3. Motivation (Motivation)

Obwohl es in diesem Bereich bereits Vorarbeit gibt (z. B. Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] in Kombination mit MIKEY [RFC3830] für Authentifizierung und Schlüsselaustausch), wird diese Spezifikation wie folgt motiviert:

o TLS wird genutzt, um Sicherheit für verbindungsorientierte Medien anzubieten. Das TLS-Design ist gut bekannt und Implementierungen sind weit verbreitet.

o Dieser Ansatz behandelt Forking und Early Media, ohne Unterstützung für Provisional Response ACKnowledgement (PRACK) [RFC3262] zu erfordern, und bewahrt die wichtige Sicherheitseigenschaft, dass der Offerer Schlüsselmaterial für die Verschlüsselung der Medien wählen kann.

o Die Einrichtung des Sicherheitsschutzes für den Medienpfad erfolgt ebenfalls entlang des Medienpfads und nicht über den Signalisierungspfad. In vielen Deployment-Szenarien nehmen Signalisierung und Medienverkehr unterschiedliche Pfade durch das Netz.

o Wenn RFC 4474 verwendet wird, funktioniert diese Lösung auch, wenn die SIP-Proxys stromabwärts des Authentifizierungsdienstes nicht vertrauenswürdig sind. Es ist nicht nötig, Schlüssel in der SIP-Signalisierung oder im SDP-Nachrichtenaustausch preiszugeben, wie bei SDDESCRIPTIONS [RFC4568]. Bei Retargeting einer dialogbildenden Anfrage (Änderung des Request-URI) kann der User Agent (UA), der sie empfängt (der User Agent Server, UAS), eine andere Identität haben als im To-Kopffeld. Wenn RFC 4916 verwendet wird, kann seine Identität dem Peer-UA durch eine Anfrage in Gegenrichtung mitgeteilt und von einem Authentication Service signiert werden.

o In dieser Methode führen Kollisionen der Synchronisationsquelle (SSRC) zu keiner zusätzlichen SIP-Signalisierung.

o Viele SIP-Endpunkte implementieren bereits TLS. Die Änderungen an der bestehenden SIP- und RTP-Nutzung sind minimal, auch wenn DTLS-SRTP [RFC5764] verwendet wird.