3. SRTP-Erweiterung für DTLS

Dieser Abschnitt beschreibt die DTLS-Erweiterung zur Etablierung von SRTP-Schlüsselmaterial, Algorithmen und Parametern.

3.1 Die use_srtp-Erweiterung

Um die Verwendung des SRTP-Datenschutzes auszuhandeln, fügen Clients eine Erweiterung vom Typ "use_srtp" in das erweiterte DTLS-Client-Hello ein. Diese Erweiterung DARF nur verwendet werden, wenn die transportierten Daten RTP oder RTCP sind. Das "extension_data"-Feld dieser Erweiterung enthält die Liste der akzeptablen SRTP-Schutzprofile. Die use_srtp-Erweiterung zeigt auch den MKI (Master Key Identifier, Master-Schlüssel-Identifikator) an, den der Client in den SRTP-Paketen verwenden wird oder für SRTP-Pakete, die er empfängt.

Das Erweiterungsformat ist:

uint8 SRTPProtectionProfile[2];

struct {
    SRTPProtectionProfiles SRTPProtectionProfiles;
    opaque srtp_mki<0..255>;
} UseSRTPData;

SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;

Die SRTPProtectionProfile-Werte sind in Abschnitt 3.1 definiert. Wenn der Server bereit ist, die use_srtp-Erweiterung zu akzeptieren, MUSS er mit seiner eigenen use_srtp-Erweiterung im erweiterten DTLS-Server-Hello antworten. Die Liste des Servers MUSS genau einen SRTPProtectionProfile-Wert enthalten, der einer der vom Client angebotenen Werte sein MUSS.

3.2 Zertifikatswahl

DTLS erlaubt dem Server, eine certificate_request-Nachricht zu senden. Wenn der Client kein geeignetes Zertifikat hat, MUSS er als Antwort eine leere Zertifikatsnachricht senden. Bei Verwendung von DTLS-SRTP SOLLTE der Client ein Zertifikat verwenden, das für die Verwendung mit DTLS geeignet ist. Da Medienpfad-DTLS den Sicherheitskontext des Signalisierungskanals nicht verwendet, SOLLTE das für DTLS verwendete Zertifikat von jedem vom Signalisierungsprotokoll verwendeten Zertifikat verschieden sein.

3.3 Schlüsselableitung

Bei Verwendung von DTLS-SRTP fungiert DTLS als Schlüsselableitungsfunktion für SRTP. Die TLS-PRF wird verwendet, um das erforderliche Schlüsselmaterial wie folgt abzuleiten:

keying material = PRF(master_secret, "EXTRACTOR-dtls_srtp",
                      client_random + server_random)

Das Schlüsselmaterial wird dann in die erforderlichen SRTP-Verschlüsselungsschlüssel, Authentifizierungsschlüssel und Salting-Schlüssel für beide Richtungen (Client-zu-Server und Server-zu-Client) aufgeteilt, wie vom ausgewählten SRTP-Schutzprofil definiert.

3.4 Schlüsselumfang

Jede DTLS-SRTP-Sitzung schützt eine einzelne RTP/RTCP-Quelle. Eine einzelne DTLS-SRTP-Sitzung kann verwendet werden, um mehrere RTP-Streams oder RTCP-Pakete zu schützen, die in eine Richtung zwischen zwei Endpunkten gehen, solange alle Medien dieselbe SSRC teilen. Wenn Konferenzanrufe jedoch mehrere Quellen mit jeweils einer anderen SSRC umfassen, MUSS eine separate DTLS-Sitzung pro SSRC verwendet werden.

3.5 Einschränkungen der Schlüsselverwendung

Die von DTLS abgeleiteten Schlüssel DÜRFEN nur zum Schutz von RTP- und RTCP-Verkehr verwendet werden, der über dasselbe 5-Tupel (Quell-IP, Quell-UDP-Port, Ziel-IP, Ziel-UDP-Port und Protokoll) transportiert wird. Wenn Verkehr über ein anderes 5-Tupel gesendet werden soll, MUSS ein neuer DTLS-Handshake durchgeführt werden.