メインコンテンツまでスキップ

6. セキュリティに関する考慮事項

[RFC3550] のセキュリティに関する考慮事項が本メモに適用されます。

6.1. RTCP CNAME の一意性に関する考慮事項​

このセクションの考慮事項は、ランダムな RTCP CNAME に適用されます。

RTCP CNAME の生成に関して本文書で示されている推奨事項は、RTP セッション内の協調的な参加者のセットが、非常に高い確率で一意の RTCP CNAME を持つことを保証します。しかし、[RFC3550] も本文書も、参加者が適切に RTCP CNAME を選択することを保証する手段を提供していません。したがって、実装は不可欠なセキュリティサービスのために RTCP CNAME の一意性に依存しては「なりません（MUST NOT）」。これは [RFC3550] と一致しています。[RFC3550] では、RTCP CNAME がセッション内で一意であることを要求しておらず、代わりにその条件が満たされる「べきである（SHOULD）」と述べています。[RFC3550] のセキュリティに関する考慮事項のセクションで説明されているように、セッションの各参加者は自身の RTCP CNAME を自由に選択できるため、他の参加者になりすますような方法で選択することができます。つまり、参加者は互いになりすまさないものとして信頼されています。攻撃者は規定を無視することができるため、RTCP CNAME を生成するためのどのような推奨事項も、このなりすましを防ぐことはできません。Secure RTP (SRTP) [RFC3711] は、権限のないエンティティを RTP セッションから排除しますが、権限のあるエンティティからのなりすまし攻撃を防ぐことを目的としたものではありません。

PRNG の特性により、長い RTCP CNAME と短い RTCP CNAME の間に、プライバシーやリンク可能性の面で大きな違いはありません。しかし、一意の RTCP CNAME を生成するという要件は、ある程度の最小の長さを必要とします。96ビットの長さがあれば、衝突の可能性が大きくなる前に、グローバルで 2^{40} 個程度の RTCP CNAME を許容できます（2^{48} 個の RTCP CNAME の後に1つの衝突が発生する確率は約50%です）。

6.2. RTCP CNAME に基づくセッション相関​

以前の RTCP CNAME 生成に関する推奨事項では、固定の RTCP CNAME 値が許可されていました。これにより、攻撃者は個別の RTP セッションを容易にリンクすることができ、IPv6 プライバシーアドレス [RFC4941] や IPv4 ネットワークアドレスポート変換 (NAPT) [RFC3022] によって提供される難読化が損なわれていました。

本仕様では、固定の RTCP CNAME 値を生成する手順はもはや記載されていないため、RTCP CNAME 値によって RTP セッション間のそのようなリンクが提供されることはなくなりました。これは攻撃者によるそのようなリンクを排除するために必要でしたが、当然ながら、トラフィック分析デバイス（例：パケット損や遅延を監視しているデバイス）によるリンクも困難になります。

7. 謝辞

RTCP CNAME の生成に UUID を使用することを提案してくれた Marc Petit-Huguenin に感謝します。また、RFC 6222 のセキュリティに関する考慮事項のセクションのテキストを提供してくれた David McGrew にも感謝します。

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.

に最終更新