跳到主要内容

6. 安全考虑

[RFC3550] 的安全考虑适用于本备忘录.

6.1. RTCP CNAME 唯一性考虑​

本节中的考虑适用于随机 RTCP CNAME.

本文档给出的 RTCP CNAME 生成建议确保 RTP 会话中的一组协作参与者将以非常高的概率拥有唯一 RTCP CNAME. 但是, [RFC3550] 和本文档都没有提供任何方法来确保参与者会适当地选择 RTCP CNAME; 因此, 实现不得 (MUST NOT) 依赖 RTCP CNAME 的唯一性来提供任何必要安全服务. 这与 [RFC3550] 一致, 后者并不要求 RTCP CNAME 在会话内唯一, 而是说该条件应当 (SHOULD) 成立. 如 [RFC3550] 安全考虑一节所述, 由于会话中的每个参与者都可以自由选择自己的 RTCP CNAME, 它们可以用这种方式冒充另一个参与者. 也就是说, 假定参与者不会相互冒充. 任何 RTCP CNAME 生成建议都无法防止这种冒充, 因为攻击者可以忽略规定. 安全 RTP (Secure RTP, SRTP) [RFC3711] 可将未授权实体排除在 RTP 会话之外, 但它并不旨在防止来自授权实体的冒充攻击.

由于 PRNG 的性质, 长 RTCP CNAME 和短 RTCP CNAME 之间没有显著的隐私/可关联性差异. 但是, 生成唯一 RTCP CNAME 的要求意味着需要某个最小长度. 96 位长度允许全局约 2^{40} 个 RTCP CNAME, 然后才会出现较大的冲突概率 (约在 2^{48} 个 RTCP CNAME 后有 50% 概率出现一次冲突).

6.2. 基于 RTCP CNAME 的会话关联​

早期 RTCP CNAME 生成建议允许固定 RTCP CNAME 值, 这使攻击者能够轻易关联不同 RTP 会话, 从而消除 IPv6 隐私地址 [RFC4941] 或 IPv4 网络地址端口转换 (Network Address Port Translation, NAPT) [RFC3022] 所提供的混淆效果.

本规范不再描述生成固定 RTCP CNAME 值的过程, 因此 RTCP CNAME 值不再在 RTP 会话之间提供此类关联. 这对于消除攻击者进行这种关联是必要的, 但当然会使流量分析设备 (例如查找丢包或延迟包的设备) 进行关联变得更复杂.

7. 致谢

感谢 Marc Petit-Huguenin, 他建议在生成 RTCP CNAME 时使用 UUID. 也感谢 David McGrew 为 RFC 6222 的安全考虑一节提供文本.

8. 参考文献

8.1. 规范性参考文献​

  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

  • [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

8.2. 资料性参考文献​

  • [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.

  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

  • [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

  • [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.

  • [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

  • [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

  • [ARCH] Rescorla, E., "WebRTC Security Architecture", Work in Progress, July 2013.

  • [RESCORLA] Rescorla, E., "Random algorithm for RTP CNAME generation", Work in Progress, July 2012.

最后于 更新