Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
updates
- rfc-3711 — The Secure Real-time Transport Protocol (SRTP)
Extracted elements (25)
For SEED-CCM and SEED-GCM AEAD transforms, the header extension keystream is generated using SEED-CTR rather than the native AEAD mode. This is because the RTP header (including the header extension) is already included in the Associated Authenticated Data (AAD) of the AEAD transform, so counter-mode encryption for the extension is considered cryptographically equivalent.
Selective encryption is intentional: a sender may wish some extension information (e.g., RTP transmission time offsets) to remain in the clear for network monitoring devices, while encrypting other sensitive extensions (e.g., audio levels). The encryption mask mechanism accommodates this per-element selectivity.
SRTP deliberately omits header confidentiality to preserve RTP header compression efficiency. Standard header fields reveal little beyond what an attacker could infer from packet size and timing, so authentication alone is sufficient for them. However, header extensions can carry sensitive data (e.g., per-packet audio levels) for which confidentiality is essential.
The mechanism uses the same cryptographic algorithms and parameters (transform, IV, master key, master salt, index, key_derivation_rate) as SRTP payload encryption, deriving only separate header-specific encryption and salting keys. This avoids introducing new cryptographic machinery while achieving equivalent security properties for header extensions.
An SDP endpoint that does not understand the 'urn:ietf:params:rtp-hdrext:encrypt' URI will, per RFC 5285 procedures, ignore the extension and negotiate not to use it during offer/answer. This provides backward compatibility with non-implementing endpoints.
A receiver SHOULD decrypt header extensions only after validating the packet's authentication tag and MUST NOT take any security- or correctness-affecting actions based on decrypted header content prior to authentication tag validation.
An offerer using best-effort header extension encryption MUST offer best-effort negotiation only when lack of confidentiality would be acceptable in the backward-compatible case, and users of best-effort encryption MUST be cautious of bid-down attacks.
Header extension encryption MUST be performed before the SRTP authentication tag is computed. Authentication tag validation MUST be performed on the encrypted (wire-form) header extension, not on decrypted data.
If the encrypted header extension extmap is specified as a media-level SDP attribute, it MUST appear only on SRTP-based media. If specified as a session-level attribute, at least one media in the session MUST use an SRTP-based RTP profile; the attribute MUST be ignored for non-SRTP media.
In a negotiated session, senders MUST NOT send, and answerers MUST NOT negotiate, both encrypted and unencrypted forms of the same header extension element simultaneously. Answerers that understand header extension encryption SHOULD choose the encrypted form and mark the unencrypted form inactive.
Strong authentication is REQUIRED when an attacker setting header extension bits could have a meaningful effect on system behavior, because some header extension elements have easily guessed plaintext bits.
The Standards Track RFC defining any new SRTP encryption transform MUST specify how that transform is to be used with header extension encryption, extending the rules of RFC 3711 Section 6.
The 'urn:ietf:params:rtp-hdrext:encrypt' URI MUST NOT be recursively applied to itself.
An encryption mask is computed for each packet containing encrypted header extension elements. The mask has 0xff octets for extension element payload octets to be encrypted and 0x00 for non-encrypted payload octets, element headers, and padding. The masked keystream (mask AND keystream) is XORed with the header extension to produce the ciphertext.
For AES-CM, AES-f8, SEED-CTR, AES_192_CM, and AES_256_CM transforms, the header extension keystream is generated using the same transform and IV as the SRTP payload, but substituting k_he and k_hs for k_e and k_s. For the NULL encryption transform, the header extension keystream is all-zero.
The one- or two-byte element headers defined by RFC 5285, header extension padding, and the 'defined by profile' and 'length' fields are never encrypted. Encryption covers only the payload octets of the selected header extension elements, starting from the first RFC 5285 ID and length field.
Two new SRTP keys are derived using the standard SRTP key derivation algorithm (Section 4.3.1 of RFC 3711): k_he (header encryption key) with label 0x06 and n=n_e, and k_hs (header salting key) with label 0x07 and n=n_s. The key sizes match those used for SRTP payload encryption and salting.
This document registers a new extension URI in the RTP Compact Header Extensions subregistry of the RTP Parameters registry: URI 'urn:ietf:params:rtp-hdrext:encrypt', described as 'Encrypted header extension element', contact [email protected], reference RFC 6904.
For the two-byte-header form (0x100N), the mechanism provides no protection for zero-length extension elements (whose presence or absence is the sole information) nor for the four appbits of the 'defined by profile' field. These limitations do not apply to one-byte-header form (0xBEDE).
Middleboxes without access to SRTP authentication keys cannot verify the authenticity of unencrypted RTP header extension elements and MUST treat them as untrusted and potentially attacker-generated, applying appropriate skepticism to any interpretation.
The mechanism provides confidentiality only for the content of selected header extension elements, not for which extension types are present. An observer can still determine which extension IDs are in use, consistent with SRTP's approach of not encrypting the RTP fixed header.
The technique is limited to keystream-based encryption transforms (e.g., CTR, f8) that generate a pseudorandom keystream for XOR with plaintext. It cannot be applied to block cipher modes such as ECB or CBC that do not produce a keystream.
There is no mechanism to protect header extensions with different algorithms or keys than those protecting the RTP payload. In particular, it is not possible to provide header extension confidentiality while leaving the payload in cleartext.
Encrypted header extension elements are signaled in SDP using the extmap attribute with URI 'urn:ietf:params:rtp-hdrext:encrypt' followed by the URI of the element being encrypted and any extension attributes. The ABNF grammar extends that of RFC 5285: extmap =/ mapentry SP enc-extensionname SP extensionname [SP extensionattributes].
Header extension encryption uses a per-packet bitmask over the RFC 5285 extension payload region. Encrypted element payload octets are masked 0xff; all other octets (element headers, non-encrypted payloads, padding) are masked 0x00. The ciphertext is computed as (Encrypt(Key, Plaintext) AND MASK) OR (Plaintext AND (NOT MASK)).