<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std" updates="8122">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
  <!-- xml2rfc v2v3 conversion 2.29.0 -->
    <title abbrev="SDP UKS">Unknown Key Share Key-Share Attacks on uses Uses of TLS with the Session Description Protocol (SDP)</title>
    <seriesInfo name="RFC" value="8844"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
    <date year="2019" month="August" day="09"/> month="May" year="2020"/>
    <keyword>Unknown Key-Share Attack</keyword>
    <keyword>SIP identity</keyword>


      <t>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
mislead misled about the identity of a
      communicating peer.  Mitigation  This document defines mitigation techniques are
defined that
      implementations of RFC 8122 are encouraged to deploy.</t>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <t>The use of Transport Layer Security (TLS) <xref target="TLS13"/> target="RFC8446"
      format="default"/> with the Session Description Protocol (SDP) <xref target="SDP"/>
      target="RFC4566" format="default"/> is defined in <xref target="FINGERPRINT"/>. target="RFC8122"
      format="default"/>.  Further use with Datagram Transport Layer Security
      (DTLS) <xref target="DTLS"/> target="RFC6347" format="default"/> and the Secure
      Real-time Transport Protocol (SRTP) <xref target="SRTP"/> target="RFC3711"
      format="default"/> is defined as DTLS-SRTP <xref target="DTLS-SRTP"/>.</t> target="RFC5763"
      <t>In these specifications, key agreement is performed using TLS or DTLS, with
authentication being tied back linked 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.</t>

      <t>WebRTC identity (see Section 7 of <xref target="WEBRTC-SEC"/>) target="RFC8827" sectionFormat="of" section="7" format="default"/>)
and SIP identity <xref target="SIP-ID"/> target="RFC8224" format="default"/> both provide a mechanism that binds an
external identity to the certificate fingerprints from a session description.
However, this binding is not integrity-protected integrity protected and is therefore vulnerable to an
identity misbinding attack - or attack, also known as an unknown key-share (UKS) attack - 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.</t>
      <t>This document describes a TLS extension that can be used in combination with
these identity bindings to prevent this attack.</t>

      <t>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 conditions necessary preconditions
(see <xref target="limits"/>), target="limits" format="default"/>), this document also
describes mitigations for this attack.</t>
      <t>The mechanisms defined in this document are intended to strengthen the protocol
by preventing the use of unknown key shares key-share attacks in combination with other protocol
or implementation vulnerabilities.  RFC 8122 <xref target="FINGERPRINT"/> target="RFC8122" format="default"/> is updated by this
document to recommend the use of these mechanisms.</t>
      <t>This document assumes that signaling is integrity protected.  However, as
Section 7 of
<xref target="FINGERPRINT"/> target="RFC8122" sectionFormat="of" section="7" format="default"/> explains, many deployments that use SDP do not
guarantee integrity of session signaling and so are vulnerable to other attacks.
<xref target="FINGERPRINT"/> target="RFC8122" format="default"/> offers key continuity mechanisms as a potential means of
reducing exposure to attack in the absence of integrity protection.
<xref target="continuity"/> target="continuity" format="default"/> provides some analysis of the effect of key continuity in
relation to the described attacks.</t>

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
    <section anchor="uks" title="Unknown numbered="true" toc="default">
      <name>Unknown Key-Share Attack"> Attack</name>
      <t>In an unknown key-share attack <xref target="UKS"/>, target="UKS" format="default"/>, 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.</t>
      <t>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 it the first victim believes
   that it is communicating with the attacker.</t> attacker.
      <t>When the identity of communicating peers is established by higher-layer
signaling constructs, such as those in SIP identity <xref target="SIP-ID"/> target="RFC8224" format="default"/> or WebRTC
<xref target="WEBRTC-SEC"/>, target="RFC8827" format="default"/>, this allows an attacker to bind their own identity to a session
with any other entity.</t>
      <t>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.</t>
      <t>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.</t>
      <t>A similar attack can be mounted based solely on the SDP <spanx style="verb">fingerprint</spanx> <tt>fingerprint</tt> attribute
<xref target="FINGERPRINT"/> target="RFC8122" format="default"/> without compromising the integrity of the signaling channel.</t>
      <t>This attack is an aspect of SDP-based protocols that upon which the technique known as
third-party call control (3PCC) <xref target="RFC3725"/> relies on. target="RFC3725" format="default"/> 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.
<xref target="byebye-3pcc"/> target="byebye-3pcc" format="default"/> describes the consequences of the mitigations described here for
systems that use 3PCC.</t>
      <section anchor="limits" title="Limits numbered="true" toc="default">
        <name>Limits on Attack Feasibility"> Feasibility</name>
        <t>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

<t><list style="numbers">
        <ol spacing="normal" type="1">
          <li>An attacker can only modify the parts of the session signaling that they are
responsible for producing, namely their own offers and answers.</t>
  <t>No answers.</li>
          <li>No entity will successfully establish a session with a peer unless they are
willing to participate in a session with that peer.</t>
</list></t> peer.</li>
        <t>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. <xref target="fp"/> target="fp" format="default"/>
describes an attack on SDP signaling under these constraints.</t>
        <t>Systems that rely on strong identity bindings, such as those defined in
<xref target="WEBRTC"/> target="WEBRTC" format="default"/> or <xref target="SIP-ID"/>, target="RFC8224" format="default"/>, 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 to both observe and to modify signaling messages.  <xref target="id"/> target="id" format="default"/> describes an attack
that assumes this threat model.</t>
      <section anchor="continuity" title="Interactions numbered="true" toc="default">
        <name>Interactions with Key Continuity"> Continuity</name>
        <t>Systems that use key continuity (as defined in Section 15.1 of
<xref target="ZRTP"/> target="RFC6189" sectionFormat="of" section="15.1" format="default"/>
or as recommended in Section 7 of <xref target="FINGERPRINT"/>) target="RFC8122" sectionFormat="of" section="7" format="default"/>) 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.</t>
        <t>Implementations that maintain a single database of identities with an index on 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
        <t>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 "Mallory appears to have a new device”). device").  However,
such an event is not always considered alarming; some implementations might
silently save a new key.</t>
      <section anchor="byebye-3pcc" title="Third-Party numbered="true" toc="default">
        <name>Third-Party Call Control"> Control</name>

        <t>Third-party call control (3PCC) <xref target="RFC3725"/> target="RFC3725" format="default"/> 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.</t>
        <t>3PCC as described in RFC 3725 is incompatible with SIP identity <xref target="SIP-ID"/> target="RFC8224" format="default"/>, 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 <spanx style="verb">fingerprint</spanx> <tt>fingerprint</tt> attribute
without additional bindings or WebRTC identity <xref target="WEBRTC-SEC"/> target="RFC8827" format="default"/> is possible.</t>
        <t>The attack mitigation mechanisms described in this document will prevent the use
of 3PCC if peers have different views of the involved identities, identities or the value
of SDP <spanx style="verb">tls-id</spanx> <tt>tls-id</tt> attributes.</t>
        <t>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 to either to
forward SDP without modification, modification or to avoid modifications to <spanx style="verb">fingerprint</spanx>,
<spanx style="verb">tls-id</spanx>, <tt>fingerprint</tt>,
<tt>tls-id</tt>, and <spanx style="verb">identity</spanx> <tt>identity</tt> 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.</t>
    <section anchor="id" title="Unknown numbered="true" toc="default">
      <name>Unknown Key-Share Attack with Identity Bindings"> Bindings</name>
      <t>The identity assertions used for WebRTC (Section 7 of <xref target="WEBRTC-SEC"/>)
(<xref target="RFC8827" sectionFormat="of" section="7" format="default"/>) and the
Personal Assertion Token (PASSporT) used in SIP identity (<xref target="SIP-ID"/>, target="RFC8224" format="default"/>, <xref target="PASSPoRT"/>) target="RFC8225" format="default"/>) 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.</t>
      <t>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.</t>
      <t>A variation on the same technique can be used to cause both victims to both
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

      <t>The problem might appear to be caused by the fact that the authority that
certifies certifying the identity binding is not required to verify that the entity
requesting the binding actually controls the keys associated with the fingerprints. fingerprints,
and this might appear to be the cause of the problem.
SIP and WebRTC identity providers are not required to perform this
validation.  However, validation of keys by the identity provider is not
relevant because verifying control of the associated keys is not a necessary
condition for a secure protocol, nor would it be sufficient to prevent attack
<xref target="SIGMA"/>.</t> target="SIGMA" format="default"/>.</t>
      <t>A simple solution to this problem is suggested by <xref target="SIGMA"/>. target="SIGMA" format="default"/>.  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.</t>
      <t>Rather than include a complete identity binding - binding, which could be
sizeable -
sizable, a collision- and pre-image-resistant preimage-resistant hash of the binding is included
in a TLS extension as described in <xref target="external_id_hash"/>. target="external_id_hash" format="default"/>.  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.</t>
      <t>This form of unknown key-share attack is possible without compromising signaling
integrity, unless the defenses described in <xref target="fp"/> target="fp" format="default"/> are used.  In order to
prevent both forms of attack, endpoints MUST <bcp14>MUST</bcp14> use the <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt>
extension (see <xref target="external_session_id"/>) target="external_session_id" format="default"/>) in addition to the <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt>
(<xref target="external_id_hash"/>) target="external_id_hash" format="default"/>) so that two calls between the same parties can’t can't be
altered by an attacker.</t>
      <section anchor="id-example" title="Example"> numbered="true" toc="default">
        <t>In the example shown in <xref target="identity-attack"/>, target="identity-attack" format="default"/>, it is assumed that the attacker
also controls the signaling channel.</t>
        <t>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.</t>
        <figure title="Example anchor="identity-attack">
          <name>Example Attack on Identity Bindings" anchor="identity-attack"><artwork><![CDATA[ Bindings</name>
          <artwork align="left" alt=""><![CDATA[
  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)
        <t>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 ('Signaling1' in the
<xref target="identity-attack" format="default"/>).</t>
        <t>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 ('Signaling2' in the figure) <xref target="identity-attack" format="default"/>) can be entirely legitimate.</t>
       <t>A DTLS session is established directly between Norma and Patsy.
   In order for this to happen happen, Mallory can substitute transport-level
   information in both
sessions to facilitate this, sessions, though this is not necessary if Mallory
   is on the network path between Norma and Patsy.</t> Patsy.
        <t>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
<xref target="uks"/>, target="uks" format="default"/>, Mallory cannot access media, but Norma might send information to Patsy
that is Norma might not intend or that Patsy might misinterpret.</t>
      <section anchor="external_id_hash" title="The external_id_hash numbered="true" toc="default">
        <name>The <tt>external_id_hash</tt> TLS Extension"> Extension</name>
        <t>The <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> 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.</t>
        <t>The <spanx style="verb">extension_data</spanx> <tt>extension_data</tt> for the <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension contains a
<spanx style="verb">ExternalIdentityHash</spanx>
<tt>ExternalIdentityHash</tt> struct, described below using the syntax defined in
Section 3 of
<xref target="TLS13"/>:</t>

<figure><artwork><![CDATA[ target="RFC8446" sectionFormat="of" section="3" format="default"/>:</t>

        <sourcecode type="tls-presentation"><![CDATA[
   struct {
      opaque binding_hash<0..32>;
   } ExternalIdentityHash;
        <t>Where an identity assertion has been asserted by a peer, this extension includes
a SHA-256 SHA-&wj;256 hash of the assertion.  An empty value is used to indicate support for
the extension.</t>

<t><list style="hanging">
  <t hangText='Note:'>
        <dl newline="false" spacing="normal">
  For both types of identity assertion, if SHA-256 SHA-&wj;256 should prove to be inadequate
at some point
in the future (see <xref target="AGILITY"/>), target="RFC7696" format="default"/>), a new TLS extension
can be defined
that uses a different hash function.</t>
</list></t> function can be defined.</dd>

        <t>Identity bindings might be provided by only one peer.  An endpoint that does not
produce an identity binding MUST <bcp14>MUST</bcp14> generate an empty <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension
in its ClientHello or - -- if a client provides the extension - -- in ServerHello or
EncryptedExtensions.  An empty extension has a zero-length binding_hash <tt>binding_hash</tt> field.</t>
        <t>A peer that receives an <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension that does not match the
value of the identity binding from its peer MUST <bcp14>MUST</bcp14> immediately fail the TLS
handshake with a illegal_parameter an <tt>illegal_parameter</tt> alert.  The absence of an identity binding
does not relax this requirement; if a peer provided no identity binding, a
zero-length extension MUST <bcp14>MUST</bcp14> be present to be considered valid.</t>
        <t>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 <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension MAY <bcp14>MAY</bcp14> accept
a TLS connection rather than fail a connection where the extension is absent.</t>


<!-- [rfced] Please clarify what is doing the validation in the sentence
below.  Two of the tasks sound like they would be performed by a receiver
of the information (validating the external_hash_id, [FINGERPRINT]
validation), while "identity assertion definition" sounds like something
the sender would do. Should "definition" be "verification"?

   Any validation performed of the <spanx style="verb">external_id_hash</spanx> "external_id_hash" extension is done
   in addition to the validation required by [FINGERPRINT] and any
   identity assertion definition.

   The endpoint performs the validation of the external_id_hash extension
   in addition to the validation required by [RFC8122] and any verification
   of the identity assertion.
   The endpoint performs the validation of the <tt>external_id_hash</tt> extension
   in addition to the validation required by <xref target="FINGERPRINT"/> target="RFC8122" format="default"/> and any verification
   of the identity assertion
definition.</t> <xref target="RFC8827" format="default"/> <xref target="RFC8224" format="default"/>.

        <t>An <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension with a <tt>binding_hash</tt> field
that is any length other than 0 or 32 is invalid
and MUST <bcp14>MUST</bcp14> cause the receiving endpoint to generate a fatal <spanx style="verb">decode_error</spanx> <tt>decode_error</tt> alert.</t>
        <t>In TLS 1.3, an <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension sent by a server MUST <bcp14>MUST</bcp14> be sent in the
EncryptedExtensions message.</t>
        <section anchor="calculating-externalidhash-for-webrtc-identity" title="Calculating external_id_hash numbered="true" toc="default">
          <name>Calculating <tt>external_id_hash</tt> for WebRTC Identity"> Identity</name>
          <t>A WebRTC identity assertion (Section 7 of <xref target="WEBRTC-SEC"/>)
(<xref target="RFC8827" sectionFormat="of" section="7" format="default"/>) is provided as a JSON
<xref target="JSON"/> target="RFC8259" format="default"/> object that is encoded into a JSON text.  The JSON text is
encoded using UTF-8 <xref target="UTF8"/> target="RFC3629" format="default"/> as described by Section 8.1 of
<xref target="JSON"/>. target="RFC8259" sectionFormat="of" section="8.1" format="default"/>.
The content of the <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension is produced by hashing the
resulting octets with SHA-256 SHA-&wj;256 <xref target="SHA"/>. target="RFC6234" format="default"/>.  This produces the 32 octets of
the <spanx style="verb">binding_hash</spanx> <tt>binding_hash</tt> parameter, which is the sole contents of the extension.</t>
          <t>The SDP <spanx style="verb">identity</spanx> <tt>identity</tt> attribute includes the base64 <xref target="BASE64"/> target="RFC4648" format="default"/> encoding of
the UTF-8 encoding of the same JSON text.  The <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> extension is
validated by performing base64 decoding on the value of the SDP <spanx style="verb">identity</spanx> <tt>identity</tt>
attribute, hashing the resulting octets using SHA-256, SHA-&wj;256, and comparing the results
with the content of the extension.  In pseudocode form, using the
<spanx style="verb">identity-assertion-value</spanx>
<tt>identity-assertion-value</tt> field from the <spanx style="verb">identity</spanx> SDP <tt>identity</tt> attribute grammar as
defined in <xref target="WEBRTC-SEC"/>:</t>

<t><spanx style="verb"> target="RFC8827" format="default"/>:</t>
        <sourcecode type="pseudocode"><![CDATA[
external_id_hash = SHA-256(b64decode(identity-assertion-value))

<t><list style="hanging">
  <t hangText='Note:'>
          <dl newline="false" spacing="normal">
  The base64 of the SDP <spanx style="verb">identity</spanx> <tt>identity</tt> 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.</t>
</list></t> hashed.</dd>
        <section anchor="calculating-externalidhash-for-passport" title="Calculating numbered="true" toc="default">
          <name>Calculating external_id_hash for PASSPoRT"> PASSporT</name>
          <t>Where the compact form of PASSPoRT PASSporT <xref target="PASSPoRT"/> target="RFC8225" format="default"/>
is used, it MUST <bcp14>MUST</bcp14> be expanded
into the full form.  The base64 encoding used in the SIP Identity (or ‘y’) 'y')
header field MUST <bcp14>MUST</bcp14> be decoded then used as input to SHA-256. SHA-&wj;256.  This produces the
32 octet <spanx style="verb">binding_hash</spanx>
32-octet <tt>binding_hash</tt> value used for creating or validating the extension.  In
pseudocode, using the <spanx style="verb">signed-identity-digest</spanx> field <tt>signed-identity-digest</tt> parameter from the <spanx style="verb">Identity</spanx> <tt>Identity</tt> header field grammar
defined <xref target="SIP-ID"/>:</t>

<t><spanx style="verb"> target="RFC8224" format="default"/>:</t>
        <sourcecode type="pseudocode"><![CDATA[
external_id_hash = SHA-256(b64decode(signed-identity-digest))
    <section anchor="fp" title="Unknown numbered="true" toc="default">
      <name>Unknown Key-Share Attack with Fingerprints"> Fingerprints</name>
      <t>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.</t>
      <t>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
      <t>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.</t>
      <t>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
      <section anchor="fp-example" title="Example"> numbered="true" toc="default">
        <t>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.</t>
        <t>In addition to the constraints described in <xref target="limits"/>, target="limits" format="default"/>, the attacker in this
example also needs the ability to view and drop packets between victims.
That is, the attacker is on-path needs to be on path for media.</t>
        <t>The attack shown in <xref target="implausible-attack"/> target="implausible-attack" format="default"/> 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.</t>
        <figure title="Example anchor="implausible-attack">
          <name>Example Attack Scenario using Fingerprints" anchor="implausible-attack"><artwork><![CDATA[ Using Fingerprints</name>
          <artwork align="left" alt=""><![CDATA[
  Norma                   Mallory                 Patsy
  (fp=N)                   -----                  (fp=P)
    |                        |                      |
    +---Signaling1 (fp=N)--->|                      |
    +-----Signaling2 (fp=N)------------------------>|
    |<-------------------------Signaling2 (fp=P)----+
    |<---Signaling1 (fp=P)---+                      |
    |                        |                      |
    |                       |                       |
    |=======DTLS2========>(Drop)                    |
    |                       |                       |
        <t>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
        <t>The first session is established with Mallory, who falsely uses Patsy’s Patsy's
certificate fingerprint (denoted with ‘fp=P’). 'fp=P').  A second session is initiated
between Norma and Patsy.  Signaling for both sessions is permitted to complete.</t>
        <t>Once signaling is complete on the first session, a DTLS connection is
established. Ostensibly, this connection is between Mallory and Norma Norma, but
Mallory forwards DTLS and media packets sent to her by Norma to Patsy.  These
packets are denoted ‘DTLS1’ 'DTLS1' because Norma associates these with the first
signaling session (‘signaling1’).</t> ('Signaling1').</t>
        <t>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 ('Signaling2'); however, Norma will interpret these as being associated
with the first signaling session (‘signaling1’).</t> ('Signaling1').</t>
        <t>The second signaling exchange - ‘signaling2’, ('Signaling2'), which is between Norma and Patsy - 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 <xref target="id-example"/>, target="id-example" format="default"/>, Mallory
cannot access media, but Norma might send information to Patsy that is Norma
might not intend or that Patsy might misinterpret.</t>
        <t>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.</t>
        <t>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 is has failed and thereby abort the call.</t>

        <t>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, simultaneously; if the attacker (Mallory) is on the
network path between the victims, victims; and if the same certificate - -- and therefore
the SDP <spanx style="verb">fingerprint</spanx> <tt>fingerprint</tt> attribute value - -- is used by Norma for both sessions.</t>
        <t>Where ICE Interactive Connectivity Establishment (ICE) <xref target="ICE"/> target="RFC8445" format="default"/>
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.</t>
      <section anchor="sess-id" title="Unique numbered="true" toc="default">
        <name>Unique Session Identity Solution"> Solution</name>
        <t>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 <xref target="SIGMA"/>).</t>

<t>Successful validation target="SIGMA" format="default"/>).</t>
        <t>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.</t>
        <t>This solution relies on the unique identifier given to DTLS sessions using the
SDP <spanx style="verb">tls-id</spanx> <tt>tls-id</tt> attribute <xref target="DTLS-SDP"/>. target="RFC8842" format="default"/>.  This field is
already required to be unique.  Thus, no two offers or answers from the same
client will have the same value.</t>
        <t>A new <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> 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 <spanx style="verb">tls-id</spanx> <tt>tls-id</tt> attribute and provides integrity
protection for its exchange as part of the TLS or DTLS handshake.</t>
      <section anchor="external_session_id" title="The numbered="true" toc="default">
        <name>The external_session_id TLS Extension"> Extension</name>
        <t>The <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> TLS extension carries the unique identifier that an
endpoint selects.  When used with SDP, the value MUST <bcp14>MUST</bcp14> include the <spanx style="verb">tls-id</spanx> <tt>tls-id</tt>
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
        <t>The <spanx style="verb">extension_data</spanx> <tt>extension_data</tt> for the <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> extension contains an
ExternalSessionId struct, described below using the syntax defined in
<xref target="TLS13"/>:</t>

<figure><artwork><![CDATA[ target="RFC8446" format="default"/>:</t>
        <sourcecode type="tls-presentation"><![CDATA[
   struct {
      opaque session_id<20..255>;
   } ExternalSessionId;
        <t>For SDP, the <spanx style="verb">session_id</spanx> <tt>session_id</tt> field of the extension includes the value of the
<spanx style="verb">tls-id</spanx>
<tt>tls-id</tt> SDP attribute as defined in <xref target="DTLS-SDP"/> target="RFC8842" format="default"/>
(that is, the <spanx style="verb">tls-id-value</spanx> <tt>tls-id-value</tt> ABNF production).  The value of the <spanx style="verb">tls-id</spanx> <tt>tls-id</tt>
attribute is encoded using ASCII <xref target="ASCII"/>.</t> target="RFC0020" format="default"/>.</t>
        <t>Where RTP and RTCP <xref target="RTP"/> target="RFC3550" format="default"/> 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 <xref target="SRTP"/> target="RFC3711" format="default"/> provides key separation.  Using RTP/RTCP multiplexing
<xref target="RTCP-MUX"/> target="RFC5761" format="default"/> further avoids this problem.</t>
        <t>The <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> extension is included in a ClientHello ClientHello, and - if the
extension is present in the ClientHello - ClientHello, either ServerHello (for TLS and DTLS
versions less older than 1.3) or EncryptedExtensions (for TLS 1.3).</t>
        <t>Endpoints MUST <bcp14>MUST</bcp14> check that the <spanx style="verb">session_id</spanx> <tt>session_id</tt> parameter in the extension that they
receive includes the <spanx style="verb">tls-id</spanx> <tt>tls-id</tt> attribute value that they received in their peer’s peer's
session description.  Endpoints can perform string comparison by ASCII decoding
the TLS extension value and comparing it to the SDP attribute value, value or compare by comparing
the encoded TLS extension octets with the encoded SDP attribute value.  An
endpoint that receives a <spanx style="verb">external_session_id</spanx> an <tt>external_session_id</tt> extension that is not identical
to the value that it expects MUST <bcp14>MUST</bcp14> abort the connection with a fatal
<spanx style="verb">illegal_parameter</spanx>
<tt>illegal_parameter</tt> alert.</t>

   The endpoint performs the validation performed of the <spanx style="verb">external_session_id</spanx> <tt>external_id_hash</tt> extension is done in
   addition to the validation required by <xref target="FINGERPRINT"/>.</t>

<t>An target="RFC8122" format="default"/>.
        <t>If an endpoint that is communicating communicates with a peer that does not support this
extension, it will receive a ClientHello, ServerHello ServerHello, or EncryptedExtensions message that
does not include this extension.  An endpoint MAY <bcp14>MAY</bcp14> choose to continue a session
without this extension in order to interoperate with peers that do not implement
this specification.</t>
        <t>In TLS 1.3, an <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> extension sent by a server MUST <bcp14>MUST</bcp14> be sent in
the EncryptedExtensions message.</t>
        <t>This defense is not effective if an attacker can rewrite <spanx style="verb">tls-id</spanx> <tt>tls-id</tt> values in
signaling.  Only the mechanism in <spanx style="verb">external_id_hash</spanx> <tt>external_id_hash</tt> is able to defend against
an attacker that can compromise session integrity.</t>
    <section anchor="concat" title="Session Concatenation"> numbered="true" toc="default">
      <name>Session Concatenation</name>
      <t>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.</t>
      <t>In the absence of any higher-level concept of peer identity, the use of session
identifiers does not prevent session concatenation if the attacker is able to
copy the session identifier from one signaling session to another.  This kind of
attack is prevented by systems that enable peer authentication authentication, such as WebRTC
identity <xref target="WEBRTC-SEC"/> target="RFC8827" format="default"/>
or SIP identity <xref target="SIP-ID"/>. target="RFC8224" format="default"/>.  However, session
concatenation remains possible at higher layers: an attacker can establish two
independent sessions and simply forward any data it receives from one into the
      <t>Use of the <spanx style="verb">external_session_id</spanx> <tt>external_session_id</tt> 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 same, then that protocol is vulnerable to attack.
While out of scope for this document, a signaling system that can defend against session concatenation, while out of
scope for this document, concatenation
requires that the signaling layer is authenticated and bound to any TLS connections.</t>
      <t>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.</t>
      <t>Critically, information about the identity of TLS peers provides no assurances
about the identity of signaling peers and do does not transfer between TLS
connections in the same session.  Information extracted from a TLS connection
therefore MUST NOT <bcp14>MUST NOT</bcp14> 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 <bcp14>MUST NOT</bcp14> be
used in other TLS connections even if they are established as a result of the
same signaling session.</t>
    <section anchor="security-considerations" title="Security Considerations">

<t>The mitigations in this document, when numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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.</t>

      <t>Without identity assertions, the mitigations in this document prevent the
session splicing attack described in <xref target="fp"/>. target="fp" format="default"/>.  Defense against session
concatenation (<xref target="concat"/>) target="concat" format="default"/>) additionally requires that protocol peers are not able to
claim the certificate fingerprints of other entities.</t>

    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document registers two extensions in the TLS “ExtensionType Values” "TLS ExtensionType Values"
registry established in <xref target="TLS13"/>:</t>

<t><list style="symbols">
  <t>The <spanx style="verb">external_id_hash</spanx> target="RFC8446" format="default"/>:</t>
      <ul spacing="normal">
        <li>The <tt>external_id_hash</tt> extension defined in <xref target="external_id_hash"/> target="external_id_hash" format="default"/> has been
assigned a code point of TBD; 55; it is recommended and is marked as “CH, EE” "CH, EE"
in TLS 1.3.</t>
  <t>The <spanx style="verb">external_session_id</spanx> 1.3.</li>
        <li>The <tt>external_session_id</tt> extension defined in <xref target="external_session_id"/> target="external_session_id" format="default"/> has
been assigned a code point of TBD; 56; it is recommended and is marked as
“CH, EE”
"CH, EE" in TLS 1.3.</t>
</list></t> 1.3.</li>

    <references title='Normative References'>
    <displayreference target="RFC0020" to="ASCII"/>
    <displayreference target="RFC3550" to="RTP"/>
    <displayreference target="RFC3629" to="UTF8"/>
    <displayreference target="RFC3711" to="SRTP"/>
    <displayreference target="RFC4566" to="SDP"/>
    <displayreference target="RFC4648" to="BASE64"/>
    <displayreference target="RFC5761" to="RTCP-MUX"/>
    <displayreference target="RFC5763" to="DTLS-SRTP"/>
    <displayreference target="RFC6189" to="ZRTP"/>
    <displayreference target="RFC6234" to="SHA"/>
    <displayreference target="RFC6347" to="DTLS"/>
    <displayreference target="RFC7696" to="AGILITY"/>
    <displayreference target="RFC8122" to="FINGERPRINT"/>
    <displayreference target="RFC8224" to="SIP-ID"/>
    <displayreference target="RFC8225" to="PASSPORT"/>
    <displayreference target="RFC8259" to="JSON"/>
    <displayreference target="RFC8445" to="ICE"/>
    <displayreference target="RFC8446" to="TLS13"/>
    <displayreference target="RFC8827" to="WEBRTC-SEC"/>
    <displayreference target="RFC8842" to="DTLS-SDP"/>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8122.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>

<!-- draft-ietf-rtcweb-security-arch in C238; RFC 8827 -->
 <reference  anchor="TLS13" target='https://www.rfc-editor.org/info/rfc8446'> anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<title>The Transport Layer
 <title>WebRTC Security (TLS) Protocol Version 1.3</title> Architecture</title>
 <author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author> fullname='Eric Rescorla'>
 <date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract> month='May' year='2020'/>
 <seriesInfo name='RFC' value='8446'/> name="RFC" value="8827"/>
 <seriesInfo name='DOI' value='10.17487/RFC8446'/> name="DOI" value="10.17487/RFC8827"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<!-- draft-ietf-mmusic-dtls-sdp-32 in C238; RFC 8842 -->
<reference  anchor="SDP" target='https://www.rfc-editor.org/info/rfc4566'> anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8842">

<title>SDP: Session
    <title>Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author> Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security

    <author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author> initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization />

    <author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author> initials="R." surname="Shpount" fullname="Roman Shpount">
      <organization />

    <date year='2006' month='July' month="May" year="2020" />
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
  <seriesInfo name='RFC' value='4566'/> name="RFC" value="8842" />
  <seriesInfo name='DOI' value='10.17487/RFC4566'/> name="DOI" value="10.17487/RFC8842"/>



        <name>Informative References</name>
        <reference  anchor="FINGERPRINT" target='https://www.rfc-editor.org/info/rfc8122'> anchor="UKS">
<title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in
            <title>Unknown Key-Share Attacks on the Session Description Protocol (SDP)</title> Station-to-Station (STS) Protocol</title>
            <author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></author> initials="S." surname="Blake-Wilson">
            <author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization /></author> initials="A." surname="Menezes">
            <date year='2017' month='March' />
<abstract><t>This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP).  It defines the SDP protocol identifier, 'TCP/TLS'.  It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session.  This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</t><t>This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.</t></abstract> year="1999" month="March"/>
	  <seriesInfo name='RFC' value='8122'/>
<seriesInfo name='DOI' value='10.17487/RFC8122'/> name="DOI" value="10.1007/3-540-49162-7_12"/>
          <refcontent>Public Key Cryptography</refcontent>
          <refcontent>Lecture Notes in Computer Science</refcontent>
          <refcontent>Vol. 1560</refcontent>

        <reference  anchor="DTLS" target='https://www.rfc-editor.org/info/rfc6347'> anchor="SIGMA">
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
            <title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols</title>
            <author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>

<reference  anchor="SRTP" target='https://www.rfc-editor.org/info/rfc3711'>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials='M.' surname='Baugher' fullname='M. Baugher'><organization /></author>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='M.' surname='Naslund' fullname='M. Naslund'><organization /></author>
<author initials='E.' surname='Carrara' fullname='E. Carrara'><organization /></author>
<author initials='K.' surname='Norrman' fullname='K. Norrman'><organization /></author>
<date year='2004' month='March' />
<abstract><t>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='3711'/>
<seriesInfo name='DOI' value='10.17487/RFC3711'/>

<reference  anchor="DTLS-SRTP" target='https://www.rfc-editor.org/info/rfc5763'>
<title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
<author initials='J.' surname='Fischl' fullname='J. Fischl'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='5763'/>
<seriesInfo name='DOI' value='10.17487/RFC5763'/>

<reference anchor="WEBRTC-SEC">
<title>WebRTC Security Architecture</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />

<date month='July' day='22' year='2019' />

<abstract><t>This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web".</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-20' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-20.txt' />

<reference  anchor="SIP-ID" target='https://www.rfc-editor.org/info/rfc8224'>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></author>
<date year='2018' month='February' />
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>

<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>

<reference  anchor="PASSPoRT" target='https://www.rfc-editor.org/info/rfc8225'>
<title>PASSporT: Personal Assertion Token</title>
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<date year='2018' month='February' />
<abstract><t>This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications.  The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination.  The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel.  PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</t></abstract>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>

<reference  anchor="JSON" target='https://www.rfc-editor.org/info/rfc8259'>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2017' month='December' />
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>

<reference  anchor="UTF8" target='https://www.rfc-editor.org/info/rfc3629'>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
<date year='2003' month='November' />
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>

<reference  anchor="SHA" target='https://www.rfc-editor.org/info/rfc6234'>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2011' month='May' />
<abstract><t>Federal Information Processing Standard, FIPS</t></abstract>
<seriesInfo name='RFC' value='6234'/>
<seriesInfo name='DOI' value='10.17487/RFC6234'/>

<reference  anchor="BASE64" target='https://www.rfc-editor.org/info/rfc4648'>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>

<reference anchor="DTLS-SDP">
<title>Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>

<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />

<author initials='R' surname='Shpount' fullname='Roman Shpount'>
    <organization />

<date month='October' day='29' year='2017' />

<abstract><t>This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association.  The document also defines the criteria for when a new DTLS association must be established.  The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification.  This document defines a new SDP media-level attribute, 'tls-id'.  This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122.</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-dtls-sdp-32' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-dtls-sdp-32.txt' />

<reference  anchor="ASCII" target='https://www.rfc-editor.org/info/rfc20'>
<title>ASCII format for network interchange</title>
<author initials='V.G.' surname='Cerf' fullname='V.G. Cerf'><organization /></author>
<date year='1969' month='October' />
<seriesInfo name='STD' value='80'/>
<seriesInfo name='RFC' value='20'/>
<seriesInfo name='DOI' value='10.17487/RFC0020'/>


    <references title='Informative References'>

<reference anchor="UKS" >
    <title>Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol</title>
    <author initials="S." surname="Blake-Wilson">
    <author initials="A." surname="Menezes">
    <date year="1999"/>
  <seriesInfo name="Lecture Notes in Computer Science 1560, Springer, pp. 154–170" value=""/>
<reference anchor="SIGMA" >
    <title>SIGMA: The ‘SIGn-and-MAc’approach to authenticated Diffie-Hellman and its use in the IKE protocols</title>
    <author initials="H." surname="Krawczyk">
    <date year="2003"/>
  <seriesInfo name="Annual International Cryptology Conference, Springer, pp. 400-425" value=""/>
<reference anchor="WEBRTC" >
    <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
    <author initials="A." surname="Bergkvist">
    <author initials="D." surname="Burnett">
    <author initials="A." surname="Narayanan">
    <author initials="C." surname="Jennings">
    <author initials="B." surname="Aboba">
    <author initials="T." surname="Brandstetter">
    <author initials="J." surname="Bruaroey">
    <date year="2018" month="November" day="08"/>
  <seriesInfo name="W3C Editor's Draft" value=""/>

<reference  anchor="RFC3725" target='https://www.rfc-editor.org/info/rfc3725'>
<title>Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'><organization /></author>
<date year='2004' month='April' />
<abstract><t>Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties.  Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP).  However, there are several possible approaches, each with different benefits and drawbacks.  This document discusses best current practices for the usage of SIP for third party call control.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
<seriesInfo name='BCP' value='85'/>
<seriesInfo name='RFC' value='3725'/>
<seriesInfo name='DOI' value='10.17487/RFC3725'/>

<reference  anchor="ZRTP" target='https://www.rfc-editor.org/info/rfc6189'>
<title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
<author initials='P.' surname='Zimmermann' fullname='P. Zimmermann'><organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston' role='editor'><organization /></author>
<author initials='J.' surname='Callas' fullname='J. Callas'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications.  The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol.  ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices.  For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication.  ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel.  To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t></abstract>
<seriesInfo name='RFC' value='6189'/>
<seriesInfo name='DOI' value='10.17487/RFC6189'/>

<reference  anchor="AGILITY" target='https://www.rfc-editor.org/info/rfc7696'>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date year='2015' month='November' />
<abstract><t>Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.  Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly.  This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t></abstract>
<seriesInfo name='BCP' value='201'/>
<seriesInfo name='RFC' value='7696'/>
<seriesInfo name='DOI' value='10.17487/RFC7696'/>

<reference  anchor="ICE" target='https://www.rfc-editor.org/info/rfc8445'>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization /></author>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author> initials="H." surname="Krawczyk">
            <date year='2018' month='July' />
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t><t>This document obsoletes RFC 5245.</t></abstract> year="2003" month="August"/>
	  <seriesInfo name='RFC' value='8445'/>
<seriesInfo name='DOI' value='10.17487/RFC8445'/>

<reference  anchor="RTP" target='https://www.rfc-editor.org/info/rfc3550'>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<date year='2003' month='July' />
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets name="DOI" value="10.1007/978-3-540-45146-4_24"/>
          <refcontent>Advances in order to minimize transmission Cryptology -- CRYPTO 2003</refcontent>
          <refcontent>Lecture Notes in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/> Computer Science</refcontent>
	  <refcontent>Vol. 2729</refcontent>

        <reference  anchor="RTCP-MUX" target='https://www.rfc-editor.org/info/rfc5761'> anchor="WEBRTC" target="https://www.w3.org/TR/2019/CR-webrtc-20191213/">
<title>Multiplexing RTP Data and Control Packets on a Single Port</title>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="C." surname="Jennings">
            <author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author> initials="H." surname="Boström">
            <author initials='M.' surname='Westerlund' fullname='M. Westerlund'><organization /></author> initials="J-I." surname="Bruaroey">
            <date year='2010' month='April' />
<abstract><t>This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions.  [STANDARDS-TRACK]</t></abstract> year="2019" month="December" day="13"/>
<seriesInfo name='RFC' value='5761'/>
<seriesInfo name='DOI' value='10.17487/RFC5761'/>
            <refcontent>W3C Candidate Recommendation</refcontent>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3725.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6189.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5761.xml"/>
    <section anchor="acknowledgements" title="Acknowledgements"> numbered="false" toc="default">

      <t>This problem would not have been discovered if it weren’t weren't for
      discussions with
Sam Scott, Hugo Krawczyk, and Richard Barnes. <contact fullname="Sam Scott"/>, <contact
      fullname="Hugo Krawczyk"/>, and <contact fullname="Richard Barnes"/>.  A
      solution similar to the one presented here was first proposed by Karthik Bhargavan
      <contact fullname="Karthik Bhargavan"/>, who provided valuable input on
      this document.  Thyla  <contact fullname="Thyla van der Merwe Merwe"/> assisted with
      a formal model of the solution.  Adam Roach  <contact fullname="Adam Roach"/> and Paul
      <contact fullname="Paul E. Jones Jones"/> provided significant review and

<!-- ##markdown-source: