Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
Extracted elements (25)
AES-GCM is chosen as the RECOMMENDED algorithm for both inner and outer transforms because it provides authenticated encryption; using it twice adds 32 octets of overhead (16 per application) plus 1-4 octets for the OHB, which is considered an acceptable trade-off for the security model.
Double encryption is introduced so a Media Distributor (MD) can modify certain RTP header fields (PT, SEQ, marker bit) while endpoints still verify end-to-end integrity and confidentiality of the payload. The MD holds only the outer (hop-by-hop) key and never learns the inner (end-to-end) key.
Header extensions are excluded from the inner (E2E) integrity protection so that an MD holding only the outer key can modify them freely. This is an explicit design choice accepting weaker E2E protection for header extensions in exchange for MD flexibility.
RED (RFC 2198) must be used end-to-end when double encryption is in use; the MD cannot synthesize RED packets because it has no access to plaintext media payloads. FlexFEC is recommended as a superior alternative because it allows MD-side synthesis of recovery packets.
After successful double-decryption, the application MUST use only information from the synthetic (inner) SRTP packet, with the specific exceptions that PT from the outer packet is used for SDP/codec selection and SEQ from the outer packet is used for RTP ordering.
All RTP header fields other than PT, SEQ, and the marker bit MUST remain unmodified by the MD, because the OHB cannot carry their original values and the receiver would be unable to verify end-to-end integrity.
If an RTP packet being encrypted has header extensions, they MUST use the RFC 8285 general mechanism.
The transforms defined in this document MUST be used with the PRF_double pseudorandom function to allow inner and outer keys to be managed independently via the master key.
To avoid nonce reuse, the cryptographic contexts used for decryption and re-encryption by the MD MUST use different, independent master keys. The MD MUST NOT re-encrypt using the sender's keys and MUST use an independent key for each recipient.
When encrypting or decrypting RTP header extensions hop-by-hop (in encryption, relay, or decryption steps), RFC 6904 MUST be used.
When using FlexFEC (RFC 8627) with the double transform, repair packets MUST be constructed by first double-encrypting the source packet, then performing FEC over the ciphertext. The FEC repair packet itself MUST then be encrypted with only the outer hop-by-hop transform.
When using RTX (RFC 4588) with the double transform, cached payloads MUST be the fully double-encrypted packets as sent on the wire, and retransmission packets MUST be encrypted in repair mode (hop-by-hop key only).
A custom PRF for key derivation is required: PRF_double_n(k_master, x) = PRF_(n/2)(inner(k_master), x) || PRF_(n/2)(outer(k_master), x). This preserves independent management of inner and outer keys from a single master key; AES_CM PRF is used for 128-bit and AES_256_CM_PRF for 256-bit variants.
An MD relaying a packet decrypts the outer layer, optionally modifies PT, SEQ, or marker bit, updates the OHB to record original values of any newly changed fields (and MAY drop OHB entries for fields restored to original), then re-encrypts with the outer key. Header extensions may be modified without OHB reflection.
Decryption first applies the outer key; on success, the receiver strips the inner authentication tag and OHB from the payload, forms a synthetic packet by replacing header fields with OHB values and removing extensions, then applies the inner key. The application MUST use only the synthetic packet's fields, except it uses PT and SEQ from the outer packet for SDP matching and RTP ordering respectively.
Encryption applies the inner (E2E) algorithm to a synthetic RTP packet with the X bit cleared and extensions removed, appends an empty OHB (0x00) after the inner ciphertext and tag, restores the original header, then applies the outer (hop-by-hop) algorithm to the full packet. Repair-mode packets skip the inner step.
Keys and salts are split: the first half of the combined key and salt drives the inner (end-to-end) algorithm, and the second half drives the outer (hop-by-hop) algorithm. SSRC is shared between both algorithms; sequence number (SEQ) and rollover counter (ROC) are tracked independently for each.
RTCP is encrypted using only the outer (hop-by-hop) cryptographic key following standard RFC 3711 procedures. No end-to-end encryption layer is applied to RTCP.
The cryptographic context has two parts: an inner (end-to-end) part used by originating and consuming endpoints to protect media integrity across the full path, and an outer (hop-by-hop) part used between endpoints and the MD. RTCP is protected only by the hop-by-hop part.
Two new DTLS-SRTP protection profiles are registered in the 'DTLS-SRTP Protection Profiles' registry (RFC 5764): DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM assigned value {0x00, 0x09} (256-bit key, 192-bit salt, 256-bit AEAD tag) and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM assigned value {0x00, 0x0A} (512-bit key, 192-bit salt, 256-bit AEAD tag).
An MD decrypting and re-encrypting with the same key and salt causes reuse of a (key, nonce) pair with two different plaintexts, which substantially degrades AES-GCM security. The MD must treat its relationship with sender and receiver as independent AES-GCM sessions with distinct keys.
Because the transforms are symmetric, the double transform provides no protection against attacks from within the conference group; any group member can generate valid SRTP packets for any SSRC in use by the group.
Header extensions in the outer packet are not protected end-to-end. Implementations SHOULD reject RTP packets containing header extensions that would require end-to-end protection, as the MD can modify or forge them.
The OHB Config octet has the bit layout R R R R B M P Q: P indicates PT is present, Q indicates SEQ is present, M indicates the marker bit is present, B carries the original marker bit value, and R bits are reserved. The masked value C & 0x0C MUST NOT be 0x80 when M=0.
The Original Header Block (OHB) has the ABNF form: OHB = [PT] [SEQ] Config. The optional PT field is 1 octet, the optional SEQ field is 2 octets, and the mandatory Config field is 1 octet. An all-zero Config octet (0x00) indicates no modifications were made.