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

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 認可とは
n IETFにおける認可関連WG
⁃ OAuth
⁃ Tokbind
⁃ ACE
⁃ JOSE (2011-16)
⁃ COSE (2015-16)
n IETF102の最新情報
⁃ OAuth
⁃ Tokbind
⁃ (Ace)
4

5. © DeNA Co., Ltd.
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: 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. © 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. © 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: 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. © 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. © DeNA Co., Ltd.
2020
認可関連IETF102最新情報

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)
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. © 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. © 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. © 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. © 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⽂書は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. © 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的処理
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. © 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. © DeNA Co., Ltd.
3333
ありがとうございました