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).