＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1431【臨時号】2016.8.29 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1431 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年7月17日(日)から22日(金)にかけて、ドイツ・ベルリンにて開催された、
第96回IETFミーティングの様子を、連載にてお届けしています。連載の最終
回となる本号では、セキュリティ関連報告(2)として、OAuthおよびTLSを取り
上げます。今までに発行した号は下記のURLからバックナンバーをご覧くださ
い。

  □第96回IETF報告

    ○[第1弾] 全体会議報告 (vol.1426)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1426.html

    ○[第2弾] IPv6関連WG報告 (vol.1427)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1427.html

    ○[第3弾] DNS関連WG報告 (vol.1428)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1428.html

    ○[第4弾] セキュリティ関連報告(1)
              ～DDoS対策技術についてDOTS WGを中心に～ (vol.1429)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1429.html

この第96回IETFのオンサイトでの報告会も、2016年9月12日(月)に開催いたし
ます。9月8日(木)の17:00まで参加申し込みを受け付けていますので、こちら
にもぜひ足をお運びください。

    IETF報告会(96thベルリン)開催のご案内
    https://www.nic.ad.jp/ja/topics/2016/20160818-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第96回IETF報告 [第5弾] セキュリティ関連報告(2) ～ OAuth、TLS編 ～
                                               株式会社レピダム 前田薫
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、IETF 96におけるセキュリティ関連の動向を、OAuthワーキンググ
ループ(以下、WG)、TLS WGに注目して報告します。

■ OAuth WG

OAuth WGは、Webにおける認可プロトコルOAuth 2.0およびその周辺の仕様を
策定しているWGです。2012年にOAuth 2.0がRFC6749として発行されてから、
だいぶ時間が経ちました。OAuth WGでは現在、OAuth実装の互換性およびセ
キュリティを高めるための仕様策定を進めています。

今回のOAuth WGは、2016年7月18日(月)と20日(水)の2回にわたって会合があ
り、以下のトピックが話されました。

(1) Token exchange
    [draft-ietf-oauth-token-exchange]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-0.pdf
    - 既に得ている認可トークンを利用して、権限委譲や偽装を行うトーク
      ンを得る
    - 仕様としてはほぼ完成しており、残る課題としてproof-of-possession
      の使い方がある

(2) OAuth for Native Apps
    [draft-ietf-oauth-native-apps]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-1.pdf
    - スマホなどのネイティブアプリでの、OAuth/OpenID Connectフローに
      おけるベストプラクティス
    - WebViewではなく、OSの提供するin-app browser tabの使用を推奨する

(3) OAuth Device Flow
    [draft-ietf-oauth-device-flow]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-2.pdf
    - TVなど入力装置がないが表示装置はあるデバイス向けの手順。TVに表
      示されたコードを、スマホやPCから入力して認可を行う

(4) AMR Values
    [draft-ietf-oauth-amr-values]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-3.pdf
    - 認可に際し、使用した認証手段(パスワード、指紋など)を表現するた
      めの語彙
    - 仕様は安定しておりWGLC (WG Last Call)になった

(5) OAuth 2.0 Authorization Server Discovery Metadata
    [draft-ietf-oauth-discovery]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-5.pdf
    - IdP Mix-up Attackに対する緩和策として、エンドポイント情報をサー
      バーメタデータとして提供する形式を定める

(6) Mix-up mitigation evaluation
    [draft-ietf-oauth-mix-up-mitigation]
    https://www.ietf.org/proceedings/96/slides/slides-96-oauth-8.pdf
    - IdP Mix-up Attackの緩和手法について、セキュリティプロパティ
      (Authentication、Containment)とプロバイダ・クライアントでの実装
      コスト、移行コストから評価

(7) Token Binding for OAuth and OpenID Connect and Implementations
    for the Token Binding Protocol
    [draft-jones-oauth-token-binding]
    [draft-campbell-oauth-tbpkce]
    https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-3.pdf
    - tokbind WGの成果に対応し、token bindingのOAuthシナリオでの使い
      どころを議論

ここではMix-up Attackに関連する(5)、(6)のトピックについて、少し詳しく
解説します。

(5)と(6)は、2016年1月にOAuth Security Advisoryとして出された「Mix-up
Attack」の緩和に関するものです。Mix-up Attackは、OAuthで使用する複数
のエンドポイントを、誤ってクライアントに設定させることにより、codeや
tokenを攻撃者のサーバーに送信させるという攻撃です。複数のエンドポイン
トのうち、例えばどれか一つだけが攻撃者による偽物URLを教えられた、とい
うことがあっても、これまでクライアントにはそれを検証するすべがありま
せんでした。

(5)のAuthorization Server Metadataは、認可サーバードメイン下にある特
定のURLから、JSON (JavaScript Object Notation)文書をクライアントが取
得することで、サーバーの複数のエンドポイントが正しく対応していること
を確認できるようにする提案です。そのための、JSON文書の要素を規定しま
す。情報を署名付きJWT (JSON Web Token)としておくことで、検証をより安
全にすることもできます。リソースサーバーから認可サーバーを指定するよ
うなユースケースも、別の提案として準備されています。

(6)は、Mix-up Attackの緩和策を、効果と費用の観点から評価したという発
表です。そもそも、OAuthが認可サーバーとクライアントの間での情報のやり
取りに、ブラウザリダイレクトを使っている部分に問題があるというのが分
析の出発点です。分析のため、二つのセキュリティプロパティ
「Authentication」と「Containment」を定義し、緩和策がこれらを守ること
ができるかを考えます。

Authenticationは、正しい相手から出たリクエストなのか検証できるという
性質です。ブラウザリダイレクトではこの部分が守れず、多くの攻撃の原因
となりました。Containmentは、情報の機密性が守れるかという性質です。リ
ダイレクトでは、情報をURLのクエリパラメータやフラグメントに乗せて送り
ますが、この部分は中間のプロキシサーバーで秘匿されているとは限りませ
ん。

Mix-upへの緩和策として二つ、

(a) レスポンスに認可サーバーのアドレス(iss)とクライアントID(client_id)
    を渡し、クライアントで確認する方法
(b) POST bindingを使う方法

を、AuthenticationとContainmentの二つの性質および、実装・移行のしやす
さという観点から評価しました。

(a)案のクライアントでの認可サーバー検証では、issで示されるドメインか
らサーバーのメタデータを取得して検証します。この方法ではMix-upは防げ
るものの、悪意あるサーバーは偽のメタデータも提供できてしまうため、
Authenticationは部分的にしか守れません。Containmentは対策がないため、
従来のままです。実装はそれほど難しくなく、後方互換性があるので移行は
楽です。

(b)案のPOST bindingは、リダイレクトの替わりに、ブラウザからのPOSTを
使って情報を渡します。ブラウザはPOST時に、Originヘッダを付加します。
このヘッダはJavaScriptから改竄できません。リクエストを受信したときに、
このヘッダを検査することでオリジンを知ることができ、Authenticationを
守れます。また、情報そのものはHTTPS通信上のリクエストbodyで送られるた
め、Containmentも守られます。実装はそれほど難しくはありませんが、一方
で移行には、従来方式の廃止に多くの労力が必要となるでしょう。

今後のMix-upに対する緩和策としては(b)案が推奨され、併せて(a)案や他の
緩和策(PKCE (Proof Key for Code Exchange by OAuth Public Clients)など)
の普及も進めていくことになりそうです。

OAuth 2.0プロトコルがRFCとなって以降、さまざまな脆弱性が指摘され、そ
れらに対する緩和手段の検討と仕様化が続いています。これらの緩和手段は
拡張仕様として定義されているものの、事実上のMUSTと考えられるものが多
くあります。前回のIETF 95で、複数文書にわたる緩和手段をまとめ、RFC6819
(OAuth 2.0の脅威モデルとセキュリティ)の改訂を考えようという指摘があり
ましたが、改訂にはまだ時間がかかりそうです。最新情報をウォッチしてお
きましょう。


■ TLS WG

TLS WGでは、SSL/TLSの次のバージョンである、1.3策定の最終検討段階に入っ
ています。今回のIETFでは、7月19日(火)に1コマの会合が行われ、TLS1.3の
話で終始しました。

- https://www.ietf.org/proceedings/96/slides/slides-96-tls-4.pdf

ここでは、話題になったトピックのうち、比較的大きな変更を伴った二つの
提案、「Cipher Suite Negotiation」と「Version Negotiation」について解
説します。

○Cipher Suite Negotiation

TLSでの暗号スイートは、鍵交換方式、共通鍵暗号方式、署名アルゴリズムの
組で決まります。これまでのTLSでは、これらのすべての可能な組み合わせに
番号を割り当て、その番号を使ってスイートのネゴシエーションを行ってい
ました。しかし、この方法では各要素の直交性が低く、例えば新しい共通鍵
暗号方式を採用する場合に、残りの組み合わせのすべてについて番号を割り
当てる必要があるなどの問題がありました。会議ではこれを「中華メニュー」
方式と呼んでいました。中華レストランでは、「肉の種類」×「ごはんか麺
か」×「味付」を直交した組み合わせで注文するのではなく、考えられるす
べての組み合わせにあらかじめ番号が振られていて、その番号で注文するこ
とに例えたものです。

TLS1.3での暗号スイートネゴシエーションにおいて、このTLS1.2までの中華
メニュー方式をやめ、より直交性の高い指定方法が提案されました。AEAD
(Authenticated Encryption with Associated Data)-PRF (Pseudo Random
Function)、署名アルゴリズム、鍵交換と群の指定、そして新たに加えるPSK
(Pre Shared Key)方式という4軸に分解して、それぞれを指定するというもの
です。「TLS1.3策定の最終段階になってこんな大きな変更を入れるのか」
「特定の組み合わせでないと動かない場合を扱えるのか」「AEADで合意でき
た後で鍵交換で失敗するなど手戻りがあるのでは」などの議論がありました。
結論として、この方式を採用するという合意が得られています。

○Version Negotiation

TLS1.2までは、クライアントがサポートするTLSのバージョンのうち最高のも
のを提示し、ネゴシエーションでは合意できる最も新しいバージョンを使う
と規定されていました。これに対し、サポートするバージョンを複数列挙し
てはどうかという提案がありました。「1.0と1.3は使いたいが、1.1や1.2は
使いたくないというような指定が可能になる」「新方式の実験中に独自番号
を混ぜることができる」「複雑になるだけでは」「ミドルボックスが絡んだ
場合の挙動が心配される」などの議論がありました。結論として、この提案
は却下されました。

○今後のスケジュール

中華メニュー方式から直交方式への変更を含めたdraft-15を2016年8月上旬
に、その後、試験実装を経て8月末のdraft-16でワイヤフォーマットを固定
し、9月にWGLCに突入したいというスケジュールが示されました。早くTLS1.3
を策定したいという願いがある一方で、中華メニュー方式の廃止など大きな
変更がこの時点で入ってきているので、実装者が十分な検証のできる時間も
確保したいところです。今後の進み具合に注目しましょう。

              ◇                ◇                ◇

次回の第97回IETFは、2016年11月13日(日)から18日(金)にかけて、韓国のソ
ウルにて開催されます。

  IETF 97 Seoul, South Korea
  http://ietf.org/meeting/97/


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1431/1dad90f55249d100584bf332f74f2178┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1431/06016dcb4318bc84a3795e400cda4d99┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.1431 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2016 Japan Network Information Center