idcon mini #4

IETF103.md

IETF103 Token Binding関連の論点

tokbind WG

• Meetecho: https://play.conf.meetecho.com/Playout/?session=IETF103-TOKBIND-20181106-0900

• 基本3文書はRFCになった

• TLS 1.3 → WGLCの準備OK

• 0-RTT

  • 0-RTTとToken Bindingについてはこれまで何も言われていなかった。リプレイ攻撃に対して何もできない。0-RTTではToken Bindingを使わないことを推奨
  • WGアイテムとする必要はない。0-RTTについてはcharterにも入っていないし

• TTRP (TLS Terminating Reverse Proxy)

  • TTRPで受け、検証済のTB Messageをバックエンドに送るためのヘッダ名と値を標準化
  • proxyは、それらのヘッダがもしクライアントから送られてきたら、サニタイズしなければならない
    • token bindingをサポートしないRPもサイタイズは行う必要がある

• 「メジャーなブラウザがToken Bindingのサポートをやめた」という言及があったが詳細不明

  • Chromeかな?
    • https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/8QD01FloF1o

• 全体として、tokbind WGは完了に近い。IETF104ではミーティングなしの方向

oauth WG

• Meetecho: https://play.conf.meetecho.com/Playout/?session=IETF103-OAUTH-20181105-0900

• OAuth ユースケースにおける Token Bindingの利用方法

  • draft-ietf-oauth-token-binding
  • https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
  • access token
    • Referred Token Binding IDを使用
    • アクセストークンがJWTの場合、およびintrospectionの戻り値では "cnf" 内の "tbh" にToken Binding IDのhashを入れることで検証可能
  • refresh token
    • Provided Token Binding IDを使う。かんたん
  • authorization code
    • PKCEを使用

• 残った問題: Implicit flowでのaccess tokenのbinding

  • ややこしい。これ本当に必要なのか? ↑のスライドの6ページ
  • ブラウザ内で動作するJSアプリ(クライアントドメイン)が、リソースサーバー行きのTBIDをreferred TBIDとして認証サーバーに送る必要がある
  • ひとつの方法はリソースサーバーからのリダイレクトをしてもらい、Include-Referred-Token-Binding-IDヘッダをつけてもらう
    • これにはフルページリダイレクトが発生するので、JSだけでページ遷移しないアプリ(SPA)では使えない
  • SPAが自主的に渡すことはできない
    • クライアントドメインのJSがリソースサーバードメインのTBIDを認証サーバードメインに送信するのはsame-origin policyに反する