Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)
updates
- rfc-8122 — Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
Extracted elements (28)
Key continuity mechanisms may partially detect UKS attacks only if a session with the attacker or the genuine peer was established in the past. Implementations that index by peer identity rather than key may silently accept a new key, mistaking the attack for a device change, so key continuity is not a reliable mitigation.
Rather than including the full identity binding in the TLS extension (which could be large), a collision- and preimage-resistant SHA-256 hash is used. This keeps the extension compact while still binding the identity to the TLS Finished MAC, preventing substitution attacks.
The existing SDP 'tls-id' attribute is reused as the unique session identifier for the external_session_id extension because it is already required to be unique per offer/answer, meaning no two offers or answers from the same client share the same value, without requiring a new identifier mechanism.
The 'external_session_id' defense is not effective if an attacker can rewrite 'tls-id' values in signaling; only the 'external_id_hash' mechanism can defend against an attacker that compromises session integrity. The two extensions address different threat models and are intended to be used together.
The SIGMA ('SIGn-and-MAc') approach is adopted: the identity of endpoints is included under a MAC during the cryptographic handshake so that peers can validate their peer's identity. In TLS, the Finished message provides a MAC over the entire handshake, making inclusion of identity in a TLS extension sufficient to bind identity to the session.
A peer that receives an identity binding but does not receive an 'external_id_hash' extension MAY accept a TLS connection rather than fail it, to allow interoperability with implementations written before this specification was defined.
An endpoint MAY choose to continue a session without the 'external_session_id' extension in order to interoperate with peers that do not implement this specification. The extension's absence does not mandate connection failure.
Third-party call control (3PCC) is affected by the mitigations in this document: for 3PCC to work with these extensions, the 3PCC controller must either forward SDP without modification or avoid modifying 'fingerprint', 'tls-id', and 'identity' attributes. 3PCC as defined in RFC 3725 is incompatible with SIP identity.
Where RTP and RTCP are not multiplexed, the two separate DTLS connections carrying RTP and RTCP can be switched without harm since SRTP provides key separation. Using RTP/RTCP multiplexing (RFC 5761) avoids even this benign ambiguity.
A peer that receives an 'external_id_hash' extension that does not match the value of the identity binding from its peer MUST immediately fail the TLS handshake with an 'illegal_parameter' alert. The absence of an identity binding does not relax this requirement; a zero-length extension MUST be present for a peer that provided no identity binding.
An endpoint that does not produce an identity binding MUST generate an empty 'external_id_hash' extension in its ClientHello, or — if a client provides the extension — in ServerHello or EncryptedExtensions. An empty extension has a zero-length 'binding_hash' field.
An 'external_id_hash' extension with a 'binding_hash' field of any length other than 0 or 32 is invalid and MUST cause the receiving endpoint to generate a fatal 'decode_error' alert.
Endpoints MUST check that the 'session_id' parameter in the received 'external_session_id' extension includes the 'tls-id' attribute value from their peer's session description. An endpoint that receives a non-matching value MUST abort the connection with a fatal 'illegal_parameter' alert.
In TLS 1.3, an 'external_id_hash' extension sent by a server MUST be sent in the EncryptedExtensions message.
In TLS 1.3, an 'external_session_id' extension sent by a server MUST be sent in the EncryptedExtensions message.
Information extracted from a TLS connection MUST NOT be used in a secondary protocol outside of that connection if that protocol assumes the signaling protocol has the same peers. Security-sensitive information from one TLS connection MUST NOT be used in other TLS connections, even if established as a result of the same signaling session.
To prevent both forms of unknown key-share attack, endpoints MUST use the 'external_session_id' extension (Section 4.3) in addition to 'external_id_hash' (Section 3.2) so that two calls between the same parties cannot be altered by an attacker.
When used with SDP, the 'external_session_id' extension value MUST include the 'tls-id' attribute from the SDP that the endpoint generated when negotiating the session, encoded using ASCII.
Where the compact form of PASSporT is used, it MUST be expanded into the full form before hashing for the 'external_id_hash' extension. The base64 encoding in the SIP Identity header MUST be decoded then used as input to SHA-256 to produce the 32-octet 'binding_hash' value.
The 'external_id_hash' TLS extension (code point 55) carries a SHA-256 hash of the identity assertion that the sending endpoint has asserted to its peer. Both peers include a hash of their own identity assertion. It is sent in ClientHello and, for TLS 1.3 servers, in EncryptedExtensions.
The 'external_session_id' TLS extension (code point 56) carries the 'tls-id' SDP attribute value chosen by the sending endpoint, binding the TLS handshake to the specific signaling session. It is sent in ClientHello and, if present in ClientHello, in ServerHello (pre-TLS 1.3) or EncryptedExtensions (TLS 1.3).
Two entries are added to the IANA 'TLS ExtensionType Values' registry established in RFC 8446: 'external_id_hash' assigned code point 55 (recommended, CH/EE in TLS 1.3) and 'external_session_id' assigned code point 56 (recommended, CH/EE in TLS 1.3).
A UKS attack using fingerprints alone (without identity bindings) is possible when a victim reuses a certificate across two near-simultaneous sessions. The attacker substitutes the victim's fingerprint and forwards DTLS/media packets, causing the victim to believe it is communicating with the attacker when it is actually communicating with a second honest endpoint. The attack requires the attacker to be on-path for media.
An unknown key-share (UKS) attack allows an attacker to bind their own identity to the certificate fingerprint of another entity, causing a victim to incorrectly believe it is communicating with the attacker when it is actually communicating with a second innocent party. The attack does not expose confidential media but breaks mutual authentication, enabling misrepresentation of context.
Session concatenation allows an attacker to establish two concurrent sessions with different peers and relay signaling between them, causing both victims to believe they are communicating with the attacker while actually communicating with each other. This attack produces only one TLS connection and is not fully prevented by session identifiers alone; it requires higher-level peer authentication.
UKS attacks on DTLS-SRTP using identity bindings (WebRTC identity or SIP PASSporT) are feasible because identity providers are not required to verify that the requesting entity controls the keys associated with the fingerprints. An attacker obtains an identity assertion for an identity they control, but covers the fingerprint of a victim, causing a second victim to believe it is talking to the attacker.
The 'ExternalIdentityHash' struct carried in the 'external_id_hash' TLS extension contains a single field 'binding_hash' of type opaque with length 0..32. A length of 0 indicates support without an identity binding; a length of 32 carries a SHA-256 hash of the identity assertion.
The 'ExternalSessionId' struct carried in the 'external_session_id' TLS extension contains a single field 'session_id' of type opaque with length 20..255. For SDP use, this field holds the ASCII-encoded value of the 'tls-id' SDP attribute.