5. 安全考虑事项

SAVPF profile 从 SAVP profile 继承其安全属性. 因此, 它适用 RFC 3711 [4] 中讨论的安全考虑事项. 与 SAVP 相比, SAVPF profile 既不增加也不减少任何安全服务.

需要同时支持媒体流安全性, 以及与非 SAVP(F) 节点的向后兼容性.

应用设计者应意识到, 安全性 不应该为互操作性让步. 如果信息要分发给封闭组, 即受到机密性保护, 则除非会使用其他安全机制, 例如 RFC 3550 [1] 第 9.1 节中描述的机制, 否则 推荐不为媒体会话提供第 3.3 节和第 3.4 节所述 SAVP 和 SAVPF 之外的替代项. 类似地, 如果认为完整性保护很重要, 则除非已知存在可保证完整性的其他机制, 例如 RFC 3550 [1] 第 9 节所述较低层机制, 否则 推荐不提供 SAVP 和 SAVPF 之外的替代项.

同时提供安全和不安全 profile 可能导致降级攻击. 因此, 不应该提供这种混合 profile offer.

注意, 共享主密钥的规则适用 RFC 3711 [4] 中的描述, 例如第 9.1 节. 特别是, 避免 two-time pad (密钥流重用) 的相同规则也适用: 除非所使用的 SSRC 在共享同一主密钥的 RTP 会话的所有 RTP 流之间唯一, 否则主密钥 不得在不同 RTP 会话之间共享.

当同一密钥已保护 2^48 个 SRTP 数据包或 2^31 个 SRTCP 数据包时, 以先发生者为准, 必须调用密钥管理来提供新的主密钥, 先前存储并使用过的密钥 不得再次使用, 或者 必须终止会话.

不同媒体会话可以混合使用不同 profile, 尤其可能同时包括安全 profile 和不安全 profile. 然而, 混合安全和不安全媒体会话可能向第三方泄露信息, 因此这样做的决定 必须符合本地安全策略. 例如, 本地策略 必须指明是否可以接受音频流不受保护而相关视频受保护这类情况.

RFC 4585 [3] 中的安全考虑事项同样有效. 尤其要注意, 应用 SAVPF profile 意味着对 RTCP 强制进行完整性保护. 这虽然解决了不属于该组的成员发送伪造数据包的问题, 但无法解决恶意成员行为不当带来的问题.