Skip to main content

3. SRTP Extension for DTLS

3. SRTP Extension for DTLS​

This section describes the DTLS extension for establishing SRTP keying material, algorithms, and parameters.

3.1 The use_srtp Extension​

In order to negotiate the use of SRTP data protection, clients include an extension of type "use_srtp" in the DTLS extended client hello. This extension MUST only be used when the data being transported is RTP or RTCP. The "extension_data" field of this extension contains the list of acceptable SRTP protection profiles. The use_srtp extension also indicates the MKI (Master Key Identifier) that the client will use in the SRTP packets or for SRTP packets it receives.

The extension format is:

uint8 SRTPProtectionProfile[2];

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

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

The SRTPProtectionProfile values are defined in Section 3.1. If the server is willing to accept the use_srtp extension, it MUST respond with its own use_srtp extension in the DTLS extended server hello. The server's list MUST contain exactly one SRTPProtectionProfile value, which MUST be one of the values offered by the client.

3.2 Certificate Choice​

DTLS allows the server to send a certificate_request message. If the client has no suitable certificate, it MUST send an empty certificate message in response. When using DTLS-SRTP, the client SHOULD use a certificate that is appropriate for use with DTLS. Since media path DTLS does not use the signaling channel's security context, the certificate used for DTLS SHOULD be different from any certificate used by the signaling protocol.

3.3 Key Derivation​

When DTLS-SRTP is used, DTLS acts as the key derivation function for SRTP. The TLS PRF is used to derive the necessary keying material as follows:

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

The keying material is then split into the necessary SRTP encryption keys, authentication keys, and salting keys for both directions (client-to-server and server-to-client) as defined by the selected SRTP protection profile.

3.4 Key Scope​

Each DTLS-SRTP session protects a single RTP/RTCP source. A single DTLS-SRTP session can be used to protect multiple RTP streams or RTCP packets going in one direction between two endpoints, so long as all the media shares the same SSRC. However, when conference calls involve multiple sources, each with a different SSRC, a separate DTLS session MUST be used per SSRC.

3.5 Key Usage Limitations​

The keys derived from DTLS MUST only be used for protecting RTP and RTCP traffic that is transported over the same 5-tuple (source IP, source UDP port, destination IP, destination UDP port, and protocol). If traffic is to be sent over a different 5-tuple, a new DTLS handshake MUST be performed.

Last updated on