doc: Add RFC documents

1 files changed, 894 insertions, 0 deletions

diff --git a/doc/rfc/rfc8844.txt b/doc/rfc/rfc8844.txt
new file mode 100644
index 0000000..282848b
--- /dev/null
+++ b/doc/rfc/rfc8844.txt
@@ -0,0 +1,894 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Thomson
+Request for Comments: 8844                                   E. Rescorla
+Updates: 8122                                                    Mozilla
+Category: Standards Track                                   January 2021
+ISSN: 2070-1721
+
+
+ Unknown Key-Share Attacks on Uses of TLS with the Session Description
+                             Protocol (SDP)
+
+Abstract
+
+   This document describes unknown key-share attacks on the use of
+   Datagram Transport Layer Security for the Secure Real-Time Transport
+   Protocol (DTLS-SRTP).  Similar attacks are described on the use of
+   DTLS-SRTP with the identity bindings used in Web Real-Time
+   Communications (WebRTC) and SIP identity.  These attacks are
+   difficult to mount, but they cause a victim to be misled about the
+   identity of a communicating peer.  This document defines mitigation
+   techniques that implementations of RFC 8122 are encouraged to deploy.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8844.
+
+Copyright Notice
+
+   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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+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
+
+   The use of Transport Layer Security (TLS) [TLS13] with the Session
+   Description Protocol (SDP) [SDP] is defined in [FINGERPRINT].
+   Further use with Datagram Transport Layer Security (DTLS) [DTLS] and
+   the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as
+   DTLS-SRTP [DTLS-SRTP].
+
+   In these specifications, key agreement is performed using TLS or
+   DTLS, with authentication being tied back to the session description
+   (or SDP) through the use of certificate fingerprints.  Communication
+   peers check that a hash, or fingerprint, provided in the SDP matches
+   the certificate that is used in the TLS or DTLS handshake.
+
+   WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity
+   [SIP-ID] both provide a mechanism that binds an external identity to
+   the certificate fingerprints from a session description.  However,
+   this binding is not integrity protected and is therefore vulnerable
+   to an identity misbinding attack, also known as an unknown key-share
+   (UKS) attack, where the attacker binds their identity to the
+   fingerprint of another entity.  A successful attack leads to the
+   creation of sessions where peers are confused about the identity of
+   the participants.
+
+   This document describes a TLS extension that can be used in
+   combination with these identity bindings to prevent this attack.
+
+   A similar attack is possible with the use of certificate fingerprints
+   alone.  Though attacks in this setting are likely infeasible in
+   existing deployments due to the narrow preconditions (see
+   Section 2.1), this document also describes mitigations for this
+   attack.
+
+   The mechanisms defined in this document are intended to strengthen
+   the protocol by preventing the use of unknown key-share attacks in
+   combination with other protocol or implementation vulnerabilities.
+   RFC 8122 [FINGERPRINT] is updated by this document to recommend the
+   use of these mechanisms.
+
+   This document assumes that signaling is integrity protected.
+   However, as Section 7 of [FINGERPRINT] explains, many deployments
+   that use SDP do not guarantee integrity of session signaling and so
+   are vulnerable to other attacks.  [FINGERPRINT] offers key continuity
+   mechanisms as a potential means of reducing exposure to attack in the
+   absence of integrity protection.  Section 2.2 provides some analysis
+   of the effect of key continuity in relation to the described attacks.
+
+   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 is in reality controlled by
+   some other actor.  This arises when the identity associated with a
+   key is not properly bound to the key.
+
+   An endpoint that can acquire the certificate fingerprint of another
+   entity can advertise that fingerprint as their own in SDP.  An
+   attacker can use a copy of that fingerprint to cause a victim to
+   communicate with another unaware victim, even though the first victim
+   believes that it is communicating with the attacker.
+
+   When the identity of communicating peers is established by higher-
+   layer signaling constructs, such as those in SIP identity [SIP-ID] or
+   WebRTC [WEBRTC-SEC], this allows an attacker to bind their own
+   identity to a session with any other entity.
+
+   The attacker obtains an identity assertion for an identity it
+   controls, but binds that to the fingerprint of one peer.  The
+   attacker is then able to cause a TLS connection to be established
+   where two victim endpoints communicate.  The victim that has its
+   fingerprint copied by the attack correctly believes that it is
+   communicating with the other victim; however, the other victim
+   incorrectly believes that it is communicating with the attacker.
+
+   An unknown key-share attack does not result in the attacker having
+   access to any confidential information exchanged between victims.
+   However, the failure in mutual authentication can enable other
+   attacks.  A victim might send information to the wrong entity as a
+   result.  Where information is interpreted in context, misrepresenting
+   that context could lead to the information being misinterpreted.
+
+   A similar attack can be mounted based solely on the SDP "fingerprint"
+   attribute [FINGERPRINT] without compromising the integrity of the
+   signaling channel.
+
+   This attack is an aspect of SDP-based protocols upon which the
+   technique known as third-party call control (3PCC) [RFC3725] relies.
+   3PCC exploits the potential for the identity of a signaling peer to
+   be different than the media peer, allowing the media peer to be
+   selected by the signaling peer.  Section 2.3 describes the
+   consequences of the mitigations described here for systems that use
+   3PCC.
+
+2.1.  Limits on Attack Feasibility
+
+   The use of TLS with SDP depends on the integrity of session
+   signaling.  Assuming signaling integrity limits the capabilities of
+   an attacker in several ways.  In particular:
+
+   1.  An attacker can only modify the parts of the session signaling
+       that they are responsible for producing, namely their own offers
+       and answers.
+
+   2.  No entity will successfully establish a session with a peer
+       unless they are willing to participate in a session with that
+       peer.
+
+   The combination of these two constraints make the spectrum of
+   possible attacks quite limited.  An attacker is only able to switch
+   its own certificate fingerprint for a valid certificate that is
+   acceptable to its peer.  Attacks therefore rely on joining two
+   separate sessions into a single session.  Section 4 describes an
+   attack on SDP signaling under these constraints.
+
+   Systems that rely on strong identity bindings, such as those defined
+   in [WEBRTC] or [SIP-ID], have a different threat model, which admits
+   the possibility of attack by an entity with access to the signaling
+   channel.  Attacks under these conditions are more feasible as an
+   attacker is assumed to be able both to observe and to 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 if a session with either the
+   attacker or the genuine peer (i.e., the victim whose fingerprint was
+   copied by an attacker) was established in the past.  Whether this is
+   possible depends on how key continuity is implemented.
+
+   Implementations that maintain a single database of identities with an
+   index of peer keys could discover that the identity saved for the
+   peer key does not match the claimed identity.  Such an implementation
+   could notice the disparity between the actual keys (those copied from
+   a victim) and the expected keys (those of the attacker).
+
+   In comparison, implementations that first match based on peer
+   identity could treat an unknown key-share attack as though their peer
+   had used a newly configured device.  The apparent addition of a new
+   device could generate user-visible notices (e.g., "Mallory appears to
+   have a new device").  However, such an event is not always considered
+   alarming; some implementations might silently save a new key.
+
+2.3.  Third-Party Call Control
+
+   Third-party call control (3PCC) [RFC3725] is a technique where a
+   signaling peer establishes a call that is terminated by a different
+   entity.  An unknown key-share attack is very similar in effect to
+   some 3PCC practices, so use of 3PCC could appear to be an attack.
+   However, 3PCC that follows RFC 3725 guidance is unaffected, and peers
+   that are aware of changes made by a 3PCC controller can correctly
+   distinguish actions of a 3PCC controller from an attack.
+
+   3PCC as described in RFC 3725 is incompatible with SIP identity
+   [SIP-ID], as SIP Identity relies on creating a binding between SIP
+   requests and SDP.  The controller is the only entity that generates
+   SIP requests in RFC 3725.  Therefore, in a 3PCC context, only the use
+   of the "fingerprint" attribute without additional bindings or WebRTC
+   identity [WEBRTC-SEC] is possible.
+
+   The attack mitigation mechanisms described in this document will
+   prevent the use of 3PCC if peers have different views of the involved
+   identities or the value of SDP "tls-id" attributes.
+
+   For 3PCC to work with the proposed mechanisms, TLS peers need to be
+   aware of the signaling so that they can correctly generate and check
+   the TLS extensions.  For a connection to be successfully established,
+   a 3PCC controller needs either to forward SDP without modification or
+   to avoid modifications to "fingerprint", "tls-id", and "identity"
+   attributes.  A controller that follows the best practices in RFC 3725
+   is expected to forward SDP without modification, thus ensuring the
+   integrity of these attributes.
+
+3.  Unknown Key-Share Attack with Identity Bindings
+
+   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 bound to the certificate fingerprint of an
+   endpoint.  An attacker can cause an identity binding to be created
+   that binds an identity they control to the fingerprint of a first
+   victim.
+
+   An attacker can thereby cause a second victim to believe that they
+   are communicating with an attacker-controlled identity, when they are
+   really talking to the first victim.  The attacker does this by
+   creating an identity assertion that covers a certificate fingerprint
+   of the first victim.
+
+   A variation on the same technique can be used to cause both victims
+   to believe they are talking to the attacker when they are talking to
+   each other.  In this case, the attacker performs the identity
+   misbinding once for each victim.
+
+   The authority certifying the identity binding is not required to
+   verify that the entity requesting the binding actually controls the
+   keys associated with the fingerprints, and this might appear to be
+   the cause of the problem.  SIP and WebRTC identity providers are not
+   required to perform this validation.
+
+   A simple solution to this problem is suggested by [SIGMA].  The
+   identity of endpoints is included under a message authentication code
+   (MAC) during the cryptographic handshake.  Endpoints then validate
+   that their peer has provided an identity that matches their
+   expectations.  In TLS, the Finished message provides a MAC over the
+   entire handshake, so that including the identity in a TLS extension
+   is sufficient to implement this solution.
+
+   Rather than include a complete identity binding, which could be
+   sizable, a collision- and preimage-resistant hash of the binding is
+   included in a TLS extension as described in Section 3.2.  Endpoints
+   then need only validate that the extension contains a hash of the
+   identity binding they received in signaling.  If the identity binding
+   is successfully validated, the identity of a peer is verified and
+   bound to the session.
+
+   This form of unknown key-share attack is possible without
+   compromising signaling integrity, unless the defenses described in
+   Section 4 are used.  In order to prevent both forms of 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 is 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 presented with
+   the option to communicate with Mallory; 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 requires that Mallory obtain an identity binding for her
+   own identity with the fingerprints presented by Patsy (P), which
+   Mallory might have obtained previously.  This false binding is then
+   presented to Norma ('Signaling1' in Figure 1).
+
+   Patsy could be similarly duped, but in this example, a correct
+   binding between Norma's identity and fingerprint (N) is faithfully
+   presented by Mallory.  This session ('Signaling2' in Figure 1) can be
+   entirely legitimate.
+
+   A DTLS session is established directly between Norma and Patsy.  In
+   order for this to happen, Mallory can substitute transport-level
+   information in both sessions, though this is not necessary if Mallory
+   is on the network path between Norma and Patsy.
+
+   As a result, Patsy correctly believes that she is communicating with
+   Norma.  However, Norma incorrectly believes that she is talking to
+   Mallory.  As stated in Section 2, Mallory cannot access media, but
+   Norma might send information to Patsy that Norma might not intend or
+   that Patsy might misinterpret.
+
+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 a
+   "ExternalIdentityHash" struct, described below using the syntax
+   defined in Section 3 of [TLS13]:
+
+      struct {
+         opaque binding_hash<0..32>;
+      } ExternalIdentityHash;
+
+   Where an identity assertion has been asserted by a peer, this
+   extension includes a SHA-256 hash of the assertion.  An empty value
+   is used to indicate support for the extension.
+
+   Note:  For both types of identity assertion, if SHA-256 should prove
+      to be inadequate in the future (see [AGILITY]), a new TLS
+      extension that uses a different hash function can be defined.
+
+   Identity bindings might be provided by only one peer.  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.
+
+   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;
+   if a peer provided no identity binding, a zero-length extension MUST
+   be present to be considered valid.
+
+   Implementations written prior to the definition of the extensions in
+   this document will not support this extension for some time.  A peer
+   that receives an identity binding but does not receive an
+   "external_id_hash" extension MAY accept a TLS connection rather than
+   fail a connection where the extension is absent.
+
+   The endpoint performs the validation of the "external_id_hash"
+   extension in addition to 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 is 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 is 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 produces
+   the 32 octets of the "binding_hash" parameter, which is the sole
+   contents of the extension.
+
+   The SDP "identity" attribute includes the base64 [BASE64] encoding of
+   the UTF-8 encoding of the same JSON text.  The "external_id_hash"
+   extension is validated by performing base64 decoding on the value of
+   the SDP "identity" attribute, hashing the resulting octets using
+   SHA-256, and comparing the results 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 is decoded to avoid
+      capturing variations in padding.  The base64-decoded identity
+      assertion could include leading or trailing whitespace octets.
+      WebRTC identity assertions are not canonicalized; 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 then used as input to
+   SHA-256.  This produces 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
+
+   An attack on DTLS-SRTP is possible because the identity of peers
+   involved is not established prior to establishing the call.
+   Endpoints use certificate fingerprints as a proxy for authentication,
+   but as long as fingerprints are used in multiple calls, they are
+   vulnerable to attack.
+
+   Even if the integrity of session signaling can be relied upon, an
+   attacker might still be able to create a session where there is
+   confusion about the communicating endpoints by substituting the
+   fingerprint of a communicating endpoint.
+
+   An endpoint that is configured to reuse a certificate can be attacked
+   if it is willing to initiate two calls at the same time, one of which
+   is with an attacker.  The attacker can arrange for the victim to
+   incorrectly believe that it is calling the attacker when it is in
+   fact calling a second party.  The second party correctly believes
+   that it is talking to the victim.
+
+   As with the attack on identity bindings, this can be used to cause
+   two victims to both believe they are talking to the attacker when
+   they are talking to each other.
+
+4.1.  Example
+
+   To mount this attack, two sessions need to be created with the same
+   endpoint at almost precisely the same time.  One of those sessions is
+   initiated with the attacker, the second session is created toward
+   another honest endpoint.  The attacker convinces the first endpoint
+   that their session with the attacker has been successfully
+   established, but media is exchanged with the other honest endpoint.
+   The attacker permits the session with the other honest endpoint to
+   complete only to the extent necessary to convince the other honest
+   endpoint to participate in the attacked session.
+
+   In addition to the constraints described in Section 2.1, the attacker
+   in this example also needs the ability to view and drop packets
+   between victims.  That is, the attacker needs to be on path for
+   media.
+
+   The attack shown in Figure 2 depends on a somewhat implausible set of
+   conditions.  It is intended to demonstrate what sort of attack is
+   possible and what conditions are necessary 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, there are two sessions initiated at the same time
+   by Norma.  Signaling is shown with single lines ('-'), DTLS and media
+   with double lines ('=').
+
+   The first session is established with Mallory, who falsely uses
+   Patsy's certificate fingerprint (denoted with 'fp=P').  A second
+   session is initiated between Norma and Patsy.  Signaling for both
+   sessions is permitted to complete.
+
+   Once signaling is complete on the first session, a DTLS connection is
+   established.  Ostensibly, this connection is between Mallory and
+   Norma, but Mallory forwards DTLS and media packets sent to her by
+   Norma to Patsy.  These packets are denoted 'DTLS1' because Norma
+   associates these with the first signaling session ('Signaling1').
+
+   Mallory also intercepts packets from Patsy and forwards those to
+   Norma at the transport address that Norma associates with Mallory.
+   These packets are denoted 'DTLS2' to indicate that Patsy associates
+   these with the second signaling session ('Signaling2'); however,
+   Norma will interpret these as being associated with the first
+   signaling session ('Signaling1').
+
+   The second signaling exchange ('Signaling2'), which is between Norma
+   and Patsy, is permitted to continue to the point where Patsy believes
+   that it has succeeded.  This ensures that Patsy believes that she is
+   communicating with Norma.  In the end, Norma believes that she is
+   communicating with Mallory, when she is really communicating with
+   Patsy.  Just like the example in Section 3.1, Mallory cannot access
+   media, but Norma might send information to Patsy that Norma might not
+   intend or that Patsy might misinterpret.
+
+   Though Patsy needs to believe that the second signaling session has
+   been successfully established, Mallory has no real interest in seeing
+   that session also be established.  Mallory only needs to ensure that
+   Patsy maintains the active session and does not abandon the session
+   prematurely.  For this reason, it might be necessary to permit the
+   signaling from Patsy to reach Norma in order to allow Patsy to
+   receive a call setup completion signal, such as a SIP ACK.  Once the
+   second session is established, Mallory might cause DTLS packets sent
+   by Norma to Patsy to be dropped.  However, if Mallory allows DTLS
+   packets to pass, it is likely that Patsy will discard them as Patsy
+   will already have a successful DTLS connection established.
+
+   For the attacked session to be sustained beyond the point that Norma
+   detects errors in the second session, Mallory also needs to block any
+   signaling that Norma might send to Patsy asking for the call to be
+   abandoned.  Otherwise, Patsy might receive a notice that the call has
+   failed and thereby abort the call.
+
+   This attack creates an asymmetry in the beliefs about the identity of
+   peers.  However, this attack is only possible if the victim (Norma)
+   is willing to conduct two sessions nearly simultaneously; if the
+   attacker (Mallory) is on the network path between the victims; and if
+   the same certificate -- and therefore the SDP "fingerprint" attribute
+   value -- is used by Norma for both sessions.
+
+   Where Interactive Connectivity Establishment (ICE) [ICE] is used,
+   Mallory also needs to ensure that connectivity checks between Patsy
+   and Norma succeed, either by forwarding checks or by answering and
+   generating the necessary messages.
+
+4.2.  Unique Session Identity Solution
+
+   The solution to this problem is to assign a new identifier to
+   communicating peers.  Each endpoint assigns their peer a unique
+   identifier during call signaling.  The peer echoes that identifier in
+   the TLS handshake, binding that identity into the session.  Including
+   this new identity in the TLS handshake means that it will be covered
+   by the TLS Finished message, which is necessary to authenticate it
+   (see [SIGMA]).
+
+   Successfully validating that the identifier matches the expected
+   value means that the connection corresponds to the signaled session
+   and is therefore established between the correct two endpoints.
+
+   This solution relies on the unique identifier given to DTLS sessions
+   using the SDP "tls-id" attribute [DTLS-SDP].  This field is already
+   required to be unique.  Thus, 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 established as part of the same
+   call or real-time session.  This carries the value of the "tls-id"
+   attribute and provides integrity protection for its exchange 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 selects.  When used with SDP, the value MUST include
+   the "tls-id" attribute from the SDP that the endpoint generated when
+   negotiating the session.  This document only defines use of this
+   extension for SDP; other methods of external session negotiation can
+   use this extension to include a unique session identifier.
+
+   The "extension_data" for the "external_session_id" extension contains
+   an ExternalSessionId struct, 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].
+
+   Where RTP and RTCP [RTP] are not multiplexed, it is possible that the
+   two separate DTLS connections carrying RTP and RTCP can be 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] further avoids this problem.
+
+   The "external_session_id" extension is included in a ClientHello, and
+   if the extension is present in the ClientHello, either ServerHello
+   (for TLS and DTLS versions older than 1.3) or EncryptedExtensions
+   (for TLS 1.3).
+
+   Endpoints MUST check that the "session_id" parameter in the extension
+   that they receive includes the "tls-id" attribute value that they
+   received in their peer's session description.  Endpoints can perform
+   string 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 receives an "external_session_id" extension that is not
+   identical to the value that it expects MUST abort the connection with
+   a fatal "illegal_parameter" alert.
+
+   The endpoint performs the validation of the "external_id_hash"
+   extension in addition to the validation required by [FINGERPRINT].
+
+   If an endpoint communicates with a peer that does not support this
+   extension, it will receive a ClientHello, ServerHello, or
+   EncryptedExtensions message that does not include this extension.  An
+   endpoint MAY choose to continue a session without this extension in
+   order to interoperate with peers that do not 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 is not effective if an attacker can rewrite "tls-id"
+   values in signaling.  Only the mechanism in "external_id_hash" is
+   able to defend against an attacker that can compromise session
+   integrity.
+
+5.  Session Concatenation
+
+   Use of session identifiers does not prevent an attacker from
+   establishing two concurrent sessions with different peers and
+   forwarding signaling from those peers to each other.  Concatenating
+   two signaling sessions in this way creates two signaling sessions,
+   with two session identifiers, but only the TLS connections from a
+   single session are established as a result.  In doing so, the
+   attacker creates a situation where both peers believe that they are
+   talking to the attacker when they are talking to each other.
+
+   In the absence of any higher-level concept of peer identity, an
+   attacker who is able to copy the session identifier from one
+   signaling session to another can cause the peers to establish a
+   direct TLS connection even while they think that they are connecting
+   to the attacker.  This differs from the attack described in the
+   previous section in that there is only one TLS connection rather than
+   two.  This kind of attack is prevented by systems that enable peer
+   authentication, such as WebRTC identity [WEBRTC-SEC] or SIP identity
+   [SIP-ID]; however, these systems do not prevent establishing two
+   back-to-back connections as described in the previous paragraph.
+
+   Use of the "external_session_id" does not guarantee that the identity
+   of the peer at the TLS layer is the same as the identity of the
+   signaling peer.  The advantage that an attacker gains by
+   concatenating sessions is limited unless data is exchanged based on
+   the assumption that signaling and TLS peers are the same.  If a
+   secondary protocol uses the signaling channel with the assumption
+   that the signaling and TLS peers are the same, then that protocol is
+   vulnerable to attack.  While out of scope for this document, a
+   signaling system that can defend against session concatenation
+   requires that the signaling layer is authenticated and bound to any
+   TLS connections.
+
+   It is important to note that multiple connections can be created
+   within the same signaling session.  An attacker might concatenate
+   only part of a session, choosing to terminate some connections (and
+   optionally forward data) while arranging to have peers interact
+   directly for other connections.  It is even possible to have
+   different peers interact for each connection.  This means that the
+   actual identity of the peer for one connection might differ from the
+   peer on another connection.
+
+   Critically, information about the identity of TLS peers provides no
+   assurances about the identity of signaling peers and does not
+   transfer between TLS connections in the same session.  Information
+   extracted from a TLS connection therefore MUST NOT be used in a
+   secondary protocol outside of that connection if that protocol
+   assumes that 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 are established as a
+   result of the same signaling session.
+
+6.  Security Considerations
+
+   When combined with identity assertions, the mitigations in this
+   document ensure that there is no opportunity to misrepresent the
+   identity of TLS peers.  This assurance is provided even if an
+   attacker can modify signaling messages.
+
+   Without identity assertions, the mitigations in this document 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.
+
+7.  IANA Considerations
+
+   This document registers two extensions in the "TLS ExtensionType
+   Values" registry established 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 not have been discovered if it weren't for
+   discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes.  A
+   solution similar to the one presented here was first proposed by
+   Karthik Bhargavan, who provided valuable input on this document.
+   Thyla van der Merwe assisted 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