Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IETF102 Report Authorization

601 views

Published on

IETF報告会102の資料です。
IETFでの認可関連WGの紹介と最新情報です

Published in: Internet
  • /.DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... /.DOWNLOAD PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... /.DOWNLOAD doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

IETF102 Report Authorization

  1. 1. © DeNA Co., Ltd. IETF102 Montreal 認可関連レポート 2018/08/31 前⽥ 薫 SWETグループ DeNA Co., Ltd. © DeNA Co., Ltd.
  2. 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. 3. © DeNA Co., Ltd. 国際学会/カンファレンス参加⽀援制度 n DeNAには国際学会/カンファレンス参加⽀援制度があります ⁃ 学会参加費/渡航費/宿泊費はDeNAが負担 n 制度⽬的以下いずれかの⽬的を果たしている場合を対象 ⁃ 海外の学会/カンファレンス参加により • 新サービスの発案、開発に寄与できる可能性がある • 今後注⽬の新サービスや最先端の技術に触れることができる • 最新の業界動向に関して情報を得ることができる n 応募対象者DeNA正社員 ⁃ ※直近1年間以内に本制度を利⽤した者は対象外 n 報告義務派遣された社員は下記の報告義務を担う ⁃ 社内に対して:国際学会/カンファレンスで得たナレッジの報告会 ⁃ 社外に対して:同業界を対象とした情報発信(ブログやSNSなど で) 3
  4. 4. © DeNA Co., Ltd. Agenda n 認可とは n IETFにおける認可関連WG ⁃ OAuth ⁃ Tokbind ⁃ ACE ⁃ JOSE (2011-16) ⁃ COSE (2015-16) n IETF102の最新情報 ⁃ OAuth ⁃ Tokbind ⁃ (Ace) 4
  5. 5. © DeNA Co., Ltd. 5 認可について
  6. 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. 7. © DeNA Co., Ltd. 認可 Authorization n 「誰が」「何をして」よいかどうかを判定すること n アクセス制御によく使われる。以下の登場⼈物が関わる ⁃ アクセス主体: クライアント ⁃ アクセス先リソース: リソースサーバー(RS) ⁃ 認可主体: リソースオーナー(ユーザー) ⁃ 認可サーバー(AS) n 例: Bobが友達Aliceのタイムラインをアクセスしてよい ⁃ アクセス主体 = Bob ⁃ リソース = Aliceのタイムライン ⁃ 認可主体 = システム n 例: 受付システムが@mad_pのメアドを取得してよい(SNSで登録) ⁃ アクセス主体 = 受付システム ⁃ リソース = @mad_pのユーザー情報の中のメールアドレス ⁃ 認可主体 = @mad_p 7
  8. 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. 9. © DeNA Co., Ltd. 認可とアクセストークン n クライアント(アクセス主体): リソースサーバーから情報を取得したい n リソースオーナー(認可主体)の認可が必要 n アクセストークン: 認可を表わす証票 9 リソース サーバー 認可 サーバー クライ アント ユーザー リソースリクエスト with アクセストークン アクセストークンを取得 リソースを使って サービス提供 リソース オーナー 認可を表明
  10. 10. © DeNA Co., Ltd. 認可プロトコル: OAuth2 n クライアント(アクセス主体): リソースサーバーから情報を取得したい n リソースオーナー(認可主体)の認可が必要 n アクセストークン: 認可を表わす証票 10 リソース サーバー 認可 サーバー クライ アント リソース オーナー ②認可を求める画⾯ ③認可OK ⑤リソースリクエスト with アクセストークン ⑦リソース レスポンス ⑥アクセス トークンの 確認 ④アクセストークン ①認可要求 ⓪リソースを 必要とする リクエスト
  11. 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. 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. 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. 14. © DeNA Co., Ltd. WG: Web Authorization 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. 15. © DeNA Co., Ltd. WG: Token Binding (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. 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. 17. © DeNA Co., Ltd. 制約デバイスにおける認証・認可 n draft-ietf-ace-actors (expired) より ⁃ Less constrained levelでACLなど複雑な判断を⾏う ⁃ Constrained levelでは署名検証だけできればよい 17
  18. 18. © DeNA Co., Ltd. WG: Javascript Object 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. 19. © DeNA Co., Ltd. WG: CBOR Object 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. 20. © DeNA Co., Ltd. 2020 認可関連IETF102最新情報
  21. 21. © DeNA Co., Ltd. OAuth n 2つの流れ ⁃ セキュリティー強化のための拡張仕様、ベストプラクティスの検討 ⁃ 新しいユースケースのサポート n セキュリティー強化 ⁃ mtls, token bindingの議論が収束 ⁃ JWS response ⁃ Distributed OAuth n 新しいユースケース ⁃ Incremental Authorization ⁃ Reciprocal OAuth 21
  22. 22. © DeNA Co., Ltd. PoPトークン関連 (1/2) n OAuth 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. 23. © DeNA Co., Ltd. PoPトークン関連 (2/2) n draft-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. 24. © DeNA Co., Ltd. その他セキュリティー関連 n JWT Response 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. 25. © DeNA Co., Ltd. 新しいユースケースのためのOAuth n Incremental Authorization ⁃ 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. 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. 27. © DeNA Co., Ltd. Tokbind n 基本3⽂書は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 n Dancing John Bradley ⁃ https://www.youtube.com/watch?v=QwnVemMAU28#t=4m15s 27
  28. 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. 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. 30. © DeNA Co., Ltd. CBOR, CWTベースのOAuth的処理 n draft-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. 31. © DeNA Co., Ltd. リソースディレクトリのパーミッション問題 n リソースディレクトリー ⁃ どのIoTデバイスがどんなサービスをどのIPアドレスで提供してい るか n 悪意のあるノードが、正規サービスの名を騙って登録すると困る ⁃ OAuthのscopeを使って「特定の名前で登録する権利」を認可して はどうか? ⁃ これに対する反応 • 名前としてランダムな数字を使えばいい n サービス名に対して別のセマンティスクで登録すると困る ⁃ 「Room 405の室温」という名前で電球を登録したら? ⁃ これをscopeで解決しようとすると、セマンティクスの表現形式を 定めることになってしまう ⁃ 反応 • そもそもプロトコルで解決できない問題なのでは? (壊れた温度計とか) • リソースディレクトリだけ守っても仕⽅ない 31
  32. 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. 33. © DeNA Co., Ltd. 3333 ありがとうございました

×