Appendix A. Requirements Analysis (付録 A. 要件分析)
[RFC5479] はメディア鍵管理のセキュリティ要件を述べる. 本節は各要件に対し本提案を評価する.
A.1. Forking and Retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
INVITE 内の SDP offer はセキュリティ能力の広告にすぎず通信ピアの身元に依存しない. すべての端点が SRTP ならフォークとリターゲットが機能する. SRTP/非 SRTP 混在では [MMUSIC-SDP] で可能な限り透過的に交渉する. DTLS はセッション毎に新鍵を確立するため, 最終的に確立した実体だけがメディア鍵を得る (R3).
A.2. Distinct Cryptographic Contexts (R-DISTINCT)
各端点で新しい DTLS ハンドシェイクを行い, 端点毎に異なる鍵と暗号コンテキストを確立する.
A.3. Reusage of a Security Context (R-REUSE)
TLS セッション再開でセッションを再開でき, 再通信時の暗号計算を減らせる. 詳細は [RFC5764].
A.4. Clipping (R-AVOID-CLIPPING)
鍵確立がメディア面で行われるため SDP answer 前にメディアをクリップする必要はない. ただし offerer が answer を受けるまでは機密性のみ: answerer は攻撃者に送っていないと分かるが offerer は受信が answerer 由来とは限らない.
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA)
RSA, DH, ECDH など DTLS スイートの公開鍵アルゴリズムは受動攻撃に対し安全.
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG)
SIP では fingerprint のみ交換するためシグナリングパスの受動攻撃者に対し DTLS は保護を提供する.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
メディアを制しシグナリングを制しない攻撃者は DTLS MITM を試みるが証明書が変わり fingerprint 検査に失敗する. 成功にはシグナリングの fingerprint 置換が要る.
RFC 4474 Identity 等を使えば Identity 署名を行うプロキシ間のシグナリング上の任意点を支配する攻撃者は署名を無効にせず fingerprint を改ざんできない. シグナリングとメディアの両方を支配してもメディア攻撃は成功しない. UA と認証サービス間のチャネルは MUST で保護され, 認証サービスは UA 身元を MUST で検証する必要がある.
認証サービスを支配する攻撃者はそのサービスを使う UA をなりすまし得る. これは SIP Identity の意図された特性である.
A.8. Binding to Identifiers (R-ID-BINDING)
SIP-Identity [RFC4474], SIP-Connected-Identity [RFC4916], S/MIME 等のエンドツーエンド機構は証明書 fingerprint をシグナリングの From: に束縛する. fingerprint は Identity 署名で覆われる. SIPS 等では束縛は弱い.
A.9. Perfect Forward Secrecy (R-PFS)
DH/ECDHE スイートで PFS を提供する.
A.10. Algorithm Negotiation (R-COMPUTE)
重大な暗号計算の前に暗号スイートを交渉するためアルゴリズム交渉と複数スイートを追加計算なしで支持.
A.11. RTP Validity Check (R-RTP-VALID)
DTLS パケットは RTP 妥当性検査に通らない. 先頭バイトはコンテンツタイプで現行タイプは上位 2 ビットがゼロとなりバージョンゼロで最初の検査に失敗する. STUN とも区別できる. [RFC5764] を参照.
A.12. Third-Party Certificates (R-CERTS, R-EXISTING)
[RFC4474] 等のシグナリングで DTLS 証明書を認証するため第三者証明書は不要. ただし TLS と整合する共有認証基盤 (第三者証明書や共有鍵) があれば使用可能.
A.13. FIPS 140-2 (R-FIPS)
TLS 実装は FIPS 140-2 承認済みであり得, ここで使うアルゴリズムは DTLS/DTLS-SRTP の承認と整合する.
A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC)
SIP の fingerprint と DTLS の証明書交換でシグナリングと鍵管理をリンクする.
A.15. Denial-of-Service Vulnerability (R-DOS)
DTLS は組み込みの DoS 防御をある程度提供する ([RFC4347] 4.2.1 節).
A.16. Crypto-Agility (R-AGILITY)
暗号スイートを交渉できるため新アルゴリズムを段階的に展開できる. 固定 MD5/SHA-1 KDF の置換作業は継続中.
A.17. Downgrading Protection (R-DOWNGRADE)
提供スイートの選択はハンドシェイク後段で確認されるためダウングレード攻撃に対し保護される. 実時間でスイートを破られない限り有効. RFC 4474 はシグナリング上の能動攻撃者が SRTP から RTP へ下げるのを防げる.
A.18. Media Security Negotiation (R-NEGOTIATE)
DTLS は UA がセッション毎にメディア安全パラメータを交渉できる.
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING)
DTLS-SRTP フレームワークは SIP に依存しない. fingerprint とメディア記述を交換できるプロトコルなら保護できる.
A.20. Media Recording (R-RECORDING)
[SIPPING-SRTP] の拡張で中間者が MITM になる必要なしに録画を支持する.
中間者が録画するなら MITM である必要がある.
A.21. Interworking with Intermediaries (R-TRANSCODER)
メディアをトランスコードする中間装置と接続するにはトランスコーダが鍵材料にアクセスし本文書の意味で端点として扱われる.
A.22. PSTN Gateway Termination (R-PSTN)
メディア安全は PSTN ゲートウェイで終端し得る. エンドツーエンドではないがゲートウェイが PSTN 名前空間を代表する権限を持つという本フレームワークの目標と整合する.
A.23. R-ALLOW-RTP
answerer と SRTP を交渉するまで主叫側は RTP を受信し得, その後は RTP より SRTP を優先する.
A.24. R-HERFP
鍵交換がメディアパスで行われるため HERFP は DTLS-SRTP に適用されず, エラーはメディアパスで伝わりプロキシが進める必要はない.