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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ietf95 http2

Similar to Ietf95 http2 (20)

More from Kaoru Maeda

More from Kaoru Maeda (12)

Ietf95 http2