Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)
Extracted elements (28)
It is RECOMMENDED to include all acceptable key management protocols in a single offer rather than sequentially offering alternatives after error responses, because unauthenticated error messages can be faked by a MITM to steer the offerer toward a weaker protocol.
RTSP does not use the SDP offer/answer model, so a new RTSP KeyMgmt header was introduced to allow the client to send back a key management response, since SDP alone cannot carry the bidirectional exchange required by key management protocols.
The existing SDP 'k=' field is insufficient for key management protocols because it lacks extensibility and cannot carry the many parameters needed. A new 'key-mgmt' attribute with a protocol identifier and opaque base64 data field was introduced to support arbitrary key management protocols.
This framework differs from SDES (RFC 4568): SDES requires end-to-end SDP integrity protection (e.g., S/MIME) to protect keying material, while RFC 4567's framework provides its own end-to-end security for key management parameters independent of signaling protection.
A media-level key-mgmt SDP attribute overrides a session-level one: if the media-level attribute is present, the session-level attribute MUST be ignored for that media.
Before creating key management data in an offer/answer scenario, the list of protocol identifiers MUST be provided to each key management protocol to defeat bidding-down attacks (Section 4.1.4).
If errors occur or the key management offer is rejected (with no intent to re-negotiate), the session SHALL be aborted. Re-negotiation MUST be done through another Offer/Answer exchange.
If the answerer does not support any offered key management protocols and the session is aborted, the answerer SHOULD return '488 Not Acceptable Here'. Re-keying MUST be handled as a new offer and MUST use the same key management protocol as the original.
If the RTSP server expects a key management message in a SETUP but none is included, a '403 Forbidden' SHOULD be returned and the setup MUST be aborted. If key management fails, error code 463 is used and the session is aborted.
In RTSP PLAY mode, the server SHALL be the Initiator of the key management exchange. Only one key management protocol SHALL be used per session/media level in RTSP.
In SAP (one-way SDP) scenarios, only one key management protocol SHALL be offered since no negotiation is possible, and the key management protocol used MUST support one-way messages.
Key management data SHALL be base64 encoded (per RFC 3548) and comply with the base64 grammar defined in SDP. The KMPID is case sensitive and it is RECOMMENDED that registered values be lowercase letters.
Key management responses for an aggregated RTSP session SHALL be sent in the first SETUP; each subsequent SETUP for the same session MUST carry the same response for the session-level context.
New key management protocol identifiers MUST be registered with IANA under the 'SDP/RTSP key management protocol identifier' registry per the Specification Required policy.
RTSP proxies SHALL NOT add, change, or delete the KeyMgmt header.
The key management protocol MUST be executable in at most one request-response message exchange when integrated with SIP/SDP and RTSP.
The protocol identifier list passed to each key management protocol SHALL be semicolon-separated (prtcl-list = KMPID *(";" KMPID)), and all offered identifiers MUST be included in the same order as they appear in the SDP.
To prevent bidding-down attacks, the list of protocol identifiers MUST be authenticated — each key management protocol MUST specify how to authenticate the protocol identifier list, even when only one protocol is used.
When creating an initial SDP offer, the key management protocol identifier MUST be placed in the prtcl-id field, and the keymgmt-data field MUST be created by the key management protocol, base64 encoded, and encapsulated in the attribute.
MIKEY integration: the KMPID 'mikey' is registered; MIKEY places the semicolon-separated protocol identifier list in a General Extension Payload of type 'SDP IDs', which is integrity-protected/signed. The receiver SHALL match this list against the SDP and SHOULD reject the offer on mismatch or verification failure.
RTSP status code 463 (Key management failure) is defined for reporting failures during key management processing. A 463 response MAY contain a KeyMgmt header with additional error detail from the key management protocol.
The RTSP KeyMgmt header carries one or more key-mgmt-spec entries, each with a 'prot' (KMPID), optional 'uri' identifying the session or media context, and base64-encoded 'data'. Syntax: KeyMgmt = 'KeyMgmt' ':' key-mgmt-spec 0*(',' key-mgmt-spec).
The SDP key management attribute 'key-mgmt' carries a protocol identifier (prtcl-id) and base64-encoded key management data (keymgmt-data). The ABNF is: key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data.
RFC 4567 creates three IANA registries: (1) SDP attribute 'key-mgmt' (att-field, session and media level); (2) RTSP header 'keymgmt' with RTSP status code 463; (3) 'SDP/RTSP key management protocol identifier' (KMPID) namespace, initially containing 'mikey'.
An active attacker who can modify unprotected SDP messages may change attributes (e.g., address information) that key management indirectly relies on, causing DoS or indirect compromise. Only the key management parameters themselves are end-to-end protected by this framework; session-level SDP integrity requires external means.
The security level of the authenticated protocol identifier list is only as strong as the weakest protocol included. An attacker can also 'peel off' all key management attributes, making bidding-down prevention ineffective; local policy must decide whether to abort the session if no security attribute is present in the response.
Using multiple key management protocols in a single offer without authenticating the protocol identifier list enables bidding-down attacks, where a MITM removes stronger offers. The offer MUST NOT contain protocols weaker than local security policy permits, and all offered identifiers must be authenticated by each key management protocol.
SDP key management processing has four steps: (1) create initial offer, (2) handle received offer, (3) create answer, (4) handle received answer. Steps 3 and 4 may not apply in one-way (SAP) scenarios. Failure at any step aborts the session.