DTLS Extension to Establish Keys for SRTP

Description

DTLS-SRTP is a key establishment protocol that combines Datagram Transport Layer Security (DTLS) with the Secure Real-time Transport Protocol (SRTP). Its primary function is to perform a authenticated key exchange, leveraging the DTLS handshake, to generate the master key and salt material used to key SRTP and SRTCP cryptographic contexts. The protocol is defined in IETF RFC 5764 and is a cornerstone for media security in 3GPP's IP Multimedia Subsystem (IMS) and WebRTC frameworks. It operates by extending the standard DTLS handshake: during the handshake completion, the peers exchange "use_srtp" extension data that lists supported SRTP protection profiles and, optionally, MIKEY keying material.

The architecture involves the two endpoints of a media session, such as two User Equipment (UE) devices or a UE and a media gateway. They first establish a DTLS association over the same UDP ports intended for the subsequent SRTP media flow. The DTLS handshake authenticates the endpoints (often using certificates) and derives a master secret. From this DTLS master secret, keying material for SRTP is exported using a key derivation function defined in RFC 5705. This yields the SRTP master key, master salt, and key derivation rate, which are then used to initialize the SRTP cryptographic context for encrypting and authenticating RTP/RTCP packets.

How it works can be summarized in a sequence: 1) Session negotiation via SIP/SDP indicates support for DTLS-SRTP and fingerprints of DTLS certificates. 2) The initiating endpoint acts as the DTLS client and initiates a handshake to the responder's IP address and port. 3) The handshake completes, authenticating the endpoints via certificate verification against the SDP fingerprints. 4) Keying material is exported from the established DTLS session. 5) SRTP and SRTCP streams begin, using the derived keys for encryption (e.g., AES_CM_128) and authentication (e.g., HMAC_SHA1_80). This mechanism provides full end-to-end media encryption between the endpoints, as the keys are not accessible to intermediate network elements like Media Gateways, unless specifically designed for lawful interception.

Purpose & Motivation

DTLS-SRTP was created to solve the problem of establishing secure keys for SRTP sessions in a scalable, standardised, and firewall-friendly manner. Previous methods for SRTP keying, such as Security Descriptions (SDES) in SDP, transmitted keys in the clear within signaling messages, requiring the signaling path to be highly trusted and secured (e.g., via IPsec). This was a significant limitation, especially in architectures where signaling intermediaries should not have access to media keys.

The motivation for DTLS-SRTP stemmed from the WebRTC project's requirement for mandatory encryption and the desire for a key agreement protocol that worked peer-to-peer. DTLS was a natural fit because it runs over UDP (like RTP/RTCP), can traverse NATs and firewalls using ICE, and provides strong authentication. By piggybacking on the DTLS handshake, DTLS-SRTP provides a unified solution for authenticating the data channel (if used) and establishing media keys, simplifying the security architecture. In 3GPP, its adoption from Release 12 onwards was driven by the need for robust, end-to-end secured voice and video services over LTE (VoLTE, ViLTE) and for integrating WebRTC clients into the IMS ecosystem, ensuring a consistent and high-security bar for real-time communications.

Key Features

• Uses DTLS handshake for authenticated key exchange over UDP
• Derives SRTP keys directly from the DTLS master secret
• Provides true end-to-end encryption for media, independent of signaling path security
• Supports mutual authentication typically via X.509 certificates
• Integrates with NAT traversal mechanisms like ICE and STUN
• Defined SRTP protection profiles for AES-CM and AES-GCM encryption

Evolution Across Releases

Defining Specifications