Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
updated by
Extracted elements (29)
Because DTLS is point-to-point, conference bridges using DTLS-SRTP cannot share a single encryption context; each bridge-to-participant flow uses independent keys, requiring the bridge to decrypt and re-encrypt all traffic for each recipient. A future specification could define key-sharing for conferencing systems that do not modify media.
DTLS-SRTP was designed so that RTP/RTCP application data is protected by SRTP (optimized for real-time media) rather than by the generic DTLS record-layer, while the DTLS handshake provides integrated key management and algorithm negotiation. This combines SRTP's per-packet efficiency with DTLS's flexible and convenient key-management infrastructure.
RTP and RTCP MAY be multiplexed on a single UDP port (RFC 5761), halving the number of DTLS-SRTP sessions required and improving cryptographic performance. However, this may cause problems when RTP and RTCP are subject to different network treatment such as bandwidth reservation or QoS scheduling.
Data other than RTP/RTCP (i.e., DTLS control messages) MUST use ordinary DTLS framing and MUST be placed in separate datagrams from SRTP data.
DTLS-SRTP implementations SHOULD store multiple SRTP key sets during a rekey event to avoid dropping packets that arrive reordered and were encrypted with the prior key set.
If the client receives a nonzero-length MKI in the server's use_srtp response that differs from the one the client offered, the client MUST abort the handshake and SHOULD send an invalid_parameter alert.
Implementations SHOULD use DTLS session resumption to amortize public-key operations across multiple media channels: establish the first DTLS association fully, then allow subsequent associations to proceed using session resumption.
Symmetric RTP (RFC 4961) is RECOMMENDED for use with DTLS-SRTP, as it allows a single DTLS-SRTP session to protect both the inbound and outbound RTP sessions on a port pair.
The server MUST NOT select an SRTPProtectionProfile value the client did not offer. If no shared profile exists, the server SHOULD NOT return the use_srtp extension (causing fallback to the negotiated DTLS cipher suite); if that is unacceptable, the server SHOULD return an appropriate DTLS alert.
The SRTP implementation MUST ensure all SSRC values for RTP sources originating from the same device over the same channel are distinct, to avoid the 'two-time pad' problem described in RFC 3711 Section 9.1.
The use_srtp extension MUST only be used with DTLS and MUST NOT be used with TLS over TCP (as specified in RFC 4572).
There MUST be a separate DTLS-SRTP session for each distinct source/destination port pair used by a media session, though multiple DTLS-SRTP sessions may share a single underlying DTLS association via session resumption.
When an MKI is established in a DTLS-SRTP session, it MUST apply uniformly to all SSRCs within that session. This differs from RFC 3711, which permits different SSRCs within the same session to use MKIs differently.
When the maximum_lifetime packet count for an SRTP profile is reached, a new DTLS session SHOULD be established for replacement keys, and implementations MUST NOT use the exhausted keys for processing any outbound or inbound traffic.
Within each RTP session, SRTP processing MUST NOT take place before the DTLS handshake completes.
Four SRTP protection profiles are defined: SRTP_AES128_CM_HMAC_SHA1_80 (0x0001), SRTP_AES128_CM_HMAC_SHA1_32 (0x0002), SRTP_NULL_HMAC_SHA1_80 (0x0005), and SRTP_NULL_HMAC_SHA1_32 (0x0006). All profiles use a 112-bit salt, HMAC-SHA1 authentication, and a maximum lifetime of 2^31 packets; the NULL profiles omit encryption.
Rekeying is performed by executing a new DTLS handshake over the existing channel while data transport continues in parallel. Receivers SHOULD maintain both old and new key sets for the maximum segment lifetime to correctly handle reordered packets protected by the old keys. If MKI is in use, the receiver uses the MKI to select the key set; otherwise it tries the new keys first and falls back to the old ones on authentication failure.
SRTP keying material is derived via a TLS exporter (RFC 5705) with the label 'EXTRACTOR-dtls_srtp' and an empty per-association context. The exporter produces four values — client_write_SRTP_master_key, server_write_SRTP_master_key, client_write_SRTP_master_salt, and server_write_SRTP_master_salt — which are fed into the SRTP KDF to produce independent encrypt/authenticate keys for each direction.
The use_srtp DTLS extension allows peers to negotiate SRTP protection during the DTLS handshake. The client includes a list of acceptable SRTP protection profiles in the ClientHello extended hello; the server responds with a single chosen profile. Once negotiated, RTP/RTCP application data is protected solely using SRTP rather than the DTLS record-layer encoding.
To handle SIP forking, the implementation maintains a per-endpoint table mapping SSRCs to DTLS-SRTP associations. For an unknown SSRC, the receiver tries each known association; on successful authentication the SSRC is recorded. Entries MUST be removed when the corresponding DTLS-SRTP association is closed.
IANA created the 'DTLS SRTPProtectionProfile' registry, initially populated with SRTP_AES128_CM_HMAC_SHA1_80 (0x0001), SRTP_AES128_CM_HMAC_SHA1_32 (0x0002), SRTP_NULL_HMAC_SHA1_80 (0x0005), and SRTP_NULL_HMAC_SHA1_32 (0x0006). Future allocations require 'Specification Required' policy per RFC 5226.
The label 'EXTRACTOR-dtls_srtp' is registered in the TLS Extractor Label Registry for use as the exporter label when deriving SRTP master keys and salts. The 'EXTRACTOR' prefix is retained for historical compatibility.
The use_srtp extension is registered with ExtensionType value 14 for DTLS only. Four new SDP proto tokens are registered: UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, and DCCP/TLS/RTP/SAVPF.
A bid-down attack attempting to force use of plain DTLS instead of SRTP is automatically detected because use_srtp negotiation is covered by the DTLS Finished messages. The attack degrades to a denial-of-service rather than an undetected downgrade.
An attacker can impose extra decryption cost by injecting packets with unknown SSRCs, forcing the receiver to attempt decryption against each active DTLS-SRTP association. Under such attack, implementations SHOULD prioritize packets from known SSRCs or source addresses matching established peers.
During rekeying without MKI, the receiver must try multiple key sets, weakening authentication by log_2(k) bits (where k is the number of active key sets). With the default 80-bit SRTP MAC and a very small k, this reduction is negligible in practice.
Framing confusion — treating an SRTP-framed RTP packet as a DTLS record or vice versa — is prevented by using separate MAC keys for each content type. The DTLS record type is also included in the MAC, so an injected SRTP record would be treated as an unknown type and silently ignored.
Incoming packets on a DTLS-SRTP port are demultiplexed by examining the first byte B: B < 2 → STUN; 19 < B < 64 → DTLS; 127 < B < 192 → RTP (or RTCP if multiplexed). Values outside these ranges are unspecified and designers SHOULD ensure additional packet types can also be distinguished.
The UseSRTPData structure in the use_srtp extension contains a SRTPProtectionProfiles list (2 to 2^16-1 bytes, each profile is a 2-byte uint8[2]) ordered by descending preference, followed by an srtp_mki field (0 to 255 bytes). A zero-length srtp_mki indicates no MKI will be used.