Security Preconditions for Session Description Protocol (SDP) Media Streams
updates
- rfc-3312 — Integration of Resource Management and Session Initiation Protocol (SIP)
Extracted elements (21)
Key duplication during precondition establishment (repeating the same crypto/key-mgmt data in the second offer/answer exchange) is not a replay attack. Implementations may recognize that the key management protocol data is identical and avoid forwarding it to the security layer for reprocessing.
Security preconditions do not guarantee that an established media stream will be secure; they only guarantee that the recipient can perform relevant decryption and integrity checking. For example, SRTP using NULL encryption and no message integrity qualifies as a "secure media stream" for precondition purposes even though it provides no real protection.
Using an optional security precondition combined with the SIP "Supported" header and option tag "precondition" (rather than mandatory with "Require") avoids the Heterogeneous Error Response Forking Problem (HERFP) that arises because mandatory preconditions require SIP UAs to support preconditions or reject the request.
Current SDP and offer/answer procedures (RFC 4566, RFC 3264) allow only a single transport protocol type per media stream; negotiation of alternative transport protocols (e.g., plain vs. secure RTP) is not defined, so if the offered secure transport is unsupported the media stream is simply rejected.
During the delay imposed by a mandatory security precondition, alerting of the called party MUST NOT occur and media for which security is being negotiated MUST NOT be exchanged until the precondition is satisfied. Non-media data (e.g., ICE connectivity checks) is allowed prior to satisfaction.
For SRTP negotiated via SDP Security Descriptions, when the offerer requests the "send" precondition, the offerer needs to receive the answer before the precondition is satisfied (to learn destination address and chosen cryptographic parameters). The answerer MUST use the confirm-status attribute to trigger an updated offer from the offerer.
If the answerer wants to avoid media clipping when an optional security precondition was offered, the answerer MUST increase the strength to "mandatory" in the answer to delay session progress until the offerer has received the answer.
Subsequent offer/answer sequences used to update the precondition status for a secure media stream SHOULD use the same key material as the initial offer/answer exchange; crypto or key-mgmt attribute lines in offers sent in response to confirm-status SHOULD repeat the same data as the previous offer.
The security precondition type MUST be used with the end-to-end status type; use of the segmented status type is undefined.
When a mandatory security precondition cannot be satisfied by the answerer (e.g., offer lacks necessary keying material), the offered media stream MUST be rejected as described in RFC 3312.
When a mandatory security precondition is received in an offer, session establishment or modification MUST be delayed until the cryptographic parameters for the secure media stream are known to have been negotiated in the required direction(s).
When a security precondition with strength-tag "optional" is received in an offer, the answerer MUST generate its answer SDP as soon as possible, since session progress is not delayed.
When all mandatory preconditions are met during a re-INVITE or UPDATE, user agents MUST start using the new session parameters for media packets being sent, and SHOULD be prepared to process media received with either old or new session parameters for a short transition period.
The security precondition type is identified by the string "sec" and extends the RFC 3312 precondition grammar: precondition-type = "sec" / "qos" / token. It requires that relevant cryptographic parameters (cipher, key, etc.) for a secure media stream have been successfully negotiated in the required direction(s).
The "send" direction tag means media stream security negotiation has reached a stage where the other party can correctly process (decrypt and/or integrity-check) media packets sent to them, including SRTP and SRTCP. The "recv" direction tag means the local party can correctly process media packets sent by the other party.
IANA registered a new RFC 3312 precondition type "sec" with the name "Security precondition", with RFC 5027 as the reference.
An attacker who adds security preconditions to offers or increases their strength-tag may cause session failure, heterogeneous error response forking problems, or undesired delays in session establishment.
An attacker who can remove or downgrade the strength-tag of security preconditions in an offer/answer exchange can cause premature user alerting for a session with no functioning media, or cause media clipping by removing protections against race conditions between offer/answer and secure media stream packets.
When SDP Capability Negotiation allows negotiating secure and non-secure media alternatives, use of security preconditions (even mandatory) does not prevent an active attacker from injecting malicious media if the offerer may receive media before knowing which alternative was selected by the answerer.
Where SIP intermediaries on the signaling path are not fully trusted, end-to-end integrity protection of signaling (e.g., S/MIME) MUST be used and MUST cover both the message body (containing security preconditions) and the SIP "Supported" and "Require" headers (containing the "precondition" option tag).
The offerer's local status table tracks Direction (send/recv), Current status (yes/no), Desired Strength (mandatory/optional/none), and Confirm flag. Initial state is Current=no for both directions; transitions to yes upon receipt of answer containing needed cryptographic parameters, triggering a confirm update if requested.