OAuth Security Workshop 2017 #osw17

OAuth Security Workshop 2017 TOI
2017-07-24
Tatsuo Kudo http://www.linkedin.com/in/tatsuokudo
Cyber Consulting Services
NRI SecureTechnologies, Ltd.

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1
IETF OAuth Working Group がオーガナイズする、
OAuthのセキュリティにフォーカスしたワークショップ
業界関係者と研究者が一堂に会する場を設けること
により、OAuthがもたらす「アシュアランス」の改善と、
OAuth自体の品質向上を目指す
年1回開催。2017年は7月13, 14日の2日間、スイス
連邦工科大学チューリッヒ校にて実施
OAuth Security Workshop とは
https://zisc.ethz.ch/oauth-security-workshop-2017/
Source: https://twitter.com/_nat_en/status/885861840990990337

スケジュール
https://zisc.ethz.ch/oauth-security-workshop-2017/
08:30-09:00 Registration and coffee
09:00-09:15 Torsten Lodderstedt, YES Europe Opening Remarks
09:15-10:15 David Basin, ETH Zurich Security Protocols at ETHZ slides
10:15-10:30 break
10:30-11:30 Cas Cremers, University of Oxford
Automated analysis and the subtleties of
authentication: Adventures in TLS 1.3 (Invited
Talk) slides
11:30-11:45 break
11:45-12:30 Michael Jones, Microsoft
OAuth Token Binding: Status and Next Steps
slides
12:30-13:15
Denis Pinkas, DP Security
Consulting
A privacy by design eID scheme supporting
Attribute-based Access Control (ABAC) slides-
scheme slides-German-eID paper
13:15-14:45 Lunch at Dozentenfoyer (directions)
14:45-15:30
Naveen Agarwal, Breno de
Medeiros, Google
OAuth & Phishing – Experiences @ Google
slides
15:30-16:15 Torsten Lodderstedt, John Bradley OAuth security slides
16:15-16:45 break
16:45-17:30 Sven Hammann, ETHZ
Proposing a new Private Mode for Open ID
Connect slides
18:00 Dinner at The Alehouse – Palmhof (location)
08:30-09:00 Coffee
09:00-09:45
Daniel Fett, Ralf Kuesters, and
Guido Schmitz, Universität
Stuttgart
The Web SSO Standard OpenID Connect: In-
Depth Formal Security Analysis and Security
Guidelines slides
09:45-10:30
Nat Sakimura, Nomura Research
Institute
Future Proofing the OAuth 2.0 Authorization
Code Grant Protocol by the application of BCM
Principles slides paper
10:30-10:45 break
10:45-11:30 Hannes Tschofenig, ARM
Lessons learned from security protocol design:
Meaningful content for security consideration
sections of technical specifications slides
11:30-11:45 break
11:45-12:30
William Denniss (presented by
John Bradley), Google
Improving Native App OAuth Security with
External User Agents slides
12:30-13:15
Go Yamamoto, Richard Boyer,
Kenji Takahashi, and Nat
Sakimura, Nomura Research
Institute
Asserting Access Tokens from the Transport
Layer slides
13:15-14:45 Lunch at Dozentenfoyer (directions)
14:45-15:30 Jacob Ideskog, Curity
Simplified Integration of OAuth into JavaScript
Applications slides
15:30-16:00 break
16:00-16:45 Antonio Sanso, Adobe Invalid curve attack in JWE ECDH-ES slides
16:45-17:30 General Discussion

 セキュリティプロトコルのモデル化
 ScytherによるNSPK（ニーダム・シュレーダー公開鍵プロトコル）の解析デモ
 AliceからBobの通信をCharlieが仲介し、BobはCharlieのことをAliceだと信じてしまう
 cf. https://staff.aist.go.jp/y-isobe/CSP-NSPK/NSPK-CSP-slides-IEICE-Taikai-20150909.pdf
 “Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication” の話
 ISO 9798-2-5 Symmetric key encryption with TTP (Trusted Third Party)
 TTPが実際のEntity Authをやった場合どうなる!?
Security Protocols: Foundations, Methods, and Tools at ETHZ by David Basin, ETH Zurich
https://zisc.ethz.ch/wp-content/uploads/2017/02/basin-securityprotocols.pdf

 1.3のゴール
 レガシーなやつを排除してクリーンスタートする。楕円曲線しか使わないとか
 0-RTT、いきなりペイロードが暗号化されてる状態
 Clean up design。よりよいデザイン原則。IETFの人がデザイン過程に関わってる
 0-RTT
 それなりのキーから始めて、あとでアップグレードする。PSK (pre shared key) -resumption。
かなり速い。delayed authentication
 Tamarin Prover で formal analysis
 クライアント認証周りの攻撃 (revision 10+) を発見
 nonceの再利用によるなりすまし
 Awkward handshake: Client can’t tell difference between “accept” and “reject but continue.
サーバーが複数インスタンスの場合とか
Automated analysis and the subtleties of authentication: Adventures in TLS 1.3 by Cas Cremers,
University of Oxford
https://zisc.ethz.ch/wp-content/uploads/2017/02/cremers_tls_invited.pdf

 仕様3つ
 draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, draft-ietf-tokbind-https
 Keyは長期間 → PC閉じてまた起動してもそのままバインドされてる
 Cookieのchannel binding
 super cookieを避けた。鍵ペアはブラウザがクッキーと同じバウンダリで作る。eTLD+1
 TB4OIDC: tbhというカンファメーションクレーム。ハッシュ。IDトークンに入れる
 議論
 tokbindいるんか? なにを解決しようとしてるのか
 導入時の課題。最新の環境が必要。経済学的には、いろんなブラウザからのアクセスを受け入れた
い。Windows 7とかも。そうするとダウングレードアタックを招く。非常に重要な議論
 0-RTTはまだ完全に理解されているものではない。Rev 21でなんか変わった
OAuth Token Binding: Status and Next Steps by Michael Jones, Microsoft

 アクセストークンを属性のやり取りに使ってる話 (?)
A privacy by design eID scheme supporting Attribute-based Access Control (ABAC) by Denis Pinkas,
DP Security Consulting
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt

 Challenges with “Undefined”
 Developer registration, Approval Page, Notification, Usage, User controls, Revocation, Admin Controls
 Googleならではの課題
 スコープが数100
 データタイプ、なんでもある。GDriveとかも。SnapchatがGCP使ってたり
 ユーザーのリテラシー。グローバルなのでバラバラ
 企業ユーザーが悪意のあるアプリに権限付与しちゃったりとか
 こないだの “OAuth Phishing Attack”
 client_idを無効化した。無効化することで同時にトークンも使えなくなる
 今後はベリフィケーションをもっとやる、ユーザー数がある閾値を超えたらマニュアルレビューする
 Wordpress Plugin のケース。コンタクトしてねボタンがGmailの権限を必要とする。インストールするのはWordpress管理者
 Approval Page
 多くのユーザーは書かれてることを読まない。レビューとかは読む。Yahooで、スコープを減らす機能をつけた → スコープ減らしたら
SSOしかできなくなった → 前のページに戻ってスコープ戻そうとしたり
 サインインについては承認ページをなくした。メールアドレスとプロファイル email profile だけ
 UXチームの調査にもとづいて、ボタンを “Trust” にした。ユーザーが実際に信頼するということをわかりやすくした
 リボケーション: リスクの高いアプリから順に並べて、レビューしてもらう
 ドメインレベルでのスコープ制御: G Suiteでできるようになった。いま何社かでテスト中。Gmailとか単位。あとスコープ単位
OAuth & Phishing – Experiences @ Google by Naveen Agarwal, Breno de Medeiros, Google
https://zisc.ethz.ch/wp-content/uploads/2017/02/agarwal_challenges.pdf

 “Access token phishing”
 リソースサーバーが悪いやつだった場合にどうするか
 ASからMetadataを取得する
 クライアントに負担がかかる
 Audience Restriction
 クライアントが、トークン使いたい先 (URI) を指定してATを取得する
 TLSへの攻撃には弱い。DNS Attackにも? いずれにせよ TLS ちゃんとしてる前提
 PoP
 RS XがMITMしようとしたリクエストが無効なものになる。署名が一致しないので
 Transport: Token Binding, MTLS (Subject DN使う)
 Application: 新しいトークンを作ってAudience Restrictionする。Signed Request, J-POP
 Q. Real issueはなによ?
 UMAとか、もろに影響がある。あるRSがやられて、そこを踏み台に他のRSがやられちゃうケース。FAPI では Sender Restriction やろうとしてる
 Q. ふつうASはRSのこと知ってるよね?
 Federated OAuthとか、Googleが3rd PartyにAT出すケースとかある
OAuth security by Torsten Lodderstedt, John Bradley
https://zisc.ethz.ch/wp-content/uploads/2017/02/lodderstedt_accesstoken.pdf

 IdPはユーザーがどのRPにログインしようとするかを知ることができる。たとえば医療関係の
フォーラムにアクセスしようとしてるとか
 Our solution: We propose a new mode that hides the RP’s identity from the IdP
 OIDC private implicit mode
 implicit modeと同等のセキュリティ
 client_id_hash、rp_nonceの導入
▪ AuthZ Reqにおいて、rp_nonceはフラグメントで送る
 IdPのJSがブラウザ上でrp_nonceを使ってhashを計算する。ハッシュはランダム値
 議論・コメント
 IdPのJSが値をサーバーにフォワードしないというのは現実的なん?
 IDトークンのリプレイはどうなん?
 データ最小化難しいのでは
 redirect_uri の verification を JS でやる? できる?
Proposing a new Private Mode for Open ID Connect by Sven Hammann, ETHZ
https://zisc.ethz.ch/wp-content/uploads/2017/02/hammann_oidc_private_mode.pdf

 OIDC の formal model を開発した
 ベストプラクティス準拠
 主要なセキュリティ・プロパティを形式化
 Authentication (IDトークン), Authorization (ATを使ったアクセス), Session Integrity
 Security Guidelines
 Mix-up対策（まだ確定してない）
 stateはフレッシュなノンス（プレディクタブルにしないように）
 リファラーからの漏洩対策
 User Intention Tracking
 リダイレクトは307じゃなくて303で
 オープンリダイレクター除去
 CSRF対策
 サードパーティリソースの除去
 すべてTLS
 セッション管理、ログイン前とログイン後でセッションを分ける
The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines by
Daniel Fett, Ralf Kuesters, and Guido Schmitz, Universität Stuttgart
https://zisc.ethz.ch/wp-content/uploads/2017/02/schmitz_oidc.pdf

 BCM Principles を RFC 6749に適用し、追加すべきパラメーターを検討
 3 Criteria
 Unique Source Identifier
 Protocol + version + msg identifier
 Full list of actor/roles
Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles
by Nat Sakimura, Nomura Research Institute
https://zisc.ethz.ch/wp-content/uploads/2017/02/sakimura_future-proofing-oauth.pdf

 Approaching security in the IETF
 RFC 3552: システムセキュリティはスコープ外。ジェネリックなセキュリティフレームワーク、GSSAPIとかSASLとか、プラガブルなやつ。スタイルとして有用なドキュメントではある。不満なところ、セ
キュリティに関する記述が分散してること、セキュリティ専門家がドキュメント全体を読まなきゃいけないこと
 RFC 6793: プライバシー
 W3CのPrivacy Interest Group はJS APIが対象
 “We examined 20 RFCs (15 standards-track) from 1996, well after the imposition of the security mandate: only three had anything substantive to say about security.” -- Nick
Doty, at al. wrote in their position paper for the IAB Privacy Workshop
 PKCS#11実装を解析したら no randomness なやつがあった話。 http://homepages.inf.ed.ac.uk/s1050796/
 SAML Conformance Testingの話。みんなテスト通るよ、メッセージチェックしてないから。Negative Testing重要。IETFだとネガティブテスティング無い。相互運用性だけ
 アウェアネスとエデュケーション重要。Rationalをもっと書くべき
 RFC 6819、Core Specと同じくらいのページ数。誰が読む?
 テスタブルであること、テスタビリティ。 "Formal" な stuff を入れるとか
Lessons learned from security protocol design: Meaningful content for security consideration sections
of technical specifications by Hannes Tschofenig, ARM
https://zisc.ethz.ch/wp-content/uploads/2017/02/HannesTschofenig_OAuth_lessons.ppt

 何が問題か
 ユーザー認証・認可について、ブラウザをembedして使うと、かんたんにcookieとか取れるし、JSを注入できたりする
 開発者に悪意がなくとも、サードパーティのSDKを使ってるとリスクがあるかも
 In-App Browser Tabs
 AppAuth ライブラリ
 Coming Soon: OpenID RP Certification
 iOS 11 beta
 WWDC Video #225 https://developer.apple.com/videos/play/wwdc2017/225/
 (beta 3 adds SFAuthenticationSession to enable Shared Authentication Context (Single Sign-in))
Improving Native App OAuth Security with External User Agents by William Denniss (presented by John
Bradley), Google
http://www.thread-safe.com/2017/07/appauth.html

 インターネットから物理システムを監視したい。REST API出したい。そこの認可にOAuth使いたい
 工場Aと工場Bとの連携。工場BはAのセキュリティをマネージできない
 提案: 認可サーバーが証明書を発行し、X.509の属性としてATを返す。クライアントはその証明書を使ってRSに接続する
 クライアントが動的にクライアント証明書を切り替えられるだろうか?
 ガチガチに繋がったPKIは避けたい、別々にCA持ちたいというニーズ
 Token in Token?
 リソースサーバーごとにクライアント証明書を切り替える? チャネルの再利用できないよね
 15分毎に50万台の証明書をアップデートするような環境に有用
 署名処理はいまやそんな高コストではないという前提
 証明書をATとして使えばいんじゃね、イントロスペクションすればいんじゃね、という話
Asserting Access Tokens from the Transport Layer by Go Yamamoto, Richard Boyer, Kenji Takahashi,
and Nat Sakimura, Nomura Research Institute
https://zisc.ethz.ch/wp-content/uploads/2017/02/yamamoto_token_transport_layer.pdf

 フロントエンドのつらみ
 デベロッパーが理解するにはいまだ難解
 SPA対応、implicitでは不十分
 トークンハンドラー・パターン
 フレームに入れて分離、有効期間長めのトークン
 Token Handler Token
▪ postMessage、タイムアウト5秒くらい
 Assisted Token Flow
 "Assisted Token" は cookie に入れる。HTTP Onlyにして、JSから覗けなくする。Secureにして、
HTTPオンリーにする
 for_origin
 redirect_uriではない。クライアントをサーブするドメイン。フレーミング（型にはめる）ために使う。
X-FRAME-OPTIONS、CSPヘッダー
 Service Workerでやるといんじゃね?
 問題は単純、レイヤーをどこで分けるかがポイント
Simplified Integration of OAuth into JavaScript Applications by Jacob Ideskog, Curity
https://zisc.ethz.ch/wp-content/uploads/2017/02/ideskog_assisted-token.pdf

 http://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html の話
Invalid curve attack in JWE ECDH-ES by Antonio Sanso, Adobe
https://zisc.ethz.ch/wp-content/uploads/2017/02/sanso_jwe.pdf

 スライド / ペーパー
 https://zisc.ethz.ch/oauth-security-workshop-2017/
 Twitter
 https://twitter.com/hashtag/osw17, https://twitter.com/hashtag/osw2017
Resources

OAuth Security Workshop 2017 #osw17

OAuth Security Workshop 2017 #osw17

More Related Content

What's hot

Similar to OAuth Security Workshop 2017 #osw17

More from Tatsuo Kudo

OAuth Security Workshop 2017 #osw17