RFC 8844

Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)

📅 published January 2021, from ietf

RFC 8844 💖 is the spec for Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) 🎀. It came out in January 2021, and M. Thomson and E. Rescorla (both at Mozilla 🦋) wrote it. It's a Standards Track doc, and it updates RFC 8122. ISSN is 2070-1721 ✨.

Abstract

okay so this doc is about unknown key-share attacks on DTLS-SRTP, which is Datagram Transport Layer Security used for the Secure Real-Time Transport Protocol 🎧. Similar attacks also work on DTLS-SRTP when it's paired with the identity bindings from WebRTC and SIP identity 📞. They're honestly hard to pull off 😭, but they can leave a victim totally confused about who they're talking to 🙈. This doc defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy 🫶.

Status of This Memo

this is an Internet Standards Track document 📜.

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community 🌸, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 7841 🔍.

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8844 💅.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⚠️.

Table of Contents

   1.  Introduction
   2.  Unknown Key-Share Attack
     2.1.  Limits on Attack Feasibility
     2.2.  Interactions with Key Continuity
     2.3.  Third-Party Call Control
   3.  Unknown Key-Share Attack with Identity Bindings
     3.1.  Example
     3.2.  The "external_id_hash" TLS Extension
       3.2.1.  Calculating "external_id_hash" for WebRTC Identity
       3.2.2.  Calculating external_id_hash for PASSporT
   4.  Unknown Key-Share Attack with Fingerprints
     4.1.  Example
     4.2.  Unique Session Identity Solution
     4.3.  The external_session_id TLS Extension
   5.  Session Concatenation
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

so, Transport Layer Security (TLS) [TLS13] works with the Session Description Protocol (SDP) [SDP], and that combo is defined in [FINGERPRINT] 🎀. Using it with Datagram Transport Layer Security (DTLS) [DTLS] and the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as DTLS-SRTP [DTLS-SRTP] 💜.

here's the vibe: key agreement happens through TLS or DTLS, and authentication gets tied back to the session description (or SDP) using certificate fingerprints 🔐. Communication peers check that the hash, or fingerprint, given in the SDP matches the certificate that shows up in the TLS or DTLS handshake 🧚.

WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity [SIP-ID] both have a way to bind an external identity to the certificate fingerprints in a session description 🪪. BUT, and this is a big but 😤, that binding isn't integrity protected. So it's open to an identity misbinding attack, also called an unknown key-share (UKS) attack, where the attacker binds their identity to someone else's fingerprint 🙅‍♀️. When that works, you get sessions where the peers are confused about who's in the call 💀.

this doc describes a TLS extension you can use together with these identity bindings to stop that attack 🛡️.

a similar attack is possible with just certificate fingerprints, no identity bindings needed. Attacks in this setting are probably infeasible in existing deployments because the preconditions are so narrow (see Section 2.1), but this doc also describes mitigations for it 🌷.

the mechanisms in this document are meant to strengthen the protocol so it doesn't fall to unknown key-share attacks when they're combined with other protocol or implementation vulnerabilities 💪. RFC 8122 [FINGERPRINT] gets updated by this document to recommend using these mechanisms 🦋.

this document assumes signaling is integrity protected. BUT, as Section 7 of [FINGERPRINT] explains, lots of deployments that use SDP don't guarantee signaling integrity, so they're exposed to other attacks too 😬. [FINGERPRINT] offers key continuity mechanisms as a possible way to reduce exposure to attack when integrity protection is missing 🔑. Section 2.2 analyzes how key continuity relates to the attacks described here 🧐.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📏.

2. Unknown Key-Share Attack 🎭

in an unknown key-share attack [UKS], a malicious participant in a protocol claims to control a key that's actually controlled by some other actor 🕵️‍♀️. This happens when the identity linked to a key isn't properly bound to that key 🫠.

an endpoint that can get the certificate fingerprint of another entity can advertise that fingerprint as its own in SDP 🍓. An attacker can use a copy of that fingerprint to get a victim talking to another unaware victim, even though the first victim thinks it's talking to the attacker 🙃.

when the identity of communicating peers is set up by higher-layer signaling, like in SIP identity [SIP-ID] or WebRTC [WEBRTC-SEC], this lets an attacker bind their own identity to a session with any other entity 🎯.

the attacker gets an identity assertion for an identity it controls, but binds that to the fingerprint of one peer 🪄. Then the attacker can make a TLS connection get set up where two victim endpoints talk to each other 📡. The victim whose fingerprint got copied correctly believes it's talking to the other victim 🥰. The other victim, though, wrongly believes it's talking to the attacker 😱.

an unknown key-share attack doesn't give the attacker access to any confidential info exchanged between the victims 🤐. BUT the failed mutual authentication can enable other attacks 🚨. A victim might send information to the wrong entity because of this 📮. And where information gets interpreted in context, misrepresenting that context could lead to the information being misinterpreted 🌀.

a similar attack can be mounted using only the SDP "fingerprint" attribute [FINGERPRINT], without compromising the integrity of the signaling channel 🧩.

this attack is part of SDP-based protocols and it's something the technique called third-party call control (3PCC) [RFC3725] depends on 🧃. 3PCC takes advantage of the signaling peer's identity possibly being different from the media peer's, so the signaling peer gets to pick the media peer 🎬. Section 2.3 covers what the mitigations here mean for systems that use 3PCC 👀.

2.1. Limits on Attack Feasibility 🔒

the use of TLS with SDP depends on signaling integrity 🛡️. Assuming signaling integrity limits what an attacker can do in a few ways. In particular:

  1. An attacker can only modify the parts of the session signaling that they're responsible for producing, namely their own offers and answers 🙋‍♀️.
  2. No entity will successfully establish a session with a peer unless they're willing to take part in a session with that peer 🤝.

these two constraints together make the spectrum of possible attacks pretty limited 📉. An attacker can only swap its own certificate fingerprint for a valid certificate that its peer finds acceptable 🎟️. So attacks have to rely on joining two separate sessions into one single session 🧵. Section 4 describes an attack on SDP signaling under these constraints 🔍.

systems that rely on strong identity bindings, like the ones defined in [WEBRTC] or [SIP-ID], have a different threat model 🧠. That model allows for an attack by an entity with access to the signaling channel 📶. These attacks are more feasible in that case, because the attacker is assumed to be able to both observe and modify signaling messages 👁️. Section 3 describes an attack that assumes this threat model 💥.

2.2. Interactions with Key Continuity 🔑

systems that use key continuity (as defined in Section 15.1 of [ZRTP] or as recommended in Section 7 of [FINGERPRINT]) might be able to detect an unknown key-share attack 🕵️. This works if a session with either the attacker or the genuine peer (that is, the victim whose fingerprint was copied by an attacker) was set up in the past 🗂️. Whether that's possible depends on how key continuity is implemented 🛠️.

implementations that keep a single database of identities with an index of peer keys could notice that the identity saved for the peer key doesn't match the claimed identity 🧾. Such an implementation could spot the mismatch between the actual keys (the ones copied from a victim) and the expected keys (the ones belonging to the attacker) 🔎.

in comparison, implementations that match on peer identity first could treat an unknown key-share attack as though their peer had used a newly configured device 📱. That apparent new device could generate user-visible notices (for example, "Mallory appears to have a new device") 🚩. BUT such an event isn't always considered alarming, and some implementations might quietly save a new key 🤫.

2.3. Third-Party Call Control 📞✨

Okay so third-party call control (3PCC) [RFC3725] is when a signaling peer sets up a call that actually ends at a different entity. bestie, this is giving "someone else is on the line and you didn't even notice" 💀. An unknown key-share attack looks really similar to some 3PCC stuff, so 3PCC could look like an attack from the outside. 🙈 BUT 3PCC that follows RFC 3725 is totally unaffected, and peers who know about the changes a 3PCC controller makes can tell the controller apart from an attacker. Main character energy for the good guys 💅

3PCC as described in RFC 3725 doesn't play nicely with SIP identity [SIP-ID], because SIP Identity depends on making a binding between SIP requests and SDP. In RFC 3725, the controller is the only entity generating SIP requests 👑. So in a 3PCC setup, the only option is using the fingerprint attribute without extra bindings or WebRTC identity [WEBRTC-SEC]. Lowkey limited, but it works 🎀

The attack mitigations in this document will block 3PCC if the peers don't agree on the identities involved or on the value of the SDP tls-id attributes. Not me being the bouncer 🚫💖

For 3PCC to work with the proposed mechanisms, the TLS peers have to know about the signaling so they can correctly generate and check the TLS extensions 🧚. For a connection to get set up successfully, a 3PCC controller either has to forward the SDP without changing it, or avoid modifying the fingerprint, tls-id, and identity attributes 🌸. A controller following the best practices in RFC 3725 is expected to forward SDP without modification, which keeps the integrity of those attributes intact. ✨

3. Unknown Key-Share Attack with Identity Bindings 🦋

Okay so the identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) and the Personal Assertion Token (PASSporT) used in SIP identity ([SIP-ID], [PASSPORT]) are both tied to the certificate fingerprint of an endpoint 🔐. An attacker can create an identity binding that connects an identity they control to the fingerprint of a first victim. Yikes 😭

This means the attacker can convince a second victim that they're talking to an attacker-controlled identity, when they're actually talking to the first victim. The attacker pulls this off by making an identity assertion that covers a certificate fingerprint of the first victim. Literally so sneaky 🙈

A variation on the same trick can make both victims think they're talking to the attacker, when they're really talking to each other 🥴. In this version, the attacker does the identity misbinding once for each victim.

The authority that certifies the identity binding isn't required to check that the entity asking for the binding actually controls the keys tied to those fingerprints, and that might look like the root of the problem 👀. SIP and WebRTC identity providers are not required to do that validation either.

[SIGMA] suggests a simple fix 💡. The identity of each endpoint gets included under a message authentication code (MAC) during the cryptographic handshake. Then the endpoints check that their peer gave an identity that matches what they expected. In TLS, the Finished message gives a MAC over the entire handshake, so putting the identity in a TLS extension is enough to make this work 🫶

Instead of including a full identity binding, which could be pretty chunky 🍓, a collision- and preimage-resistant hash of the binding goes into a TLS extension, as described in Section 3.2. Endpoints then only need to check that the extension has a hash of the identity binding they got through signaling. If the identity binding checks out, the peer's identity is verified and bound to the session ✅

This form of unknown key-share attack is possible without breaking signaling integrity, unless the defenses in Section 4 are used. To stop both forms of the attack, endpoints MUST use the external_session_id extension (see Section 4.3) in addition to the external_id_hash (Section 3.2), so that two calls between the same parties can't be altered by an attacker 🔥

3.1. Example 🎬

In the example shown in Figure 1, it's assumed that the attacker also controls the signaling channel 😈.

Mallory (the attacker) presents two victims, Norma and Patsy, with two separate sessions. In the first session, Norma is given the option to communicate with Mallory, and a second session with Norma is presented to Patsy 🙃.

  Norma                   Mallory                   Patsy
  (fp=N)                   -----                    (fp=P)
    |                        |                        |
    |<---- Signaling1 ------>|                        |
    |   Norma=N Mallory=P    |                        |
    |                        |<---- Signaling2 ------>|
    |                        |   Norma=N Patsy=P      |
    |                                                 |
    |<=================DTLS (fp=N,P)=================>|
    |                                                 |
  (peer = Mallory!)                         (peer = Norma)

            Figure 1: Example Attack on Identity Bindings

The attack needs Mallory to get an identity binding for her own identity with the fingerprints Patsy (P) presents, which Mallory might have grabbed earlier 🕵️‍♀️. Then this fake binding gets presented to Norma ('Signaling1' in Figure 1).

Patsy could be tricked in a similar way, but in this example, a correct binding between Norma's identity and fingerprint (N) is faithfully passed along by Mallory. This session ('Signaling2' in Figure 1) can be totally legit 🥰.

A DTLS session gets set up directly between Norma and Patsy. For this to happen, Mallory can swap out transport-level information in both sessions, although she doesn't need to if she's already on the network path between Norma and Patsy 🛤️.

So Patsy correctly believes she's talking to Norma. Norma, however, incorrectly believes she's talking to Mallory 😭. As stated in Section 2, Mallory can't access media, but Norma might send information to Patsy that Norma didn't intend to share, or that Patsy might misread 💀.

3.2. The "external_id_hash" TLS Extension 🔑

The external_id_hash TLS extension carries a hash of the identity assertion that the endpoint sending the extension has asserted to its peer. Both peers include a hash of their own identity assertion 🫶.

The extension_data for the external_id_hash extension contains an ExternalIdentityHash struct, described below using the syntax defined in Section 3 of [TLS13]:

   struct {
      opaque binding_hash<0..32>;
   } ExternalIdentityHash;

When a peer has asserted an identity assertion, this extension includes a SHA-256 hash of that assertion. An empty value is used to indicate support for the extension ✨.

Note: For both types of identity assertion, if SHA-256 turns out to be inadequate in the future (see [AGILITY]), a new TLS extension that uses a different hash function can be defined 🔮.

Identity bindings might only be provided by one peer 🌈. An endpoint that doesn't 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 🧸.

A peer that receives an external_id_hash extension that doesn't 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. If a peer provided no identity binding, a zero-length extension MUST be present to be considered valid 💅.

Implementations written before the extensions in this document were defined won't support this extension for some time 🐢. A peer that receives an identity binding but doesn't receive an external_id_hash extension MAY accept a TLS connection instead of failing a connection where the extension is absent 🤷‍♀️.

The endpoint does the validation of the external_id_hash extension on top of the validation required by [FINGERPRINT] and any verification of the identity assertion [WEBRTC-SEC] [SIP-ID]. An endpoint MUST validate any external_session_id value that's present; see Section 4.3 📋.

An external_id_hash extension with a binding_hash field that is any length other than 0 or 32 is invalid and MUST cause the receiving endpoint to generate a fatal decode_error alert ❌.

In TLS 1.3, an external_id_hash extension sent by a server MUST be sent in the EncryptedExtensions message 🎀.

3.2.1. Calculating "external_id_hash" for WebRTC Identity 🌸

A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided as a JSON [JSON] object that gets encoded into a JSON text. The JSON text is encoded using UTF-8 [UTF8] as described by Section 8.1 of [JSON]. The content of the external_id_hash extension is produced by hashing the resulting octets with SHA-256 [SHA]. This gives the 32 octets of the binding_hash parameter, which is the sole content of the extension 💖.

The SDP identity attribute includes the base64 [BASE64] encoding of the UTF-8 encoding of that same JSON text. The external_id_hash extension gets validated by base64-decoding the value of the SDP identity attribute, hashing the resulting octets with SHA-256, and comparing the result with the content of the extension. In pseudocode form, using the identity-assertion-value field from the SDP identity attribute grammar as defined in [WEBRTC-SEC]:

external_id_hash = SHA-256(b64decode(identity-assertion-value))

Note: The base64 of the SDP identity attribute gets decoded so that variations in padding aren't captured. The base64-decoded identity assertion could include leading or trailing whitespace octets. WebRTC identity assertions are not canonicalized, so all octets are hashed 🧐.

3.2.2. Calculating external_id_hash for PASSporT 📨

Where the compact form of PASSporT [PASSPORT] is used, it MUST be expanded into the full form. The base64 encoding used in the SIP Identity (or 'y') header field MUST be decoded and then used as input to SHA-256. This gives the 32-octet binding_hash value used for creating or validating the extension. In pseudocode, using the signed-identity-digest parameter from the Identity header field grammar defined [SIP-ID]:

external_id_hash = SHA-256(b64decode(signed-identity-digest))

4. Unknown Key-Share Attack with Fingerprints ✨

okay so this one is about DTLS-SRTP 🎀 The attack works because the peers' identities aren't established before the call even starts. Endpoints lean on certificate fingerprints as a stand-in for authentication, but as long as the same fingerprints get reused across multiple calls, they're open to attack 💀

Even if you can totally trust the session signaling, an attacker can still make a session where everyone's confused about who they're talking to, just by swapping in the fingerprint of one of the communicating endpoints 🙈

An endpoint that's set up to reuse a certificate is vulnerable if it's willing to start two calls at the same time, and one of them is with the attacker. The attacker can make the victim genuinely believe it's calling the attacker, when it's actually calling a second party 😭 Meanwhile, that second party is totally sure it's talking to the victim.

Just like the identity-binding attack, this can be used to get two victims both thinking they're talking to the attacker, when they're really talking to each other 🦋

4.1. Example

Okay, so to pull this off, two sessions have to be set up with the same endpoint at almost exactly the same time 🕰️ One session starts with the attacker, and the other is created toward a different honest endpoint. The attacker convinces the first endpoint that its session with the attacker worked, but the media is actually going to the other honest endpoint 💅 The attacker only lets the session with the other honest endpoint finish as much as it needs to, just so that endpoint goes along with the attacked session.

On top of the constraints from Section 2.1, the attacker in this example also has to be able to see and drop packets between the victims. Basically, the attacker needs to be on path for the media 🧚

The attack in Figure 2 depends on a kinda unlikely set of conditions 😅 It's there to show what kind of attack is possible and what has to line up for someone to exploit this weakness in the protocol.

     Norma                   Mallory                 Patsy
     (fp=N)                   -----                  (fp=P)
       |                        |                      |
       +---Signaling1 (fp=N)--->|                      |
       +-----Signaling2 (fp=N)------------------------>|
       |<-------------------------Signaling2 (fp=P)----+
       |<---Signaling1 (fp=P)---+                      |
       |                        |                      |
       |=======DTLS1=======>(Forward)======DTLS1======>|
       |<======DTLS2========(Forward)<=====DTLS2=======|
       |=======Media1======>(Forward)======Media1=====>|
       |<======Media2=======(Forward)<=====Media2======|
       |                       |                       |
       |=======DTLS2========>(Drop)                    |
       |                       |                       |

Figure 2: Example Attack Scenario Using Fingerprints

In this scenario, Norma starts two sessions at the same time 🌸 Signaling is shown with single lines ('-'), and DTLS and media are shown with double lines ('=').

The first session is set up with Mallory, who lies and uses Patsy's certificate fingerprint (written as 'fp=P'). A second session gets started between Norma and Patsy. Signaling for both sessions is allowed to finish 🫶

Once signaling wraps up on the first session, a DTLS connection gets established. It looks like it's between Mallory and Norma, but Mallory forwards the DTLS and media packets Norma sends her over to Patsy 👀 These packets are labeled 'DTLS1' because Norma ties them to the first signaling session ('Signaling1').

Mallory also grabs packets coming from Patsy and passes them on to Norma, at the transport address Norma links to Mallory. These are labeled 'DTLS2' because Patsy ties them to the second signaling session ('Signaling2'). But Norma reads them as belonging to the first signaling session ('Signaling1') 😭

The second signaling exchange ('Signaling2'), between Norma and Patsy, is allowed to keep going until Patsy thinks it worked. This makes sure Patsy really believes she's talking to Norma 💖 In the end, Norma thinks she's talking to Mallory, when she's actually talking to Patsy. Just like the example in Section 3.1, Mallory can't get to the media, but Norma might send Patsy information she didn't mean to share, or that Patsy could misread 🙈

Patsy needs to believe the second session was set up successfully, but Mallory doesn't actually care about that session working out. Mallory just needs Patsy to keep the active session going and not give up on it too early 💅 So it might be necessary to let the signaling from Patsy reach Norma, so Patsy can get a call setup completion signal, like a SIP ACK. Once the second session is up, Mallory might drop the DTLS packets Norma sends to Patsy. But if Mallory lets those DTLS packets through, Patsy will probably throw them away, since she already has a working DTLS connection set up 🍓

For the attacked session to keep going after Norma notices errors in the second session, Mallory also has to block any signaling Norma might send to Patsy asking for the call to be dropped. Otherwise, Patsy could get a notice that the call failed and end the call 😤

This attack makes the two sides disagree about who they're talking to 🚨 But it only works if the victim (Norma) is willing to run two sessions nearly at once, if the attacker (Mallory) is on the network path between the victims, and if Norma uses the same certificate, and therefore the same SDP "fingerprint" attribute value, for both sessions.

Where Interactive Connectivity Establishment (ICE) [ICE] is used, Mallory also has to make sure the connectivity checks between Patsy and Norma succeed, either by forwarding the checks or by answering them and generating the messages that are needed 🧠

4.2. Unique Session Identity Solution

The fix for this problem is to give each communicating peer a new identifier 🎀 Each endpoint gives its peer a unique identifier during call signaling. The peer then repeats that identifier in the TLS handshake, which binds that identity into the session. Putting this new identity in the TLS handshake means it's covered by the TLS Finished message, which is what authenticates it (see [SIGMA]) 🔐

If the identifier checks out as matching the expected value, then the connection matches the signaled session and is established between the right two endpoints ✨

This solution depends on the unique identifier that DTLS sessions get from the SDP "tls-id" attribute [DTLS-SDP]. That field is already required to be unique, so no two offers or answers from the same client will have the same value 💜

A new "external_session_id" extension is added to the TLS or DTLS handshake for connections that are set up as part of the same call or real-time session. It carries the value of the "tls-id" attribute and gives integrity protection to the exchange of that value as part of the TLS or DTLS handshake 🛡️

4.3. The external_session_id TLS Extension

The "external_session_id" TLS extension carries the unique identifier that an endpoint picks 🦋 When it's used with SDP, the value MUST include the "tls-id" attribute from the SDP that the endpoint generated while negotiating the session. This document only defines using this extension for SDP. Other methods of external session negotiation can use this extension to include a unique session identifier too 🌈

The "extension_data" for the "external_session_id" extension holds an ExternalSessionId struct. It's described below using the syntax defined in [TLS13] 📝

   struct {
      opaque session_id<20..255>;
   } ExternalSessionId;

For SDP, the "session_id" field of the extension includes the value of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls-id-value" ABNF production). The value of the "tls-id" attribute is encoded using ASCII [ASCII] 🔤

When RTP and RTCP [RTP] aren't multiplexed, it's possible for the two separate DTLS connections that carry RTP and RTCP to get switched. This is considered benign, since these protocols are designed to be distinguishable, as SRTP [SRTP] provides key separation. Using RTP/RTCP multiplexing [RTCP-MUX] avoids this problem even more 🌸

The "external_session_id" extension is included in a ClientHello. If the extension is present in the ClientHello, it's also included in either the ServerHello (for TLS and DTLS versions older than 1.3) or the EncryptedExtensions (for TLS 1.3) 💫

Endpoints MUST check that the "session_id" parameter in the extension they receive includes the "tls-id" attribute value they got in their peer's session description. Endpoints can do the comparison by ASCII decoding the TLS extension value and comparing it to the SDP attribute value, or by comparing the encoded TLS extension octets with the encoded SDP attribute value 🧐 An endpoint that gets an "external_session_id" extension that isn't identical to the value it expects MUST abort the connection with a fatal "illegal_parameter" alert 🚫

The endpoint also validates the "external_id_hash" extension, in addition to the validation required by [FINGERPRINT] 💅

If an endpoint talks to a peer that doesn't support this extension, it'll get a ClientHello, ServerHello, or EncryptedExtensions message that doesn't include the extension. An endpoint MAY choose to keep going without this extension, so it can interoperate with peers that don't implement this specification 🤝

In TLS 1.3, an "external_session_id" extension sent by a server MUST be sent in the EncryptedExtensions message 🍓

This defense doesn't work if an attacker can rewrite "tls-id" values in signaling 😱 Only the mechanism in "external_id_hash" can defend against an attacker that can compromise session integrity.

5. Session Concatenation 🎀

Okay so, using session identifiers doesn't stop an attacker from opening two concurrent sessions with different peers and forwarding signaling between them 💀. Concatenating two signaling sessions like this gives you two signaling sessions with two session identifiers, but only the TLS connections from one session actually get set up. The attacker ends up in a situation where both peers think they're talking to the attacker, when they're really talking to each other 🙈.

Without any higher-level concept of peer identity, an attacker who can copy a session identifier from one signaling session into another can get the peers to set up a direct TLS connection while they still think they're connecting to the attacker 😭. This is different from the attack in the previous section because there's only one TLS connection instead of two. Systems that enable peer authentication, like WebRTC identity [WEBRTC-SEC] or SIP identity [SIP-ID], prevent this kind of attack ✨. They don't, however, prevent the two back-to-back connections from the previous paragraph.

Using external_session_id doesn't guarantee that the TLS-layer identity of a peer matches the identity of its signaling peer 🧚. The attacker's gain from concatenating sessions stays limited unless data gets exchanged on the assumption that the signaling and TLS peers are the same. If a secondary protocol uses the signaling channel while assuming the signaling and TLS peers are the same, then that protocol is vulnerable to attack 🔥. This document doesn't cover it, but a signaling system that can defend against session concatenation needs its signaling layer to be authenticated and bound to any TLS connections 💜.

Multiple connections can be created within the same signaling session, and that's important to remember 🦋. An attacker might concatenate only part of a session, terminating some connections (and optionally forwarding data) while arranging for peers to interact directly over others. It's even possible for different peers to interact over each connection. So the actual identity of the peer on one connection might be different from the peer on another connection 👑.

Here's the critical bit: information about the identity of TLS peers gives no assurance about the identity of signaling peers, and it doesn't carry over between TLS connections in the same session 🚨. So 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. Similarly, security-sensitive information from one TLS connection MUST NOT be used in other TLS connections, even if they were established as a result of the same signaling session 🫶.

6. Security Considerations 🔒

Okay, serious moment, bestie 😤. When you combine the mitigations in this document with identity assertions, there is no opportunity to misrepresent the identity of TLS peers ✨. And this assurance holds even if an attacker can modify signaling messages 💅.

Without identity assertions, the mitigations in this document still prevent the session splicing attack described in Section 4 🛡️. Defense against session concatenation (Section 5) additionally requires that protocol peers are not able to claim the certificate fingerprints of other entities 🚫. No cap, this part is non-negotiable 💀.

7. IANA Considerations 🌸

Two extensions get registered in the "TLS ExtensionType Values" registry set up in [TLS13] 🎀:

  • The "external_id_hash" extension defined in Section 3.2 has been assigned a code point of 55. It is recommended and is marked as "CH, EE" in TLS 1.3 ✨.
  • The "external_session_id" extension defined in Section 4.3 has been assigned a code point of 56. It is recommended and is marked as "CH, EE" in TLS 1.3 💖.

8. References 📚

8.1. Normative References

[ASCII]    Cerf, V., "ASCII format for network interchange", STD 80,
           RFC 20, DOI 10.17487/RFC0020, October 1969,
           <https://www.rfc-editor.org/info/rfc20>.

[BASE64]   Josefsson, S., "The Base16, Base32, and Base64 Data
           Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
           <https://www.rfc-editor.org/info/rfc4648>.

[DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
           January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[DTLS-SDP] Holmberg, C. and R. Shpount, "Session Description Protocol
           (SDP) Offer/Answer Considerations for Datagram Transport
           Layer Security (DTLS) and Transport Layer Security (TLS)",
           RFC 8842, DOI 10.17487/RFC8842, January 2021,
           <https://www.rfc-editor.org/info/rfc8842>.

[DTLS-SRTP]
           Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
           for Establishing a Secure Real-time Transport Protocol
           (SRTP) Security Context Using Datagram Transport Layer
           Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
           2010, <https://www.rfc-editor.org/info/rfc5763>.

[FINGERPRINT]
           Lennox, J. and C. Holmberg, "Connection-Oriented Media
           Transport over the Transport Layer Security (TLS) Protocol
           in the Session Description Protocol (SDP)", RFC 8122,
           DOI 10.17487/RFC8122, March 2017,
           <https://www.rfc-editor.org/info/rfc8122>.

[JSON]     Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", STD 90, RFC 8259,
           DOI 10.17487/RFC8259, December 2017,
           <https://www.rfc-editor.org/info/rfc8259>.

[PASSPORT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
           Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
           <https://www.rfc-editor.org/info/rfc8225>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[SDP]      Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
           July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[SHA]      Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234,
           DOI 10.17487/RFC6234, May 2011,
           <https://www.rfc-editor.org/info/rfc6234>.

[SIP-ID]   Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
           "Authenticated Identity Management in the Session
           Initiation Protocol (SIP)", RFC 8224,
           DOI 10.17487/RFC8224, February 2018,
           <https://www.rfc-editor.org/info/rfc8224>.

[SRTP]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, DOI 10.17487/RFC3711, March 2004,
           <https://www.rfc-editor.org/info/rfc3711>.

[TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[WEBRTC-SEC]
           Rescorla, E., "WebRTC Security Architecture", RFC 8827,
           DOI 10.17487/RFC8827, January 2021,
           <https://www.rfc-editor.org/info/rfc8827>.

8.2. Informative References

[AGILITY]  Housley, R., "Guidelines for Cryptographic Algorithm
           Agility and Selecting Mandatory-to-Implement Algorithms",
           BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
           <https://www.rfc-editor.org/info/rfc7696>.

[ICE]      Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
           Camarillo, "Best Current Practices for Third Party Call
           Control (3pcc) in the Session Initiation Protocol (SIP)",
           BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
           <https://www.rfc-editor.org/info/rfc3725>.

[RTCP-MUX] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
           Control Packets on a Single Port", RFC 5761,
           DOI 10.17487/RFC5761, April 2010,
           <https://www.rfc-editor.org/info/rfc5761>.

[RTP]      Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
           July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[SIGMA]    Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
           Authenticated Diffie-Hellman and Its Use in the IKE
           Protocols", Advances in Cryptology -- CRYPTO 2003, Lecture
           Notes in Computer Science, Vol. 2729,
           DOI 10.1007/978-3-540-45146-4_24, August 2003,
           <https://doi.org/10.1007/978-3-540-45146-4_24>.

[UKS]      Blake-Wilson, S. and A. Menezes, "Unknown Key-Share
           Attacks on the Station-to-Station (STS) Protocol", Public
           Key Cryptography, Lecture Notes in Computer Science, Vol.
           1560, DOI 10.1007/3-540-49162-7_12, March 1999,
           <https://doi.org/10.1007/3-540-49162-7_12>.

[WEBRTC]   Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
           Real-time Communication Between Browsers", W3C Proposed
           Recommendation, <https://www.w3.org/TR/webrtc/>.

[ZRTP]     Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
           Media Path Key Agreement for Unicast Secure RTP",
           RFC 6189, DOI 10.17487/RFC6189, April 2011,
           <https://www.rfc-editor.org/info/rfc6189>.

Acknowledgements 💜

This problem would never have been discovered without discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes 🙌. A solution similar to the one presented here was first proposed by Karthik Bhargavan, who also gave valuable input on this document ✨. Thyla van der Merwe helped with a formal model of the solution 🧠. Adam Roach and Paul E. Jones provided significant review and input 🫶.

Authors' Addresses 🦋

Martin Thomson Mozilla Email: mt@lowentropy.net

Eric Rescorla Mozilla Email: ekr@rtfm.com

📦 where this page comes from