Zum Hauptinhalt springen

6. Sicherheitsüberlegungen

Die Sicherheitsüberlegungen von [RFC3550] gelten für dieses Memorandum.

6.1. Überlegungen zur Eindeutigkeit von RTCP CNAMEs​

Die Überlegungen in diesem Abschnitt gelten für zufällige RTCP CNAMEs.

Die in diesem Dokument gegebenen Empfehlungen für die Generierung von RTCP CNAMEs stellen sicher, dass eine Gruppe kooperierender Teilnehmer in einer RTP-Sitzung mit sehr hoher Wahrscheinlichkeit eindeutige RTCP CNAMEs haben wird. Weder [RFC3550] noch dieses Dokument bieten jedoch eine Möglichkeit, sicherzustellen, dass die Teilnehmer die RTCP CNAMEs angemessen wählen; daher DÜRFEN (MUST NOT) Implementierungen nicht auf die Eindeutigkeit von RTCP CNAMEs für wesentliche Sicherheitsdienste vertrauen. Dies steht im Einklang mit [RFC3550], das nicht verlangt, dass RTCP CNAMEs innerhalb einer Sitzung eindeutig sind, sondern besagt, dass diese Bedingung erfüllt sein SOLLTE (SHOULD). Wie im Abschnitt Sicherheitsüberlegungen von [RFC3550] beschrieben, steht es jedem Teilnehmer einer Sitzung frei, seinen eigenen RTCP CNAME zu wählen, und er kann dies so tun, dass er sich als ein anderer Teilnehmer ausgibt. Das heißt, es wird darauf vertraut, dass sich die Teilnehmer nicht gegenseitig ausgeben. Keine Empfehlung für die Generierung von RTCP CNAMEs kann diese Identitätstäuschung verhindern, da ein Angreifer die Bestimmung missachten kann. Secure RTP (SRTP) [RFC3711] hält unbefugte Einheiten von einer RTP-Sitzung fern, zielt aber nicht darauf ab, Angriffe durch Identitätsvortäuschung von autorisierten Einheiten zu verhindern.

Aufgrund der Eigenschaften des PRNG gibt es keinen signifikanten Unterschied in Bezug auf Privatsphäre/Verknüpfbarkeit zwischen langen und kurzen RTCP CNAMEs. Die Anforderung, eindeutige RTCP CNAMEs zu generieren, impliziert jedoch eine gewisse Mindestlänge. Eine Länge von 96 Bits ermöglicht in der Größenordnung von 2^{40} RTCP CNAMEs weltweit, bevor eine nennenswerte Kollisionswahrscheinlichkeit besteht (die Wahrscheinlichkeit für eine Kollision nach 2^{48} RTCP CNAMEs liegt bei etwa 50 %).

6.2. Sitzungskorrelation basierend auf RTCP CNAMEs​

Frühere Empfehlungen für die Generierung von RTCP CNAME erlaubten einen festen RTCP-CNAME-Wert, was es einem Angreifer ermöglichte, separate RTP-Sitzungen einfach zu verknüpfen. Dadurch wurde die durch IPv6-Privacy-Adressen [RFC4941] oder IPv4 Network Address Port Translation (NAPT) [RFC3022] bereitgestellte Verschleierung zunichtegemacht.

Diese Spezifikation beschreibt kein Verfahren mehr zur Generierung fester RTCP-CNAME-Werte, sodass RTCP-CNAME-Werte keine solche Verknüpfung zwischen RTP-Sitzungen mehr bieten. Dies war notwendig, um eine solche Verknüpfung durch einen Angreifer zu eliminieren, erschwert aber natürlich die Verknüpfung durch Verkehrsanalysgeräte (z. B. Geräte, die nach verlorenen oder verzögerten Paketen suchen).

7. Danksagungen

Vielen Dank an Marc Petit-Huguenin, der vorgeschlagen hat, UUIDs bei der Generierung von RTCP CNAMEs zu verwenden. Außerdem vielen Dank an David McGrew für die Bereitstellung des Textes für den Abschnitt Sicherheitsüberlegungen in RFC 6222.

8. Referenzen

8.1. Normative Referenzen​

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

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

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

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

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

8.2. Informative Referenzen​

  • [RFC6222] Begen, A., Perkins, C., und 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., und E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, Februar 1996.

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

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

  • [RFC4941] Narten, T., Draves, R., und 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. und E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, Mai 2010.

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

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

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

Letztes Update am