Session Description Protocol (SDP) Security Descriptions for Media Streams
Extracted elements (26)
Late binding of SSRCs is RECOMMENDED: rather than signaling SSRCs in SDP, the crypto context is bound to an SSRC upon first packet arrival. This works because the ROC is always zero at session start and unique master keys per direction avoid keystream reuse even in SSRC collision scenarios.
MKI is chosen over the SRTP <From, To> sequence-number-based key lifetime feature because the AES master key lifetime of 2^48 SRTP packets eliminates any cryptographic reason to replace a master key for practical point-to-point applications, making a single key signaling mechanism sufficient.
SIP forking can produce multiple answers to a single offer, creating multipoint scenarios that are outside the scope of SRTP security descriptions. A suggested (non-normative) workaround is to issue a new offer with a new receive transport address for each answer beyond the initial one, using SIP UPDATE and security preconditions.
Each SRTP master key MUST be a unique cryptographically random value with respect to all other master keys in the entire SDP message, including master keys for other streams. If the base64-decoded key-and-salt length does not match the crypto-suite specification, the crypto attribute MUST be considered invalid.
For AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, and F8_128_HMAC_SHA1_80, the length of the base64-decoded key and salt value MUST be 30 octets (240 bits); otherwise the crypto attribute is considered invalid.
If an offer includes both 'a=crypto' and 'a=keymgt' or 'k=' lines, the answer MUST include either 'a=crypto' or the other attribute, but not both; including both is undefined.
If an SDP crypto attribute is received with an unknown session parameter that is not prefixed with '-', that crypto attribute MUST be considered invalid. New session parameters prefixed with '-' are optional and MAY be ignored.
If the MKI length field is not given or its value exceeds 128 bytes, the entire crypto attribute MUST be considered invalid. When more than one master key is present, all keys MUST include an MKI value, and the MKI length MUST be the same for all keys in a given crypto attribute.
If the offerer sees an accepted SRTP media stream in the answer that does not include a crypto line, the security negotiation MUST be deemed to have failed. Similarly, in the general case, if the answer omits a crypto line for an offered secure stream, the security negotiation MUST fail.
If UNENCRYPTED_SRTCP is signaled, the SRTCP E bit MUST be clear (0) in all SRTCP messages. If the default encryption is used, the E bit MUST be set (1) in all SRTCP messages. Offerers and answerers MUST NOT use the SRTCP E-bit to override the UNENCRYPTED_SRTCP parameter.
Implementations MUST employ security mechanisms that provide confidentiality and integrity for the keying material. When used with SIP, the application SHOULD employ either the SIPS URI or S/MIME; use of transport-layer or IP-layer security in lieu of SIPS/S/MIME is NOT RECOMMENDED because protection cannot be ensured through intermediate SIP proxies.
The 'crypto' attribute MUST only appear at the SDP media level, not at the session level.
The master key(s) included in the answer MUST be different from those in the offer; the receiver MUST NOT use the sender's inline master key for the SRTP or SRTCP packets it sends, because the default SRTP cipher is insecure when a master key is reused across distinct SRTP streams.
The ROC MUST be zero at the time each SSRC commences sending packets. The initial value of SEQ SHOULD be chosen in the range 0..2^15-1 to avoid ambiguity when packets are lost at session start.
The tag MUST be unique among all crypto attributes for a given media line, and leading zeroes MUST NOT be used. In the offer/answer model, the tag is a negotiated parameter used to identify which offered crypto attribute was accepted.
Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED. SRTP requires authentication for SRTCP but not for SRTP; unauthenticated SRTP combined with late binding exposes sessions to easy denial-of-service attacks.
When a new offer changes the IP address and/or port for a media or FEC stream, the offerer MUST include a new master key (creating a new crypto context with ROC=0). The answerer faces the same requirement when it changes the IP address and/or port in an answer.
When generating the initial answer, the answerer MUST accept exactly one of the offered crypto attributes or MUST reject the offered stream. The selected crypto attribute in the answer MUST contain the tag and crypto-suite from the accepted offer, plus the answerer's own keying material.
When multiple keys are included in the key parameters, it MUST be possible to determine which key is being used in a given media packet by simple inspection; a trial-and-error approach MUST NOT be performed. For SRTP, this is achieved using Master Key Identifiers (MKI).
The SDP 'crypto' attribute has the form: a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]. It is a media-level attribute describing the cryptographic suite, keying material, and optional session parameters for the preceding unicast media line.
Three SRTP crypto-suites are defined: AES_CM_128_HMAC_SHA1_80 (128-bit key, 80-bit SRTP auth tag), AES_CM_128_HMAC_SHA1_32 (128-bit key, 32-bit SRTP auth tag), and F8_128_HMAC_SHA1_80 (128-bit key, AES f8 cipher, 80-bit auth tag). All use 128-bit master keys, 112-bit master salts, HMAC-SHA1, and 160-bit auth keys.
RFC 4568 creates the 'SDP Security Descriptions' IANA registry with two sub-registries: Key Methods (initially containing 'inline') and Media Stream Transports (initially containing 'SRTP', which itself has sub-registries for crypto suites and session parameters). New entries require Standards Action RFCs.
SSRC collisions can cause keystream reuse in SRTP when senders and receivers share a master key, drastically weakening encryption. This specification mitigates the risk by requiring unique master keys for each direction of each unicast media stream.
The encapsulating application protocol (e.g., SIP) MUST provide strong message authentication, payload encryption, and effective replay protection for SDP messages containing security descriptions. Failure to encrypt an SDP message containing an inline SRTP master key renders SRTP encryption useless in practically all circumstances.
When SDP messages are routed through intermediate systems (e.g., SIP proxies), hop-by-hop TLS or IPsec SHOULD NOT be used to protect security descriptions. MIME secure multiparts (e.g., S/MIME) are RECOMMENDED to ensure end-to-end protection of the 'a=crypto' attribute and keying material against intermediate-system inspection or modification.
The SRTP inline key format is: 'inline:<key||salt> ["|"] [lifetime] ["|"] [MKI ":" length]'. The key and salt are concatenated and base64-encoded; lifetime is expressed as a decimal integer or power-of-2 (e.g., 2^20); MKI is a positive decimal integer followed by a colon and its byte length (1–128).