Ietf95 http2

https://lepidum.co.jp/ Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.
IETF95 Buenos Aires
HTTP2関連レポート
株式会社レピダム
前田薫 (@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

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

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

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

Client Cert Example
IETF95報告会2016/05/10
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf
13

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

'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

Caching Secure HTTP Content using
Blind Caches
IETF95報告会2016/05/10
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf
シェアドキャッシュが
できますね!
16

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

Mix-Up Security Vulnerability
原因と対策
 原因:
 AuthZ responseなど、リダイレクトで伝わって
くる部分のintegrity保証メカニズムがない
 cf: OpenID Connectではid_token内のc_hashがdetached
signatureとして使える
 エンドポイントが複数あるが対応が不明
 対策:
 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

OAuthプロトコルの修正と今後
 OAuth基本仕様が策定されてからも、数々の
脆弱性が見つかり、mitigation方法を定めた
ドラフトが出ている
 threat modelなどの文書の改訂と基本仕様の
bis検討が必要なのではないか
 Barry: bisの着手が早すぎるのはよくない。threat
modelなどを個別に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:maeda@lepidum.co.jp / twitter: @mad_p
IETF95報告会2016/05/10

Ietf95 http2

More Related Content

What's hot

Similar to Ietf95 http2

More from Kaoru Maeda

Ietf95 http2