rfc8122.md

Read original / markdown

---

Connection-Oriented Media Transport over the TLS Protocol in the SDP

1. Introduction

• RFC4145でTCPにしか触れてなかった
  • でも実際はセキュアにメディア転送したいはず
• なので今回TLSを使用できる拡張を行う
• 自己証明書でFingerprintを生成し、それをSDPに載せる

1.1. Changes from RFC 4572

• RFC4572からのアップデート
• 後方互換性は保ちつつ
• 複数のFingerprintをマッチングするロジックを明示する
• より強力な暗号スイートを使うように更新など

2. Terminology

• いつもの

3. Overview

• なぜTLSを使う必要があるのかについて

3.1. SDP Operational Modes

• SDPの用途
• SAP: セッションの告知
• オファー・アンサー: 示し合わせて交換

3.2. Threat Model

• どんな脅威が考えられるか
• セッションの傍受
• なりすまし
  • アンサーを代わりに返しちゃうかも
• これらはTLSで防ぐことができる

3.3. The Need for Self-Signed Certificates

• SDPを作成するエンドポイントのIPは不定
  • だいたいが動的にIPやホスト名を決定する
• そうなると自己証明書しかない
• 自己証明書でSDPの記述の整合性を保証する
  • 自己証明書のFingerprintをSDPの属性につける

3.4. Example SDP Description for TLS Connection

• SDPにFingerprintを載せる例
• a=fingerprint属性をm=セクションごとに

4. Protocol Identifiers

• m=行のプロトコルにTCP/TLSを使う
• そのほかa=setupとa=connectionも
  • WebRTCではa=setupだけ

5. Fingerprint Attribute

• 認証にはX.509証明書を使う
• 自身が提示したFingerprintでTLSのハンドシェイクされることを期待する
• a=fingerprint行でそれを示す
  • ハッシュ関数の名前とそのハッシュ値を記述する
  • a=fingerprint:sha-256 92:BB:7F:59:47:FD:21:4D:D2:...
• MD2とMD5をハッシュ関数に使ってはいけない
• この属性は、セッションレベルでもいいし、メディアレベルでもいい
  • セッションレベルにある場合は、すべてのメディアレベルで共通になる

5.1. Multiple Fingerprints

• 複数のa=fingerprint属性を、単一のm=セクションに紐付けられる
• その場合は、SHA-256と任意のアルゴリズムにする
• WebRTCではそうならない

6. Endpoint Identification

• 本文なし

6.1. Certificate Choice

• 証明書の用意について
• c=行にあるIPに一致する証明書にしてもよい
  • ただしワイルドカードパターンはだめ
• セキュリティの懸念はSection7.にて

6.2. Certificate Presentation

• TLSのハンドシェイクでFingerprintが不一致の場合
  • bad_certificateエラーで終了する
• オファー・アンサーでは、a=setup:activeの側が証明書を提示する
  • クライアントが提示しない場合も、bad_certificateエラーで終了する
• a=setup:passiveまたはa=setup:actpassの場合は、オファー送信後すぐに接続を開始する
  • ただしFingerprintを照合できるまではそのデータを信頼してはいけない

7. Security Considerations

• SDP自体をセキュアに転送する必要がある
• 保護されていないチャネルでSDPを受け取る場合は、ユーザーに警告が必要かも
• TLSより安全な選択肢もあるかもしれない

8. IANA Considerations

• SDPのprotoとしてTCP/TLSを追加
• メディアレベルの属性にfingerprintを追加