OAuth Security Workshop 2017 TOI

2017-07-24

Tatsuo Kudo http://www.linkedin.com/in/tatsuokudoCyber Consulting ServicesNRI 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

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 2

スケジュール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 OxfordAutomated 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:45Daniel Fett, Ralf Kuesters, and Guido Schmitz, UniversitätStuttgart

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, ARMLessons 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

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 3

セキュリティプロトコルのモデル化

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 Zurichhttps://zisc.ethz.ch/wp-content/uploads/2017/02/basin-securityprotocols.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 4

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 Oxfordhttps://zisc.ethz.ch/wp-content/uploads/2017/02/cremers_tls_invited.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 5

仕様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

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 6

アクセストークンを属性のやり取りに使ってる話 (?)

A privacy by design eID scheme supporting Attribute-based Access Control (ABAC) by Denis Pinkas, DP Security Consultinghttps://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 7

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, Googlehttps://zisc.ethz.ch/wp-content/uploads/2017/02/agarwal_challenges.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 8

“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 Bradleyhttps://zisc.ethz.ch/wp-content/uploads/2017/02/lodderstedt_accesstoken.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 9

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, ETHZhttps://zisc.ethz.ch/wp-content/uploads/2017/02/hammann_oidc_private_mode.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 10

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 Stuttgarthttps://zisc.ethz.ch/wp-content/uploads/2017/02/schmitz_oidc.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 11

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 Institutehttps://zisc.ethz.ch/wp-content/uploads/2017/02/sakimura_future-proofing-oauth.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 12

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, ARMhttps://zisc.ethz.ch/wp-content/uploads/2017/02/HannesTschofenig_OAuth_lessons.ppt

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 13

何が問題か

ユーザー認証・認可について、ブラウザを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), Googlehttp://www.thread-safe.com/2017/07/appauth.html

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 14

インターネットから物理システムを監視したい。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 Institutehttps://zisc.ethz.ch/wp-content/uploads/2017/02/yamamoto_token_transport_layer.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 15

フロントエンドのつらみ

デベロッパーが理解するにはいまだ難解

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, Curityhttps://zisc.ethz.ch/wp-content/uploads/2017/02/ideskog_assisted-token.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 16

http://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html の話

Invalid curve attack in JWE ECDH-ES by Antonio Sanso, Adobehttps://zisc.ethz.ch/wp-content/uploads/2017/02/sanso_jwe.pdf

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 17

スライド / ペーパー

https://zisc.ethz.ch/oauth-security-workshop-2017/

Twitter

https://twitter.com/hashtag/osw17, https://twitter.com/hashtag/osw2017

Resources