The Secure Real-time Transport Protocol (SRTP)
updated by
Extracted elements (32)
A single master key derives up to six session keys (SRTP/SRTCP encryption, authentication, and salt keys) via a key derivation function, so key management only needs to exchange one master key plus master salt. Periodic re-derivation (non-zero key_derivation_rate) provides forward and backward security: compromise of one session key does not expose others derived from the same master key.
Short or zero-length authentication tags (down to zero bytes) are permitted for SRTP (but not SRTCP) to accommodate bandwidth-constrained wireless environments such as CDMA2000 VoIP where not a single additional byte can be added. A 32-bit tag still yields one-in-2^32 forgery probability per packet for a voice codec, which is acceptable for stateless applications.
SRTCP uses an explicit 31-bit index carried in every packet rather than the implicit ROC+SEQ approach of SRTP, because RTCP packets are sent infrequently and the receiver cannot reliably infer the index from the sparse sequence. The E-flag allows selective encryption of individual RTCP compound packets while always authenticating.
The master salt and derived session salting key protect against pre-computation attacks and time-memory tradeoff attacks on the key derivation and the stream cipher. The salt is explicitly included in the IV rather than via an implicit mechanism to ease hardware implementation.
SRTP and SRTCP share the same cryptographic context by default (including master key(s)), but MUST use distinct session keys derived via different label values. The session key MUST NOT be shared between SRTP and SRTCP even when the master key is shared. Separate replay lists and packet counters MUST be maintained for each stream.
When computing the RTCP variable avg_rtcp_size at initialization and update time, implementations MUST include the sizes of the SRTCP-added fields (index, E-bit, authentication tag, and optional MKI) to prevent SRTCP from exceeding its allotted bandwidth share.
A new SRTP transform MUST be defined in a companion standards-track RFC. That RFC MUST list any additional cryptographic context parameters, MUST explain interactions between the new transform and SRTP, and the new message integrity transform SHOULD define a minimum key/tag size for SRTCP equivalent in strength to the HMAC-SHA1 defaults.
After 2^48 SRTP packets have been sent with a given master or session key, the sender MUST NOT send any more packets with that key. Re-keying MUST be triggered before this limit is reached. A similar (and in practice more restrictive) limit of 2^31 applies for SRTCP.
Automatic key management MUST be used for establishing and maintaining SRTP and SRTCP keying material to avoid keystream reuse, which is more likely to occur with manual key management.
If both encryption and authentication are applied to an SRTP packet, encryption SHALL be applied before authentication on the sender side, and conversely (authenticate first, then decrypt) on the receiver side.
Interoperable SRTP implementations MUST use the SRTP key derivation to generate session keys, regardless of the encryption or message authentication transform employed. At least one initial key derivation SHALL be performed before the first packet.
On the receiver, a packet judged to be replayed MUST be discarded and the event SHOULD be logged. If authentication verification yields AUTHENTICATION FAILURE, the packet MUST also be discarded and the event SHOULD be logged.
SRTCP message authentication is MANDATORY because malicious or erroneous alteration of RTCP messages could disrupt processing of the RTP stream. Encryption and replay protection for SRTCP remain optional and independent.
SRTP/SRTCP MUST NOT share master keys outside of two permitted cases: (1) between an SRTP stream and its corresponding SRTCP, and (2) between streams belonging to the same RTP session. In all other circumstances, separate master keys are required.
SRTP-WINDOW-SIZE for the replay protection sliding window MUST be at least 64 but MAY be set to a higher value. Packets with index lagging more than SRTP-WINDOW-SIZE behind the current context index may be assumed already received.
The RTCP encryption prefix (a random 32-bit quantity) specified in RFC 3550 Section 6.1 MUST NOT be used in SRTCP, as it applies only to the encryption method defined in RFC 3550 and is not needed by SRTP's cryptographic mechanisms.
The SRTCP index MUST be set to zero before the first SRTCP packet is sent and MUST be incremented by one modulo 2^31 after each packet. After a re-key, the SRTCP index MUST NOT be reset to zero.
When the session starts, the sender MUST set the ROC to zero. Each time the RTP sequence number wraps modulo 2^16, the sender MUST increment the ROC by one modulo 2^32. After a re-keying occurs, the ROC MUST NOT be reset to zero.
The 48-bit SRTP packet index is defined as i = 2^16 * ROC + SEQ, where ROC is the 32-bit rollover counter maintained by SRTP and SEQ is the 16-bit sequence number from the RTP header. The index is implicit (not fully carried in the packet) and used for replay protection, encryption IV, message authentication, and key derivation.
The default and mandatory-to-implement encryption transform is AES in Segmented Integer Counter Mode (AES-CM) with a 128-bit session encryption key and a 112-bit session salt. AES-f8 is optional. The NULL cipher is also mandatory-to-implement for use when confidentiality is not required.
The default and mandatory-to-implement message authentication transform is HMAC-SHA1 with a 160-bit session authentication key and an 80-bit truncated output tag. For SRTCP, HMAC-SHA1 MUST NOT be applied with tag length or key length smaller than these defaults.
The SRTP cryptographic context is the per-stream state maintained by sender and receiver, identified by the triplet <SSRC, destination network address, destination transport port number>. It holds the master key(s), session keys, ROC, s_l, replay list, algorithm identifiers, and associated parameters. If no valid context can be found for a packet, that packet MUST be discarded.
SRTP defines key derivation label constants 0x00–0x05 for the six session keys/salts (SRTP encryption, SRTP authentication, SRTP salt, SRTCP encryption, SRTCP authentication, SRTCP salt). Future extensions MAY use label values 0x06–0xFF for other purposes, and new transforms must be defined in companion standards-track RFCs.
SRTP encrypts only the RTP payload, not the RTP header. Header fields (SSRC, sequence number, timestamp, payload type) are visible to any observer and can be used for traffic analysis. Confidentiality of the RTP header requires a lower-layer security mechanism such as IPsec.
SSRC collision within the same RTP session sharing the same master key creates a two-time pad exposure: two streams with identical SSRCs and identical sequence numbers will produce identical keystream, catastrophically compromising confidentiality. Key management SHOULD proactively ensure SSRC uniqueness by including SSRCs as negotiation parameters.
The master key usage limit is 2^48 SRTP packets (48-bit index) and 2^31 SRTCP packets (31-bit index). SRTP senders MUST count processed packets per master key and invoke re-keying before these limits are exceeded. The SRTCP limit may be more restrictive in practice because SRTCP is often sent at a lower rate and uses a shorter index.
Using a zero-length or weak authentication tag exposes SRTP to packet injection, blind denial-of-service, and router-table attacks. Null authentication is acceptable only in tightly bandwidth-constrained environments (e.g., certain wireless channels) where the application can tolerate forged packets and is not stateful across packets.
An SRTCP packet appends three mandatory fields to the RTCP compound packet: a 1-bit E-flag (encrypt/no-encrypt), a 31-bit SRTCP index, and a configurable-length authentication tag; plus an optional MKI. The Encrypted Portion begins at the ninth octet of the first RTCP packet and extends to the end of the compound packet.
An SRTP packet is an RTP packet with two SRTP-specific appended fields: an OPTIONAL variable-length MKI (Master Key Identifier) and a RECOMMENDED variable-length authentication tag. The Encrypted Portion covers the RTP payload; the Authenticated Portion covers the RTP header plus the Encrypted Portion.
For AES Counter Mode, the 128-bit IV is formed as IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16), where k_s is the 112-bit session salt (zero-padded), SSRC is the 32-bit synchronization source, and i is the 48-bit packet index. The least significant 16 bits are reserved as zero for the block counter.
For AES f8-mode SRTP, the 128-bit IV is formed as IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC, where all fields are taken from the RTP header except ROC which comes from the cryptographic context. For SRTCP, IV = 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC.
SRTP key derivation uses label constants to distinguish derived keys: 0x00 for SRTP encryption key (k_e), 0x01 for SRTP authentication key (k_a), 0x02 for SRTP salt (k_s), 0x03 for SRTCP encryption key, 0x04 for SRTCP authentication key, and 0x05 for SRTCP salt. The derived key is PRF_n(k_master, label XOR (index DIV rate) XOR master_salt).