Download as PDF, PPTX
IETF102 Report Authorization
- 1. © DeNA Co., Ltd. IETF102 Montreal 認可関連レポート 2018/08/31 前⽥薫 SWETグループ DeNA Co., Ltd. © DeNA Co., Ltd.
- 2. © DeNA Co., Ltd. ⾃⼰紹介 n 名前 ⁃前⽥ 薫 @mad_p n 所属 ⁃ DeNA • SWETグループ テストエンジニアリングをする チームです n コミュニティー活動 ⁃ Learn Language Events ⁃ Identity Conference ⁃ http2study n IETFとの関わり ⁃ IETF89〜97 ⁃ 今回ひさしぶりの現地参加 ⁃ SEC, ARTエリア中⼼ 2
- 3. © DeNA Co., Ltd. 国際学会/カンファレンス参加⽀援制度 n DeNAには国際学会/カンファレンス参加⽀援制度があります ⁃学会参加費／渡航費／宿泊費はDeNAが負担 n 制度⽬的以下いずれかの⽬的を果たしている場合を対象 ⁃ 海外の学会／カンファレンス参加により • 新サービスの発案、開発に寄与できる可能性がある • 今後注⽬の新サービスや最先端の技術に触れることができる • 最新の業界動向に関して情報を得ることができる n 応募対象者DeNA正社員 ⁃ ※直近1年間以内に本制度を利⽤した者は対象外 n 報告義務派遣された社員は下記の報告義務を担う ⁃ 社内に対して：国際学会／カンファレンスで得たナレッジの報告会 ⁃ 社外に対して：同業界を対象とした情報発信（ブログやSNSなど で） 3
- 4. © DeNA Co., Ltd. Agenda n 認可とは nIETFにおける認可関連WG ⁃ OAuth ⁃ Tokbind ⁃ ACE ⁃ JOSE (2011-16) ⁃ COSE (2015-16) n IETF102の最新情報 ⁃ OAuth ⁃ Tokbind ⁃ (Ace) 4
- 5.
- 6. © DeNA Co., Ltd. 認可とは n 認証と認可の違い ⁃「Authなんとか」としてよくいっしょくたにされるが… ⁃ 認証: Authentication (AuthNと略される) ⁃ 認可: Authorization (AuthZ または AuthR) ⁃ 注: ⽇本語の認証には別の意味もあるので注意 • Certification: 技適など • Attestation: 今⽇のホットワード! n 認証 Authentication ⁃ 対象が「誰であるか」を確認すること ⁃ よく⾒る例: ログイン • パスワード認証 • 2要素認証 • 認証の3要素: Something you know, have, are ⁃ 認証プロトコルの例: OpenID Connect (IETFではなくOIDF) 6
- 7. © DeNA Co., Ltd. 認可 Authorization n「誰が」「何をして」よいかどうかを判定すること n アクセス制御によく使われる。以下の登場⼈物が関わる ⁃ アクセス主体: クライアント ⁃ アクセス先リソース: リソースサーバー(RS) ⁃ 認可主体: リソースオーナー(ユーザー) ⁃ 認可サーバー(AS) n 例: Bobが友達Aliceのタイムラインをアクセスしてよい ⁃ アクセス主体 = Bob ⁃ リソース = Aliceのタイムライン ⁃ 認可主体 = システム n 例: 受付システムが@mad_pのメアドを取得してよい(SNSで登録) ⁃ アクセス主体 = 受付システム ⁃ リソース = @mad_pのユーザー情報の中のメールアドレス ⁃ 認可主体 = @mad_p 7
- 8. © DeNA Co., Ltd. HTTP Authorizationヘッダ n HTTP ヘッダAuthorization ⁃ Basic (RFC7617), Digest (RFC7616) • ユーザ名とパスワードを使って認証を求める ⁃ Bearer (RFC6750) • アクセストークンを提⽰して認可されていることを⽰す n HTTPレスポンスコード ⁃ 401 Unauthorized (RFC7235) • 「あんた誰?」 • 普及している使われ⽅ではunauthenticatedの意味合いが強い • 実態としては認証と認可の両⽅が⾏われている ⁃ 403 Forbidden (RFC7231) • 「おまえには⾒せられないなあ」 • 認可が得られない 8
- 9. © DeNA Co., Ltd. 認可とアクセストークン n クライアント(アクセス主体):リソースサーバーから情報を取得したい n リソースオーナー(認可主体)の認可が必要 n アクセストークン: 認可を表わす証票 9 リソース サーバー 認可 サーバー クライ アント ユーザー リソースリクエスト with アクセストークン アクセストークンを取得 リソースを使って サービス提供 リソース オーナー 認可を表明
- 10. © DeNA Co., Ltd. 認可プロトコル: OAuth2 nクライアント(アクセス主体): リソースサーバーから情報を取得したい n リソースオーナー(認可主体)の認可が必要 n アクセストークン: 認可を表わす証票 10 リソース サーバー 認可 サーバー クライ アント リソース オーナー ②認可を求める画⾯ ③認可OK ⑤リソースリクエスト with アクセストークン ⑦リソース レスポンス ⑥アクセス トークンの 確認 ④アクセストークン ①認可要求 ⓪リソースを 必要とする リクエスト
- 11. © DeNA Co., Ltd. OAuth2 (RFC6749,RFC6750, RFC7662) n リソースオーナーのブラウザがHTTPリダイレクトを使って、 クライアント〜認可サーバー間で情報を運ぶ 11 リソース サーバー 認可 サーバー クライ アント リソース オーナー ①Authorization Request RFC6749 ②認可を求める画⾯ ③認可OK ⑥Token Response access_token ⑦リソースリクエスト with access_token Authorization: Bearer eyJ... RFC6750 ⑨リソース レスポンス ⑧Token Introspection RFC7662 ⑤Token Request ④Authorization Response ⓪リソースを 必要とする リクエスト
- 12. © DeNA Co., Ltd. アクセストークン n アクセストークン(認可トークン) ⁃認可の証査として検証できる形にまとめたもの ⁃ OAuth2ではIntrospection Endpointで中⾝を確認できる • 何をしてよいか(scope) • 誰が認可したか(sub): リソースオーナー • 発⾏者(iss): 認可サーバー • 受領者(aud): リソースサーバー • 有効期限(exp) n Bearer(ベアラ)トークン (RFC6750) ⁃ 持ってきた⼈が使える n PoP(ポップ proof-of-possession)トークン (RFC7800) ⁃ 発⾏時の対象だけが使える ⁃ どうやってproofするか → Token bindingなど 12 https://www.slideshare.net/KaoruMaeda/tokbindfido/3
- 13. © DeNA Co., Ltd. IETFにおける認可関連WG n いずれもSECエリア ⁃OAuth (2009-) • OAuthプロトコル、JWTなどを策定 ⁃ Tokbind (2015-) • PoPトークンのうち、TLSトークンバインディングについて ⁃ ACE (2014-) • 制約デバイス上での認証・認可 ⁃ JOSE (2011-16) • JWTの署名・暗号化形式を策定 ⁃ COSE (2015-16) • JWTのCBOR版 13
- 14. © DeNA Co., Ltd. WG: WebAuthorization Protocol (OAuth) n 2009〜 ⁃ OAuth2.0プロトコル n RFC ⁃ OAuth2.0プロトコルのコア • 6749 (フレームワーク), 6750 (Bearerトークン), • 7009 (Revocation), 7519 (JWT), 7591-2 (DynReg), • 7636 (イントロスペクション), 7800 (PoPトークン) ⁃ ユースケースに応じた拡張 • 7521-3 (Assertions), 8176 (amr), 8252 (Native App) ⁃ セキュリティー強化のための拡張・BCP • 6819 (Threat Model), 7636 (PKCE), 8414 (Server Metadata) n I-D (主なもの) draft-ietf-oauth- ⁃ token-exchange, token-binding, device-flow ⁃ security-topics, resource-indicators, jwt-bcp, jwsreq 14
- 15. © DeNA Co., Ltd. WG: TokenBinding (Tokbind) n 2015〜 ⁃ トークンをクライアントの持つ秘密に暗号論的に結びつける ⁃ TLS接続を使って検証 n I-D: RFC Editor Queue ⁃ draft-ietf-tokbind-protocol-19: The Token Binding Protocol Version 1.0 ⁃ draft-ietf-tokbind-negotiation-14: TLS Extension for Token Binding Protocol Negotiation ⁃ draft-ietf-tokbind-https-18: Token Binding over HTTP 15
- 16. © DeNA Co., Ltd. WG: Ace(Authentication and Authorization for Constrained Devices) n 2014〜 ⁃ IoT(制約されたデバイス)向け認証・認可プロトコル n RFC ⁃ 7422: Use Cases for Authentication and Authorization in Constrained Environments ⁃ 8392: CBOR Web Token (CWT) n I-D: draft-ietf-ace- ⁃ oauth-authz: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE- OAuth) ⁃ oscore-profile, dtls-authorize ⁃ cwt-proof-of-possession 16
- 17. © DeNA Co., Ltd. 制約デバイスにおける認証・認可 n draft-ietf-ace-actors(expired) より ⁃ Less constrained levelでACLなど複雑な判断を⾏う ⁃ Constrained levelでは署名検証だけできればよい 17
- 18. © DeNA Co., Ltd. WG: JavascriptObject Signing and Encryption (JOSE) n 2011-16 ⁃ JWT: JSONベースのトークンの総称 • 「eyJ」 JWTヘッダは {"t で始まり、Base64するので eyJ になる ⁃ JSONデータをJWTとしてシリアライズし、署名 and/or 暗号化す るための標準 ⁃ 署名・暗号化の鍵やアルゴリズムを規定 n RFC ⁃ 7165: Use Cases and Requirements ⁃ 7515 (JWS), 7516 (JWE), 7517 (JWK), 7518 (JWA) ⁃ 7520 (Examples), 7638 (JWK Thumbprint) ⁃ 7797 (JWS unencoded), 8037 (ECDH) n OAuth WGでベストプラクティス⽂書を策定中 ⁃ draft-ietf-oauth-jwt-bcp JSON Web Token Best Current Practices 18
- 19. © DeNA Co., Ltd. WG: CBORObject Signing and Encryption (COSE) n 2015-16 ⁃ CBORベースの署名トークン(JWTのCBOR版) ⁃ CBOR RFC7049 (CBOR WG) • JSONに代わる軽量バイナリシリアライズフォーマット • IETF版MessagePack: 実装のコードサイズが⼩さいことをゴールに ⁃ COSE: JOSEのCBOR版 • JOSEと互換性を保ってコンサイスに表現 • 特定のキーワードは⼩さな整数にマッピング ⁃ ⽤途: WebAuthn, FIDO2のAttestationDataフォーマットなど n RFC ⁃ 8152: CBOR Object Signing and Encryption (COSE) 19
- 20.
- 21. © DeNA Co., Ltd. OAuth n 2つの流れ ⁃セキュリティー強化のための拡張仕様、ベストプラクティスの検討 ⁃ 新しいユースケースのサポート n セキュリティー強化 ⁃ mtls, token bindingの議論が収束 ⁃ JWS response ⁃ Distributed OAuth n 新しいユースケース ⁃ Incremental Authorization ⁃ Reciprocal OAuth 21
- 22. © DeNA Co., Ltd. PoPトークン関連 (1/2) nOAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens ⁃ draft-ietf-oauth-mtls: IESG Publication Requested ⁃ トークンをクライアントのTLS証明書に対してバインドする ⁃ 証明書はself-signedでもPKIでもよい ⁃ サーバー側LBではPKIルートからつながっていないクライアント証 明書でもいったん受け⼊れ、アプリサーバーに証明書(ないしその S256ハッシュ)を渡す設定が必要 n Token Binding ⁃ draft-ietf-oauth-token-binding: WG Item ⁃ OAuth2でのToken Bindingについて規定 • アクセストークン, リフレッシュトークン • authorization code, JWT AuthZ Grants, JWT Client AuthN ⁃ 議論は収束 22
- 23. © DeNA Co., Ltd. PoPトークン関連 (2/2) ndraft-ietf-oauth-pop-key-distribution ⁃ パラメータ名が不統⼀ • OAuthで定義されたもの • Ace-OAuth (draft-ietf-ace-oauth-authz 後述)で定義されたもの ⁃ リクエストパラメータ名audience • JWT claimのaudと意味が違うので別の⽤語を使うべき ⁃ プロセス的な話でモメた… • ace-oauthとは別⽂書にしたらよいのでは? → WGLCなので間に合わない • この問題を扱うのはOAuth WGなのかAce WGなのか的な ⁃ → OAuth WGでgenericなものを作り、Ace, WebRTC側が合わせ るということに 23
- 24. © DeNA Co., Ltd. その他セキュリティー関連 n JWTResponse for OAuth Token Introspection ⁃ draft-lodderstedt-oauth-jwt-introspection-response ⁃ Token Introspection ResponseをJWSで署名できるようにする ⁃ リクエスト時にAcceptヘッダで指定 • Accept: application/jwt ⁃ 他のAPIでも使えそう ⁃ → WGドキュメントに n Distributed OAuth ⁃ draft-hardt-oauth-distributed ⁃ clientがリソースアクセスに必要なアクセストークンを取れるASを知る⽅ 法: 401レスポンスで⽰す • Link: rel="resource_uri", rel="oauth_server_metadata_uri" ⁃ クライアントがリソースサーバーを指定してアクセストークンを取る(サ ーバーがaudience制約をかける) ⁃ draft-campbell-resource-indicators をWGアイテムとし、この話を加 える 24
- 25. © DeNA Co., Ltd. 新しいユースケースのためのOAuth n IncrementalAuthorization ⁃ draft-ietf-oauth-incremental-authz ⁃ 追加のスコープが必要になったときに要求できる仕組み • 最初に取れるだけたくさんのスコープで認可を要求するのでなく、 最初は最⼩のセットだけを取る、というプラクティスにしていく ⁃ AuthZリクエストでinclude_granted_scopesを加えると、全部⼊ りのトークンをもらえる n Reciprocal OAuth ⁃ draft-ietf-oauth-reciprocal • 相互OAuth (mutual OAuth → reciprocal OAuthと改名) ⁃ ふたつのRS(==AS) A、Bがあり、同⼀のユーザーに対しておたが いにリソースアクセスしたい場合 • 例: AlexaからSonosスピーカーを鳴らす場合 ⁃ 2つのOAuthダンスをひとつにまとめる 25
- 26. © DeNA Co., Ltd. Reciprocal OAuth 26 A (Alexa)B (Sonos)Browser AuthZ Req AがBを使う認可 AuthZ Res code=code_for_a &reciprocal=scope BがAを使う認可 Token Req grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agranttype%3reciprocal &code=code_for_a &access_token=access_token_for_b Token Res access_token=access_token_for_a
- 27. © DeNA Co., Ltd. Tokbind n 基本3⽂書はRFCEditor Queueに ⁃ draft-ietf-tokbind-protocol-19: The Token Binding Protocol Version 1.0 ⁃ draft-ietf-tokbind-negotiation-14: TLS Extension for Token Binding Protocol Negotiation ⁃ draft-ietf-tokbind-https-18: Token Binding over HTTP n Dancing John Bradley ⁃ https://www.youtube.com/watch?v=QwnVemMAU28#t=4m15s 27
- 28. © DeNA Co., Ltd. Tokbind n リバースプロキシ(TTRP: TLS Terminating Reverse Proxy) ⁃ draft-ietf-tokbind-ttrp-06 ⁃ TLS終端をするリバースプロキシから、アプリサーバーでToken Binding IDを伝えるためのHTTPヘッダを定義 • Sec-Provided-Token-Binding-ID: base64url-TBID • -Referred- も同じ • Sec-Other-Token-Binding-ID: hex(type).b64url-TBID ⁃ これらのヘッダがクライアントから送られてきたらサニタイズ ⁃ WGLCを始める n draft-ietf-tokbind-tls13-01: 進んでいる n 新しい話: Attestation ⁃ draft-mandyam-tokbind-attest-06 ⁃ Token Bindingのセキュリティー要求を満たすというattestation ⁃ Token Binding Messageの拡張として送る ⁃ WebAuthN (W3C)のattestation objectを使うといいのでは ⁃ リチャーターしてWGスコープに⼊れることを検討 28
- 29. © DeNA Co., Ltd. Ace n 概要 ⁃最近ではCBOR/COSEベースのプロトコルの議論が多い • CBORでは⽂字列よりもshort intが好まれることからくる問題も • 限られたリソースの取り合い、kidの衝突など ⁃ HTTP + JWT よりも CoAP + CWT はコンパクト • 問題の複雑さが減るわけではない ⁃ グループ通信関連 • IoT機器のグループで共有の鍵を使って通信 ⁃ 鍵の更新、グループへの加⼊/脱退でも発⽣ • draft-palombini-ace-key-groupcomm • draft-tiloca-ace-oscoap-joining ⁃ リソースディレクトリのパーミッション問題 29
- 30. © DeNA Co., Ltd. CBOR, CWTベースのOAuth的処理 ndraft-ietf-ace-oauth-authz ⁃ OAuthのAce版: HTTPに限定したOAuthより、多くのプロファイル を扱う • プロトコル(CoAP, HTTP, MQTT) • トークンタイプ(CWT, JWT, TLV) • セキュリティー(DTLS, COSE, OSCORE) ⁃ Client, RSのいずれかあるいは両⽅がIoT機器の可能性がある ⁃ RSがIoTデバイスのとき、ASがRSに合わせてトークンやPoP検証⽅ 法を選択する n draft-ietf-ace-cwt-proof-of-possession: WGLC at IETF101 ⁃ RFC7800のCOSE版 ⁃ "cnf"クレームのためのshort intを割り当てる ⁃ kid衝突の問題: • 鍵のIDがCBORでは⼩さな整数になる • アタッカーが別の鍵に同じkidを割り当てると、RSが混乱するかもしれない 30
- 31. © DeNA Co., Ltd. リソースディレクトリのパーミッション問題 n リソースディレクトリー ⁃どのIoTデバイスがどんなサービスをどのIPアドレスで提供してい るか n 悪意のあるノードが、正規サービスの名を騙って登録すると困る ⁃ OAuthのscopeを使って「特定の名前で登録する権利」を認可して はどうか? ⁃ これに対する反応 • 名前としてランダムな数字を使えばいい n サービス名に対して別のセマンティスクで登録すると困る ⁃ 「Room 405の室温」という名前で電球を登録したら? ⁃ これをscopeで解決しようとすると、セマンティクスの表現形式を 定めることになってしまう ⁃ 反応 • そもそもプロトコルで解決できない問題なのでは? (壊れた温度計とか) • リソースディレクトリだけ守っても仕⽅ない 31
- 32. © DeNA Co., Ltd. まとめ n 認可とは ⁃「誰が何をしてよいか」 ⁃ cf. 認証…その⼈が何者であるか n 認可を扱うIETF WG ⁃ 認可プロトコル: OAuth, Tokbind, Ace ⁃ トークン表現形式: JWT (JOSE), CWT (COSE) n IETF102最新情報 ⁃ OAuth: セキュリティー強化とユースケース拡張 ⁃ Tokbind: 基本⽂書が完了、周辺の仕様を検討 ⁃ Ace: CoAP+CWTでのOAuth, トークン関連の議論 32
- 33.