ietf95 http2

https://lepidum.co.jp/ Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.

IETF95 Buenos AiresHTTP2関連レポート

株式会社レピダム

前田薫 (@mad_p)

IETF95報告会 2016/05/10

IETF95報告会2016/05/10

Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/

Agenda

WG

dispatch

httpbis

oauth, httpauth

IETF95

Buenos Aires, AG

Apr 2-8, 2016

IETF95報告会2016/05/102


自己紹介

名前前田薫@mad_p

所属株式会社レピダムシニアプログラママネージャ

コミュニティー活動 Lightweight Language

Identity Conference

http2study

業務領域

認証・認可、デジタルアイデンティティー、プライバシー

標準化支援

ソフトウェアセキュリティー、脆弱性

IETFとの関わり

IETF89 Londonより

ART, SECエリア中心

IETF95報告会2016/05/103


dispatch: ART エリア概要

概要 ARTエリアのエリアWG 月曜朝イチにAPPS全体を見渡すセッション

トピックス AD交代: Barry → Alexey appsawg MLを存続リアルタイム系の話が多かった draft-seantek-mail-regexen-00

Email validationの正規表現議論は炎上、BCPではない、やるならInformationalで

https://www.ietf.org/proceedings/95/slides/slides-95-core-0.pdf

IETF95報告会2016/05/10

5


httpbis WG

概要 HTTPプロトコルの改良

HTTP/2は完了、さまざまな拡張

HTTP自体に関する新しいアイディア

Finished Documents RFC7694: Client Initiated Content Encoding

RFC7725: An HTTP Status Code to Report Legal Obstacles

RFC7838: Alternative Services

IETF95報告会2016/05/10

7


httpbis discussions

Secure Cookies ★Opportunistic security Character Encoding and Language for Parameters ★Client hints HTTP Encryption Content Encoding JSON Header Field Values ★ORIGIN frame and connection coalescing ★Client authentication with certificates Cache Digest Decomposing the Hypertext Transfer Protocol Merkle Integrity Content Encoding ★Secure Content Delegation using HTTP and Caching Secure HTTP Content

using Blind Caches ★印: 以降で少し解説

IETF95報告会2016/05/10

8


Opportunistic security

draft-ietf-httpbis-http2-encryption-04 だいたい議論は終わり? .well-known/http-opportunistic の問題を検討 {

"origins": ["http://example.com", "http://www.example.com:81"],"commit": 86400

}

commit: この期間、セキュアコンテンツを提供する。commitの時間とwell-knownリソースの寿命を分離

HTTP/2 only問題 HTTP/1.1の実装の中には、TLSが使われているかどうかでURIスキームがhttpsであるか判断しているものがある

HTTP/2の:scheme pseudoヘッダもうまくいかない? → ML上でのSec-Schemeヘッダ検討へ(進行中)

IETF95報告会2016/05/10

9

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04


Client Hints

draft-ietf-httpbis-client-hints-00 リソースのレイアウトなど、デバイスに合わせて最適化したい。DPR

(Device Pixel Ratio), Width of the screen, or Viewportなどを使う。いままではUAを見て判定していた

RFC7234 では"Vary"ヘッダを使って、UAやクッキーに依存したコンテンツであることを示せると定義

Client Hintsはクライアントがその情報をサーバーに伝えるヘッダ群のこと DPR: 2.0 Width: 320 Viewport-Width: 320

これらの値に依存してコンテンツを作った場合、サーバーはVaryヘッダに加えてKeyヘッダも出す

サーバーはAccept-CHヘッダを送って、クライアントがClient Hintsを送ってくれれば考慮するよーと知らせることも可能

IETF95報告会2016/05/10

10

https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-00


ORIGIN Frame

draft-nottingham-httpbis-origin-frame-01 同一のHTTP/2 connection上で、他のオリジンも提供できることを示すORIGIN frame

connection coalescingできることを明示

IETF95報告会2016/05/10

https://docs.google.com/presentation/d/1r7QXGYOLCh

4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/Ilya

11

https://tools.ietf.org/html/draft-nottingham-httpbis-origin-frame-01

https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/


Client authentication with certificates

draft-thomson-http2-client-certs-02 リアクティブなクライアント証明書認証には問題があった TLS の client cert authはセッション単位

TLS を開始した後でクライアント証明書認証の必要なリソースにアクセスしたらどうする?

TLS 1.2では renegotiation; TLS 1.3では spontaneous authを使う不統一。めんどう h2ではどのアクセスが認証を必要としたのかわからない

解決方法: 証明書検証に必要な道具をHTTP/2 Frameとして実装 request-idを導入し、対応が取れるように connection単位で証明書一覧を管理、streamごとに使う

IETF95報告会2016/05/10

12

https://tools.ietf.org/html/draft-thomson-http2-client-certs-02


Client Cert Example

IETF95報告会2016/05/10

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf

13

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf


Secure Content Delegation using HTTP and Caching Secure HTTP Content using Blind Caches

draft-thomson-http-scd-00

draft-thomson-http-bc-00

ベースになっているのはContent-Encoding:

out-of-band

CE: OOBとは?

IETF95報告会2016/05/10

14

https://tools.ietf.org/html/draft-thomson-http-scd-00

https://tools.ietf.org/html/draft-thomson-http-bc-00


'Out-Of-Band' Content Coding for HTTP

draft-reschke-http-oob-encoding-04

IETF95報告会2016/05/10

Request:

GET /test HTTP/1.1

Host: www.example.com

Accept-Encoding: gzip, out-of-band

Response:

HTTP/1.1 200 OK

Date: Thu, 14 May 2015 18:52:00 GMT

Content-Type: text/plain

Cache-Control: max-age=10, public

Content-Encoding: out-of-band

Content-Length: 145

Vary: Accept-Encoding

{

"URIs": [

"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"

],

"fallback": "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"

}

クライアントは、ここを取りに行って、このヘッダと合体させてHTTPレスポンスを作る

暗号化も可能。キーをCrypto-Keyで渡す

15

https://tools.ietf.org/html/draft-reschke-http-oob-encoding-04


Caching Secure HTTP Content using Blind Caches

IETF95報告会2016/05/10

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf

シェアドキャッシュができますね!

16

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf


Server Push活用

IETF95報告会2016/05/10

この1RTT ×

Server Pushで0RTT

いきなり近くに取りに行ける

17


oauth WG

概要 Webの認可プロトコルの策定基本部品は完了セキュリティー強化、拡張

トピック Mix-Up Security Vulnerability Discovery Metadata, OAuth Metadata Token Exchange OAuth 2.0 for Apps Resource Indicators

IETF95報告会2016/05/10

19


Mix-Up Security Vulnerability

draft-ietf-oauth-mix-up-mitigation-00 クライアントをendpointについて混乱させるアタック

Dynamic registration, Authorization, Token, Resource

正当なサービスのAuthZエンドポイントから得たcodeを悪意あるサービスのTokenエンドポイントに送らせる、その逆、など

攻撃成功の要件 clientは3rd party triggerでauthzが開始できる必要がある

xsrfや、TLSのないページからの誘導など

clientは複数のclient_idを持っていること(複数のASから認可をもらうなど)

Dynamic RegistrationやDiscoveryを使うと攻撃が容易に cut-n-paste attack: 盗んだcodeをクラフトしたauthz responseに貼る

IETF95報告会2016/05/10

20

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00


Mix-Up Security Vulnerability原因と対策

原因:

AuthZ responseなど、リダイレクトで伝わってくる部分のintegrity保証メカニズムがない

cf: OpenID Connectではid_token内のc_hashがdetachedsignatureとして使える

エンドポイントが複数あるが対応が不明

対策:

AuthZ req/resのintegrity強化(deteched sig)

エンドポイント間の対応を明示→メタデータ

IETF95報告会2016/05/10

21


Discovery Metadata, OAuth Metadata

Discovery Metadata draft-ietf-oauth-discovery

discoveryによって、各エンドポイントの対応を明確に

クライアントは設定時と実行時で値に違いがないかチェック

OAuth Metadata draft-sakimura-oauth-meta

AuthZ response, Token responseに、対応するエンドポイント情報を持たせる

Linkヘッダを使用

クライアントで検証

IETF95報告会2016/05/10

22

https://tools.ietf.org/html/draft-ietf-oauth-discovery

https://tools.ietf.org/html/draft-sakimura-oauth-meta


OAuthプロトコルの修正と今後

OAuth基本仕様が策定されてからも、数々の脆弱性が見つかり、mitigation方法を定めたドラフトが出ている

threat modelなどの文書の改訂と基本仕様のbis検討が必要なのではないか

Barry: bisの着手が早すぎるのはよくない。threatmodelなどを個別にUpdate, Errataしていき、ある程度たまったところで全体的なbisを考えるのがよい

IETF95報告会2016/05/10

23


httpauth WG

概要

HTTP認証仕様の策定

すでにBasic, Digest, HOBA, SCRAM策定済

トピック

Mutual Authがnear WGLC ready

最後のissueに対する対応を確認

5月にWGLC

BerlinまでにRFC化できるか?

IETF95報告会2016/05/10

25


まとめ

httpbis HTTP/2の策定はALT-SVCが完了して、部品としてはひととおりそろった

HTTPはまだまだ課題がつきない

oauth 基本部分がひととおり完了セキュリティー強化、対策アプリサポート

httpauth Mutual Authが終わったらおしまい?

IETF95報告会2016/05/10

27


Any Questions? Please Give Feedbacks!

https://lepidum.co.jp/

mailto:[email protected] / twitter: @mad_p

IETF95報告会2016/05/10

https://lepidum.co.jp/

ietf95 http2

Internet