6. Miscellaneous Considerations (Sonstige Überlegungen)
6.1. Anonyme Anrufe
DTLS-SRTP bietet keinen anonymen Anruf; es verhindert ihn aber auch nicht. Wenn bei anonymen Anruffunktionen wie in [RFC3325] oder [RFC5767] beschrieben nicht aufgepasst wird, kann DTLS-SRTP die Deanonymisierung eines sonst anonymen Anrufs ermöglichen. Bei anonymen Anrufen SHOULD folgende Verfahren angewendet werden, um Deanonymisierung zu vermeiden.
Bei anonymen Anrufen SHOULD für jeden Anruf ein neues selbstsigniertes Zertifikat verwendet werden, damit Anrufe nicht als vom selben Anrufer korreliert werden können. Wo ein gewisses Maß an Korrelation akzeptabel ist, SHOULD dasselbe Zertifikat für mehrere Anrufe genutzt werden, um Authentifizierungskontinuität zu ermöglichen; siehe Abschnitt 8.4.
Außerdem gilt: In Netzen mit [RFC3325] verlangt RFC 3325, dass der Privacy-Kopfwert aus [RFC3323] auf „id“ gesetzt wird. Das dient zusammen mit SIP Identity dazu, die Nutzeridentität bei anonymen Anrufen nicht zu assertieren. Der Inhalt des subjectAltName-Attributs im Zertifikat MUST NOT Informationen enthalten, die Korrelation oder Identifikation des anonym anrufenden Nutzers ermöglichen. Diese Empfehlung allein reicht nicht für Anonymisierung.
6.2. Early Media
Empfängt ein Endpunkt ein Angebot und will Early Media liefern, MUST er die Rolle setup:active übernehmen und kann sofort eine DTLS-Assoziation mit dem anderen Endpunkt aufbauen und Medien senden. Der setup:passive-Endpunkt hat den Fingerprint des aktiven Zertifikats ggf. noch nicht validiert. Sicherheitsaspekte in diesem Fall siehe Abschnitt 8.
6.3. Forking
In SIP kann eine Anfrage zu mehreren Endpunkten forken. Jede geforkte Anfrage kann eine andere Antwort ergeben. Unter der Annahme, der Anforderer hat ein Angebot geliefert, liefert jeder Antwortende eine eindeutige Antwort. Jeder Antwortende bildet eine DTLS-Assoziation mit dem Offerer. Der Offerer kann dann die in der SIP-Nachricht empfangene SDP-Antwort sicher korrelieren, indem er den Fingerprint in der Antwort mit dem Hash des Zertifikats je DTLS-Assoziation vergleicht.
6.4. Verzögerte Angebots-Anrufe
Ein Endpunkt kann eine SIP-INVITE ohne Angebot senden. Dann liefern die Empfänger das Angebot in der Antwort und der Ursprung liefert die Antwort im folgenden ACK oder in der PRACK-Anfrage [RFC3262], wenn beide Endpunkte zuverlässige vorläufige Antworten unterstützen. In jedem Fall etabliert der aktive Endpunkt weiterhin die DTLS-Assoziation mit dem passiven Endpunkt wie im Offer/Answer ausgehandelt.
6.5. Mehrere Assoziationen
Gibt es mehrere Flüsse (z. B. mehrere Mediaströme, nicht gemultiplextes RTP und RTCP usw.), MAY die aktive Seite die DTLS-Handshakes in beliebiger Reihenfolge ausführen. Anhang B von [RFC5764] gibt Hinweise zu parallelen DTLS-Handshakes. Wird der Antwortende aktiv, kann er Handshakes nur auf einer Teilmenge der möglichen Ströme starten (z. B. nur Audio, obwohl Audio und Video angeboten wurden). Ist der Offerer aktiv, trifft die vollständige Antwort ein, bevor der Offerer Handshakes initiiert.
6.6. Sitzungsänderung
Nachdem eine Antwort dem Offerer gegeben wurde, MAY jeder Endpunkt eine Sitzungsänderung anfordern, die MAY ein aktualisiertes Angebot enthält. Die Änderung kann in INVITE oder UPDATE transportiert werden. Peers können bestehende Assoziationen wiederverwenden, wenn sie kompatibel sind (gleiche Schlüsselfingerprints und Transportparameter), oder eine neue gemäß denselben Regeln wie beim Erstkontakt etablieren und die bestehende Assoziation nach Abschluss des Offer/Answer abbauen. Ändert sich der aktive/passive Status der Endpunkte, MUST eine neue Verbindung aufgebaut werden.
6.7. Middlebox-Interaktion
Es gibt mehrere potenziell schädliche Wechselwirkungen zwischen DTLS-SRTP und Middleboxes, dokumentiert in [MMUSIC-MEDIA], mit Empfehlungen zur Vermeidung.
6.7.1. ICE-Interaktion
Interactive Connectivity Establishment (ICE) gemäß [RFC5245] ermöglicht es Teilnehmern, gegenseitige Erreichbarkeit zu prüfen. Bei ICE erfolgen die ICE-Connectivity-Checks vor Beginn des DTLS-Handshakes. Im aggressiven Nominationsmodus können mehrere Kandidatenpaare gültig sein, bevor ICE auf ein Paar konvergiert. Implementierungen MUST alle ICE-Kandidatenpaare einer Komponente als Teil derselben DTLS-Assoziation behandeln. Es gibt also nur einen DTLS-Handshake, auch bei mehreren gültigen Paaren. Endpunkt-IP-Adressen können angepasst werden, wenn sich das gewählte Paar ändert, wie bei normalem Medienstrom.
STUN-Pakete gehen direkt über UDP, nicht über DTLS. [RFC5764] beschreibt Demultiplexing von STUN, DTLS und SRTP.
6.7.2. Latching ohne ICE
Ohne ICE droht eine problematische Interaktion mit SBCs über „Latching“, siehe [MMUSIC-MEDIA]. Ohne ICE und wenn der DTLS-Handshake beim Empfang des SDP der Gegenseite noch nicht abgeschlossen ist, MUST die passive Seite einen einzelnen unauthentifizierten STUN-[RFC5389]-Connectivity-Check ausführen, um das Pinhole zu öffnen. Alle Implementierungen MUST während der Handshake-Phase auf diese Anfrage antworten können, auch ohne ICE. Die aktive Seite MUST den DTLS-Handshake dennoch fortführen, auch ohne solchen STUN-Check; die passive Seite MUST NOT auf eine STUN-Antwort warten, bevor sie ServerHello sendet.
6.8. Rekeying
Wie bei TLS können DTLS-Endpunkte jederzeit durch erneuten DTLS-Handshake rekeyen. Während des Rekeys nutzen die Endpunkte weiter das zuvor etablierte Schlüsselmaterial für DTLS. Nach etablierten neuen Sitzungsschlüsseln kann auf diese gewechselt und alte verworfen werden, ohne zusätzliche Latenz.
Weitere Überlegungen zum Rekeying bei SRTP-Sicherheitskontext über DTLS: Abschnitt 3.7 von [RFC5764].
6.9. Konferenzserver und geteilte Verschlüsselungskontexte
Vorgeschlagen wurde, dass Konferenzserver denselben Verschlüsselungskontext für alle Teilnehmer nutzen. Vorteil: Ausgabe muss nur einmal für alle Sprecher verschlüsselt werden, nicht pro Teilnehmer.
Unter dieser Spezifikation ist das nicht möglich, da jeder DTLS-Handshake frische Schlüssel etabliert, die nicht vollständig einer Seite unterliegen. Der Aufwand pro RTP-Paket gilt jedoch als gering gegenüber anderen Aufgaben wie Codec-Verarbeitung.
Künftige Erweiterungen wie [SRTP-EKT] oder [KEY-TRANSPORT] könnten das gemeinsam mit den hier beschriebenen Mechanismen ermöglichen.
6.10. Medien über SRTP
DTLS-Datenübertragung ist generisch und weniger für RTP optimiert als SRTP [RFC3711], das dafür ausgelegt ist. DTLS-SRTP [RFC5764] verhandelt SRTP-Transport über DTLS und verbindet SRTP-Leistung mit einfacher DTLS-Schlüsselverwaltung. Wiederverwendung bestehender SRTP-SW/HW kann zusätzlich motivieren. Implementierungen dieser Spezifikation MUST DTLS-SRTP [RFC5764] unterstützen.
6.11. Best-Effort-Verschlüsselung
[RFC5479] beschreibt Best-Effort-Verschlüsselung: SRTP wenn beide Endpunkte es unterstützen und Schlüsselverhandlung gelingt, sonst RTP.
[MMUSIC-SDP] kann RTP und SRTP alternativ signalisieren. Der Offerer kann SRTP bevorzugen; RTP ist Default für Endpunkte ohne SRTP/diesen Schlüsselaustausch. Implementierungen dieses Dokuments MUST [MMUSIC-SDP] unterstützen.