5. Establishing a Secure Channel (安全チャネルの確立)

交換する二端点は DTLS ハンドシェイクで証明書として身元を示す. 証明書の扱いは [RFC4572] に従う.

自己署名証明書では, subjectAltName にユーザの URI を MAY で含めてよい. デバッグ用であり端点への束縛には不要である. 整合性は SDP の fingerprint 属性で保証する. subjectAltName は検証の重要部分ではない.

鍵生成は高コストのため, セッション毎の証明書生成は必須ではない.

[RFC3264] の offer/answer モデルは SIP [RFC3261] 等が用いる. 通常の SDP [RFC4566] に加え, 各メディア記述 ("m=" 行とパラメータ) に [RFC5764], [RFC4145], [RFC4572] で規定される属性を含める.

安全なメディアセッションを張る端点は SIP で offer を送る. SDP には使用証明書の fingerprint を含める. offer を含む SIP メッセージは整合性保護チャネルで offerer の SIP プロキシへ送る SHOULD である. プロキシは [RFC4474] に従い Identity ヘッダを加える SHOULD である. 受信側は Identity で送信者を検証でき, 署名後に本文が改ざんされていないことも分かる.

answerer は offerer と DTLS association を張るか, answer で offerer に TLS 開始を指示できる. いずれにせよ相互証明書ベースの DTLS 認証を用いる. ハンドシェイク後, 認証済み身元情報がアプリに渡る. answerer は offer の SDP fingerprint と offerer の DTLS 証明書を対応付けられ, ユーザにメディア保護を示せる. offerer は answerer の fingerprint を未受信の場合一時的に証明書を受諾するだけかもしれない.

answerer が offer を受諾すると answer に自身の fingerprint を返す. offerer はピア証明書を承認または拒否し, ユーザに示せる.

メディア保護の認証と鍵交換はすべてメディアパスの DTLS で行われ, シグナリングパスは fingerprint 検証にのみ使われる.

offer/answer は次を満たす MUST である.

• [RFC4145] の setup を使う MUST. offerer は setup:actpass とし answer 前の client_hello に備える MUST. answerer は setup:active または setup:passive MUST. passive は answer 後までハンドシェイクが始まらず遅延が増える. active は answer と並行可能であり RECOMMENDED. active 側は各フロー (ホスト/ポート四つ組) で ClientHello を送り DTLS を開始する MUST.

• [RFC4145] の connection 属性は使ってはならない MUST NOT.

• [RFC4572] の証明書 fingerprint 属性を使う MUST.

• DTLS の証明書はシグナリングの fingerprint と一致する MUST (第 8 節).

• 不一致ならメディアセッションを直ちに破棄する MUST. 相手の fingerprint 待ちは許されるが遅延の副作用あり.