跳到主要内容

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 端点时, 使用正在定义的 SDP 能力机制 [MMUSIC-SDP] 在可能时透明协商安全. 因 DTLS 为每个会话建立新密钥, 仅最终建立呼叫的实体获得媒体加密密钥 (R3).

A.2. Distinct Cryptographic Contexts (R-DISTINCT)​

DTLS 与每个端点执行新的 DTLS 握手, 为每个端点建立不同的密钥与密码学上下文.

A.3. Reusage of a Security Context (R-REUSE)​

DTLS 允许通过 “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)​

DTLS 密码套件使用的公钥算法 (如 RSA, Diffie-Hellman, 椭圆曲线 Diffie-Hellman) 可抵御被动攻击.

A.6. Passive Attacks on the Signaling Path (R-PASS-SIG)​

因仅通过 SIP 信令交换指纹, DTLS 可抵御信令路径上对手的被动攻击.

A.7. (R-SIG-MEDIA, R-ACT-ACT)​

控制媒体信道但不控制信令信道的攻击者可对 DTLS 握手实施 MITM, 但这会改变证书从而导致指纹校验失败. 因此任何成功攻击都要求攻击者修改信令消息以替换指纹.

若使用 RFC 4474 Identity 或等效机制, 控制执行 Identity 签名的代理之间任一点信令信道的攻击者无法在不让签名失效的情况下修改指纹. 因此, 即使攻击者同时控制信令与媒体路径, 也无法成功攻击媒体流量. 注意: UA 与认证服务之间的信道必须 (MUST) 安全, 且认证服务必须 (MUST) 验证 UA 身份, 该机制才安全.

注意: 控制认证服务的攻击者可冒充使用该认证服务的 UA. 这是 SIP Identity 的有意特性: 认证服务拥有命名空间并因而定义用户与身份的对应.

A.8. Binding to Identifiers (R-ID-BINDING)​

使用端到端机制如 SIP-Identity [RFC4474] 与 SIP-Connected-Identity [RFC4916] 或 S/MIME 时, 它们将端点证书指纹绑定到信令中的 From: 地址. 指纹被 Identity 签名覆盖. 使用其他机制 (如 SIPS) 时, 绑定相应较弱.

A.9. Perfect Forward Secrecy (R-PFS)​

DTLS 支持提供 PFS 的 Diffie-Hellman 与椭圆曲线 Diffie-Hellman 密码套件.

A.10. Algorithm Negotiation (R-COMPUTE)​

DTLS 在进行大量密码运算之前协商密码套件, 因而支持算法协商与多种密码套件且不增加额外计算开销.

A.11. RTP Validity Check (R-RTP-VALID)​

DTLS 分组无法通过 RTP 有效性检查. DTLS 分组首字节为内容类型, 当前所有 DTLS 内容类型的前两位为零, 导致版本字段为零, 因而未通过第一项检查. DTLS 分组亦可与 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 携带的指纹与 DTLS 中交换的证书与密钥管理交换相链接.

A.15. Denial-of-Service Vulnerability (R-DOS)​

DTLS 内置一定程度的拒绝服务 (DoS) 防护 (见 [RFC4347] 第 4.2.1 节).

A.16. Crypto-Agility (R-AGILITY)​

DTLS 允许协商密码套件, 因而可逐步部署新算法. 替换固定 MD5/SHA-1 密钥派生函数的工作仍在进行.

A.17. Downgrading Protection (R-DOWNGRADE)​

DTLS 在握手后续阶段确认所提供的密码套件选择, 因而可防范降级攻击. 除非对手能实时攻破某密码套件, 否则该保护有效. RFC 4474 可阻止信令路径上的主动攻击者将呼叫从 SRTP 降级到 RTP.

A.18. Media Security Negotiation (R-NEGOTIATE)​

DTLS 允许 UA 为每个会话协商媒体安全参数.

A.19. Signaling Protocol Independence (R-OTHER-SIGNALING)​

DTLS-SRTP 框架不依赖 SIP; 任何能交换指纹与媒体描述的协议均可获得安全保护.

A.20. Media Recording (R-RECORDING)​

扩展见 [SIPPING-SRTP], 支持不要求中间人充当 MITM 的媒体录制.

若由中间人录制媒体, 则它们需要充当 MITM.

A.21. Interworking with Intermediaries (R-TRANSCODER)​

要与转码媒体的中间人互通, 转码器必须能访问密钥材料, 并在本文档意义上被视为端点.

A.22. PSTN Gateway Termination (R-PSTN)​

DTLS-SRTP 框架允许媒体安全在 PSTN 网关终止. 这不提供端到端安全, 但与本文档安全目标一致, 因为网关被授权代表 PSTN 命名空间发言.

A.23. R-ALLOW-RTP​

DTLS-SRTP 允许主叫方在已与 answerer 协商 SRTP 之前接收 RTP 媒体, 之后优先使用 SRTP 而非 RTP.

A.24. R-HERFP​

异构错误响应分叉问题 (HERFP) 不适用于 DTLS-SRTP, 因为密钥交换协议沿媒体路径执行, 错误消息沿该路径传递, 代理无需推进它们.

最后于 更新