rfc8844v5.xml   rfc8844.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> nsus="true" docName="draft-ietf-mmusic-sdp-uks-07" indexInclude="true" ipr="trus
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" t200902" number="8844" prepTime="2020-12-28T16:22:59" scripts="Common,Latin" sor
ipr="trust200902" tRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true"
number="8844" updates="8122" xml:lang="en">
docName="draft-ietf-mmusic-sdp-uks-07" <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks-07" rel
category="std" ="prev"/>
updates="8122" <link href="https://dx.doi.org/10.17487/rfc8844" rel="alternate"/>
obsoletes="" <link href="urn:issn:2070-1721" rel="alternate"/>
submissionType="IETF"
consensus="true"
xml:lang="en"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.29.0 -->
<front> <front>
<title abbrev="SDP UKS">Unknown Key-Share Attacks on Uses of TLS with the Se ssion Description Protocol (SDP)</title> <title abbrev="SDP UKS">Unknown Key-Share Attacks on Uses of TLS with the Se ssion Description Protocol (SDP)</title>
<seriesInfo name="RFC" value="8844"/> <seriesInfo name="RFC" value="8844" stream="IETF"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson"> <author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization> <organization showOnFrontPage="true">Mozilla</organization>
<address> <address>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Mozilla</organization> <organization showOnFrontPage="true">Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date month="December" year="2020"/> <date month="01" year="2021"/>
<keyword>Unknown Key-Share Attack</keyword> <keyword>Unknown Key-Share Attack</keyword>
<keyword>SDP</keyword> <keyword>SDP</keyword>
<keyword>DTLS-SRTP</keyword> <keyword>DTLS-SRTP</keyword>
<keyword>WebRTC</keyword> <keyword>WebRTC</keyword>
<keyword>SIP identity</keyword> <keyword>SIP identity</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">This document describes unknown key-
share attacks on the use of
<t>This document describes unknown key-share attacks on the use of
Datagram Transport Layer Security for the Secure Real-Time Transport Datagram Transport Layer Security for the Secure Real-Time Transport
Protocol (DTLS-SRTP). Similar attacks are described on the use of Protocol (DTLS-SRTP). Similar attacks are described on the use of
DTLS-SRTP with the identity bindings used in Web Real-Time DTLS-SRTP with the identity bindings used in Web Real-Time
Communications (WebRTC) and SIP identity. These attacks are difficult Communications (WebRTC) and SIP identity. These attacks are difficult
to mount, but they cause a victim to be misled about the identity of a to mount, but they cause a victim to be misled about the identity of a
communicating peer. This document defines mitigation techniques that communicating peer. This document defines mitigation techniques that
implementations of RFC 8122 are encouraged to deploy.</t> implementations of RFC 8122 are encouraged to deploy.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
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.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8844" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-unknown-key-share-attack">Unknown
Key-Share Attack</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-li
mits-on-attack-feasibilit">Limits on Attack Feasibility</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-in
teractions-with-key-conti">Interactions with Key Continuity</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-third-party-call-contr
ol">Third-Party Call Control</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-unknown-key-share-attack-wi">Unkno
wn Key-Share Attack with Identity Bindings</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-example">Example</xref
></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-external_id_hash-t
ls-ex">The <tt>external_id_hash</tt> TLS Extension</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derived
Content="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-calculatin
g-external_id_has">Calculating <tt>external_id_hash</tt> for WebRTC Identity</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-calculatin
g-external_id_hash">Calculating external_id_hash for PASSporT</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-unknown-key-share-attack-wit">Unkn
own Key-Share Attack with Fingerprints</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-example-2">Example</xr
ef></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unique-session-identit
y-sol">Unique Session Identity Solution</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-external_session_i
d-tls">The external_session_id TLS Extension</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-session-concatenation">Session Con
catenation</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<name>Introduction</name> lse" pn="section-1">
<t>The use of Transport Layer Security (TLS) <xref target="RFC8446" <name slugifiedName="name-introduction">Introduction</name>
format="default"/> with the Session Description Protocol (SDP) <xref <t indent="0" pn="section-1-1">The use of Transport Layer Security (TLS) <
target="RFC4566" format="default"/> is defined in <xref target="RFC8122" xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS13"
format="default"/>. Further use with Datagram Transport Layer Security /> with the Session Description Protocol (SDP) <xref target="RFC4566" format="de
(DTLS) <xref target="RFC6347" format="default"/> and the Secure fault" sectionFormat="of" derivedContent="SDP"/> is defined in <xref target="RFC
Real-time Transport Protocol (SRTP) <xref target="RFC3711" 8122" format="default" sectionFormat="of" derivedContent="FINGERPRINT"/>. Furth
format="default"/> is defined as DTLS-SRTP <xref target="RFC5763" er use with Datagram Transport Layer Security
format="default"/>.</t> (DTLS) <xref target="RFC6347" format="default" sectionFormat="of" derivedC
<t>In these specifications, key agreement is performed using TLS or DTLS, ontent="DTLS"/> and the Secure
with Real-time Transport Protocol (SRTP) <xref target="RFC3711" format="default
" sectionFormat="of" derivedContent="SRTP"/> is defined as DTLS-SRTP <xref targe
t="RFC5763" format="default" sectionFormat="of" derivedContent="DTLS-SRTP"/>.</t
>
<t indent="0" pn="section-1-2">In these specifications, key agreement is p
erformed using TLS or DTLS, with
authentication being tied back to the session description (or SDP) through the authentication being tied back to the session description (or SDP) through the
use of certificate fingerprints. Communication peers check that a hash, or 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 fingerprint, provided in the SDP matches the certificate that is used in the TLS
or DTLS handshake.</t> or DTLS handshake.</t>
<t indent="0" pn="section-1-3">WebRTC identity (see <xref target="RFC8827"
<t>WebRTC identity (see <xref target="RFC8827" sectionFormat="of" section= sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor
"7" format="default"/>) .org/rfc/rfc8827#section-7" derivedContent="WEBRTC-SEC"/>)
and SIP identity <xref target="RFC8224" format="default"/> both provide a mechan and SIP identity <xref target="RFC8224" format="default" sectionFormat="of" deri
ism that binds an vedContent="SIP-ID"/> both provide a mechanism that binds an
external identity to the certificate fingerprints from a session description. external identity to the certificate fingerprints from a session description.
However, this binding is not integrity protected and is therefore vulnerable to an 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, whe re the identity misbinding attack, also known as an unknown key-share (UKS) attack, whe re the
attacker binds their identity to the fingerprint of another entity. A attacker binds their identity to the fingerprint of another entity. A
successful attack leads to the creation of sessions where peers are confused successful attack leads to the creation of sessions where peers are confused
about the identity of the participants.</t> about the identity of the participants.</t>
<t>This document describes a TLS extension that can be used in combination with <t indent="0" pn="section-1-4">This document describes a TLS extension tha t can be used in combination with
these identity bindings to prevent this attack.</t> these identity bindings to prevent this attack.</t>
<t indent="0" pn="section-1-5">A similar attack is possible with the use o
<t>A similar attack is possible with the use of certificate fingerprints a f certificate fingerprints alone.
lone.
Though attacks in this setting are likely infeasible in existing Though attacks in this setting are likely infeasible in existing
deployments due to the narrow preconditions deployments due to the narrow preconditions
(see <xref target="limits" format="default"/>), this document also (see <xref target="limits" format="default" sectionFormat="of" derivedContent="S ection 2.1"/>), this document also
describes mitigations for this attack.</t> describes mitigations for this attack.</t>
<t>The mechanisms defined in this document are intended to strengthen the protocol <t indent="0" pn="section-1-6">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 pro tocol by preventing the use of unknown key-share attacks in combination with other pro tocol
or implementation vulnerabilities. RFC 8122 <xref target="RFC8122" format="defa ult"/> is updated by this or implementation vulnerabilities. RFC 8122 <xref target="RFC8122" format="defa ult" sectionFormat="of" derivedContent="FINGERPRINT"/> is updated by this
document to recommend the use of these mechanisms.</t> document to recommend the use of these mechanisms.</t>
<t>This document assumes that signaling is integrity protected. However, <t indent="0" pn="section-1-7">This document assumes that signaling is int
as egrity protected. However, as
<xref target="RFC8122" sectionFormat="of" section="7" format="default"/> explain <xref target="RFC8122" sectionFormat="of" section="7" format="default" derivedLi
s, many deployments that use SDP do not nk="https://rfc-editor.org/rfc/rfc8122#section-7" derivedContent="FINGERPRINT"/>
explains, many deployments that use SDP do not
guarantee integrity of session signaling and so are vulnerable to other attacks. guarantee integrity of session signaling and so are vulnerable to other attacks.
<xref target="RFC8122" format="default"/> offers key continuity mechanisms as a potential means of <xref target="RFC8122" format="default" sectionFormat="of" derivedContent="FINGE RPRINT"/> offers key continuity mechanisms as a potential means of
reducing exposure to attack in the absence of integrity protection. reducing exposure to attack in the absence of integrity protection.
<xref target="continuity" format="default"/> provides some analysis of the effec t of key continuity in <xref target="continuity" format="default" sectionFormat="of" derivedContent="Se ction 2.2"/> provides some analysis of the effect of key continuity in
relation to the described attacks.</t> relation to the described attacks.</t>
<t> <t indent="0" pn="section-1-8">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="uks" numbered="true" toc="default"> <section anchor="uks" numbered="true" toc="include" removeInRFC="false" pn="
<name>Unknown Key-Share Attack</name> section-2">
<t>In an unknown key-share attack <xref target="UKS" format="default"/>, a <name slugifiedName="name-unknown-key-share-attack">Unknown Key-Share Atta
malicious participant in a protocol ck</name>
<t indent="0" pn="section-2-1">In an unknown key-share attack <xref target
="UKS" format="default" sectionFormat="of" derivedContent="UKS"/>, a malicious p
articipant in a protocol
claims to control a key that is in reality controlled by some other actor. This 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> 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 ent ity can <t indent="0" pn="section-2-2">An endpoint that can acquire the certificat e fingerprint of another entity can
advertise that fingerprint as their own in SDP. advertise that fingerprint as their own in SDP.
An attacker can use a copy of that fingerprint to cause a victim to An attacker can use a copy of that fingerprint to cause a victim to
communicate with another unaware victim, even though the first victim believe s communicate with another unaware victim, even though the first victim believe s
that it is communicating with the attacker. that it is communicating with the attacker.
</t> </t>
<t>When the identity of communicating peers is established by higher-layer <t indent="0" pn="section-2-3">When the identity of communicating peers is
signaling constructs, such as those in SIP identity <xref target="RFC8224" forma established by higher-layer
t="default"/> or WebRTC signaling constructs, such as those in SIP identity <xref target="RFC8224" forma
<xref target="RFC8827" format="default"/>, this allows an attacker to bind their t="default" sectionFormat="of" derivedContent="SIP-ID"/> or WebRTC
own identity to a session <xref target="RFC8827" format="default" sectionFormat="of" derivedContent="WEBRT
C-SEC"/>, this allows an attacker to bind their own identity to a session
with any other entity.</t> with any other entity.</t>
<t>The attacker obtains an identity assertion for an identity it controls, but <t indent="0" pn="section-2-4">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 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 TLS connection to be established where two victim endpoints communicate. The
victim that has its fingerprint copied by the attack correctly believes that it victim that has its fingerprint copied by the attack correctly believes that it
is communicating with the other victim; however, the other victim incorrectly is communicating with the other victim; however, the other victim incorrectly
believes that it is communicating with the attacker.</t> believes that it is communicating with the attacker.</t>
<t>An unknown key-share attack does not result in the attacker having acce ss to any <t indent="0" pn="section-2-5">An unknown key-share attack does not result in the attacker having access to any
confidential information exchanged between victims. However, the failure in confidential information exchanged between victims. However, the failure in
mutual authentication can enable other attacks. A victim might send information mutual authentication can enable other attacks. A victim might send information
to the wrong entity as a result. Where information is interpreted in context, to the wrong entity as a result. Where information is interpreted in context,
misrepresenting that context could lead to the information being misinterpreted. </t> misrepresenting that context could lead to the information being misinterpreted. </t>
<t>A similar attack can be mounted based solely on the SDP <tt>fingerprint <t indent="0" pn="section-2-6">A similar attack can be mounted based solel
</tt> attribute y on the SDP <tt>fingerprint</tt> attribute
<xref target="RFC8122" format="default"/> without compromising the integrity of <xref target="RFC8122" format="default" sectionFormat="of" derivedContent="FINGE
the signaling channel.</t> RPRINT"/> without compromising the integrity of the signaling channel.</t>
<t>This attack is an aspect of SDP-based protocols upon which the techniqu <t indent="0" pn="section-2-7">This attack is an aspect of SDP-based proto
e known as cols upon which the technique known as
third-party call control (3PCC) <xref target="RFC3725" format="default"/> relies third-party call control (3PCC) <xref target="RFC3725" format="default" sectionF
. 3PCC exploits the ormat="of" derivedContent="RFC3725"/> relies. 3PCC exploits the
potential for the identity of a signaling peer to be different than the media 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. peer, allowing the media peer to be selected by the signaling peer.
<xref target="byebye-3pcc" format="default"/> describes the consequences of the mitigations described here for <xref target="byebye-3pcc" format="default" sectionFormat="of" derivedContent="S ection 2.3"/> describes the consequences of the mitigations described here for
systems that use 3PCC.</t> systems that use 3PCC.</t>
<section anchor="limits" numbered="true" toc="default"> <section anchor="limits" numbered="true" toc="include" removeInRFC="false"
<name>Limits on Attack Feasibility</name> pn="section-2.1">
<t>The use of TLS with SDP depends on the integrity of session signaling <name slugifiedName="name-limits-on-attack-feasibilit">Limits on Attack
. Assuming Feasibility</name>
<t indent="0" pn="section-2.1-1">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 signaling integrity limits the capabilities of an attacker in several ways. In
particular:</t> particular:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.
<li>An attacker can only modify the parts of the session signaling tha 1-2">
t they are <li pn="section-2.1-2.1" derivedCounter="1.">An attacker can only modi
fy the parts of the session signaling that they are
responsible for producing, namely their own offers and answers.</li> responsible for producing, namely their own offers and answers.</li>
<li>No entity will successfully establish a session with a peer unless they are <li pn="section-2.1-2.2" derivedCounter="2.">No entity will successful ly establish a session with a peer unless they are
willing to participate in a session with that peer.</li> willing to participate in a session with that peer.</li>
</ol> </ol>
<t>The combination of these two constraints make the spectrum of possibl e attacks <t indent="0" pn="section-2.1-3">The combination of these two constraint s make the spectrum of possible attacks
quite limited. An attacker is only able to switch its own certificate quite limited. An attacker is only able to switch its own certificate
fingerprint for a valid certificate that is acceptable to its peer. Attacks fingerprint for a valid certificate that is acceptable to its peer. Attacks
therefore rely on joining two separate sessions into a single session. <xref tar get="fp" format="default"/> therefore rely on joining two separate sessions into a single session. <xref tar get="fp" format="default" sectionFormat="of" derivedContent="Section 4"/>
describes an attack on SDP signaling under these constraints.</t> describes an attack on SDP signaling under these constraints.</t>
<t>Systems that rely on strong identity bindings, such as those defined <t indent="0" pn="section-2.1-4">Systems that rely on strong identity bi
in ndings, such as those defined in
<xref target="WEBRTC" format="default"/> or <xref target="RFC8224" format="defau <xref target="WEBRTC" format="default" sectionFormat="of" derivedContent="WEBRTC
lt"/>, have a different threat model, which admits the "/> or <xref target="RFC8224" format="default" sectionFormat="of" derivedContent
="SIP-ID"/>, have a different threat model, which admits the
possibility of attack by an entity with access to the signaling channel. 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 Attacks under these conditions are more feasible as an attacker is assumed to be
able both to observe and to modify signaling messages. <xref target="id" format ="default"/> describes an attack able both to observe and to modify signaling messages. <xref target="id" format ="default" sectionFormat="of" derivedContent="Section 3"/> describes an attack
that assumes this threat model.</t> that assumes this threat model.</t>
</section> </section>
<section anchor="continuity" numbered="true" toc="default"> <section anchor="continuity" numbered="true" toc="include" removeInRFC="fa
<name>Interactions with Key Continuity</name> lse" pn="section-2.2">
<t>Systems that use key continuity (as defined in <name slugifiedName="name-interactions-with-key-conti">Interactions with
<xref target="RFC6189" sectionFormat="of" section="15.1" format="default"/> Key Continuity</name>
or as recommended in <xref target="RFC8122" sectionFormat="of" section="7" forma <t indent="0" pn="section-2.2-1">Systems that use key continuity (as def
t="default"/>) might be able to detect an ined in
<xref target="RFC6189" sectionFormat="of" section="15.1" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc6189#section-15.1" derivedContent="ZRTP"/>
or as recommended in <xref target="RFC8122" sectionFormat="of" section="7" forma
t="default" derivedLink="https://rfc-editor.org/rfc/rfc8122#section-7" derivedCo
ntent="FINGERPRINT"/>) might be able to detect an
unknown key-share attack if a session with either the attacker or the genuine 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 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 established in the past. Whether this is possible depends on how key continuity
is implemented.</t> is implemented.</t>
<t>Implementations that maintain a single database of identities with an index of <t indent="0" pn="section-2.2-2">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 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 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 the actual keys (those copied from a victim) and the expected keys (those of the
attacker).</t> attacker).</t>
<t>In comparison, implementations that first match based on peer identit y could <t indent="0" pn="section-2.2-3">In comparison, implementations that fir st match based on peer identity could
treat an unknown key-share attack as though their peer had used a 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 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, user-visible notices (e.g., "Mallory appears to have a new device"). However,
such an event is not always considered alarming; some implementations might such an event is not always considered alarming; some implementations might
silently save a new key.</t> silently save a new key.</t>
</section> </section>
<section anchor="byebye-3pcc" numbered="true" toc="default"> <section anchor="byebye-3pcc" numbered="true" toc="include" removeInRFC="f
<name>Third-Party Call Control</name> alse" pn="section-2.3">
<name slugifiedName="name-third-party-call-control">Third-Party Call Con
<t>Third-party call control (3PCC) <xref target="RFC3725" format="defaul trol</name>
t"/> is a technique where a signaling <t indent="0" pn="section-2.3-1">Third-party call control (3PCC) <xref t
arget="RFC3725" format="default" sectionFormat="of" derivedContent="RFC3725"/> i
s a technique where a signaling
peer establishes a call that is terminated by a different entity. An unknown 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 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 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 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> 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="RFC8224" format="default"/>, as <t indent="0" pn="section-2.3-2">3PCC as described in RFC 3725 is incomp atible with SIP identity <xref target="RFC8224" format="default" sectionFormat=" of" derivedContent="SIP-ID"/>, as
SIP Identity relies on creating a binding between SIP requests and SDP. The 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. controller is the only entity that generates SIP requests in RFC 3725.
Therefore, in a 3PCC context, only the use of the <tt>fingerprint</tt> attribute Therefore, in a 3PCC context, only the use of the <tt>fingerprint</tt> attribute
without additional bindings or WebRTC identity <xref target="RFC8827" format="de without additional bindings or WebRTC identity <xref target="RFC8827" format="de
fault"/> is possible.</t> fault" sectionFormat="of" derivedContent="WEBRTC-SEC"/> is possible.</t>
<t>The attack mitigation mechanisms described in this document will prev <t indent="0" pn="section-2.3-3">The attack mitigation mechanisms descri
ent the use bed in this document will prevent the use
of 3PCC if peers have different views of the involved identities or the value of 3PCC if peers have different views of the involved identities or the value
of SDP <tt>tls-id</tt> attributes.</t> of SDP <tt>tls-id</tt> attributes.</t>
<t>For 3PCC to work with the proposed mechanisms, TLS peers need to be a ware of the <t indent="0" pn="section-2.3-4">For 3PCC to work with the proposed mech anisms, TLS peers need to be aware of the
signaling so that they can correctly generate and check the TLS extensions. For 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 a connection to be successfully established, a 3PCC controller needs either to
forward SDP without modification or to avoid modifications to <tt>fingerprint</t t>, forward SDP without modification or to avoid modifications to <tt>fingerprint</t t>,
<tt>tls-id</tt>, and <tt>identity</tt> attributes. A controller that follows th e best <tt>tls-id</tt>, and <tt>identity</tt> attributes. A controller that follows th e best
practices in RFC 3725 is expected to forward SDP without modification, thus practices in RFC 3725 is expected to forward SDP without modification, thus
ensuring the integrity of these attributes.</t> ensuring the integrity of these attributes.</t>
</section> </section>
</section> </section>
<section anchor="id" numbered="true" toc="default"> <section anchor="id" numbered="true" toc="include" removeInRFC="false" pn="s
<name>Unknown Key-Share Attack with Identity Bindings</name> ection-3">
<t>The identity assertions used for WebRTC <name slugifiedName="name-unknown-key-share-attack-wi">Unknown Key-Share A
(<xref target="RFC8827" sectionFormat="of" section="7" format="default"/>) and t ttack with Identity Bindings</name>
he <t indent="0" pn="section-3-1">The identity assertions used for WebRTC
Personal Assertion Token (PASSporT) used in SIP identity (<xref target="RFC8224" (<xref target="RFC8827" sectionFormat="of" section="7" format="default" derivedL
format="default"/>, <xref target="RFC8225" format="default"/>) are bound ink="https://rfc-editor.org/rfc/rfc8827#section-7" derivedContent="WEBRTC-SEC"/>
) and the
Personal Assertion Token (PASSporT) used in SIP identity (<xref target="RFC8224"
format="default" sectionFormat="of" derivedContent="SIP-ID"/>, <xref target="RF
C8225" format="default" sectionFormat="of" derivedContent="PASSPORT"/>) are boun
d
to the certificate fingerprint of an endpoint. An attacker can cause an identit y to the certificate fingerprint of an endpoint. An attacker can cause an identit y
binding to be created that binds an identity they control to the fingerprint of binding to be created that binds an identity they control to the fingerprint of
a first victim.</t> a first victim.</t>
<t>An attacker can thereby cause a second victim to believe that they are <t indent="0" pn="section-3-2">An attacker can thereby cause a second vict im to believe that they are
communicating with an attacker-controlled identity, when they are really talking communicating with an attacker-controlled identity, when they are really talking
to the first victim. The attacker does this by creating an identity assertion to the first victim. The attacker does this by creating an identity assertion
that covers a certificate fingerprint of the first victim.</t> 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 <t indent="0" pn="section-3-3">A variation on the same technique can be us ed to cause both victims to
believe they are talking to the attacker when they are talking to each other. 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 In this case, the attacker performs the identity misbinding once for each
victim.</t> victim.</t>
<t>The authority certifying the identity binding is not required to <t indent="0" pn="section-3-4">The authority certifying the identity bindi ng is not required to
verify that the entity requesting the binding actually controls the verify that the entity requesting the binding actually controls the
keys associated with the fingerprints, and this might appear to be keys associated with the fingerprints, and this might appear to be
the cause of the problem. SIP and WebRTC identity providers are not the cause of the problem. SIP and WebRTC identity providers are not
required to perform this validation.</t> required to perform this validation.</t>
<t>A simple solution to this problem is suggested by <xref target="SIGMA" format="default"/>. The identity of <t indent="0" pn="section-3-5">A simple solution to this problem is sugges ted by <xref target="SIGMA" format="default" sectionFormat="of" derivedContent=" SIGMA"/>. The identity of
endpoints is included under a message authentication code (MAC) during the endpoints is included under a message authentication code (MAC) during the
cryptographic handshake. Endpoints then validate that their peer has provided cryptographic handshake. Endpoints then validate that their peer has provided
an identity that matches their expectations. In TLS, the Finished message 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 provides a MAC over the entire handshake, so that including the identity in a
TLS extension is sufficient to implement this solution.</t> TLS extension is sufficient to implement this solution.</t>
<t>Rather than include a complete identity binding, which could be <t indent="0" pn="section-3-6">Rather than include a complete identity bin ding, which could be
sizable, a collision- and preimage-resistant hash of the binding is included sizable, a collision- and preimage-resistant hash of the binding is included
in a TLS extension as described in <xref target="external_id_hash" format="defau lt"/>. Endpoints then need in a TLS extension as described in <xref target="external_id_hash" format="defau lt" sectionFormat="of" derivedContent="Section 3.2"/>. Endpoints then need
only validate that the extension contains a hash of the identity binding they only validate that the extension contains a hash of the identity binding they
received in signaling. If the identity binding is successfully validated, the received in signaling. If the identity binding is successfully validated, the
identity of a peer is verified and bound to the session.</t> identity of a peer is verified and bound to the session.</t>
<t>This form of unknown key-share attack is possible without compromising <t indent="0" pn="section-3-7">This form of unknown key-share attack is po
signaling ssible without compromising signaling
integrity, unless the defenses described in <xref target="fp" format="default"/> integrity, unless the defenses described in <xref target="fp" format="default" s
are used. In order to ectionFormat="of" derivedContent="Section 4"/> are used. In order to
prevent both forms of attack, endpoints <bcp14>MUST</bcp14> use the <tt>external _session_id</tt> prevent both forms of attack, endpoints <bcp14>MUST</bcp14> use the <tt>external _session_id</tt>
extension (see <xref target="external_session_id" format="default"/>) in additio extension (see <xref target="external_session_id" format="default" sectionFormat
n to the <tt>external_id_hash</tt> ="of" derivedContent="Section 4.3"/>) in addition to the <tt>external_id_hash</t
(<xref target="external_id_hash" format="default"/>) so that two calls between t t>
he same parties can't be (<xref target="external_id_hash" format="default" sectionFormat="of" derivedCont
ent="Section 3.2"/>) so that two calls between the same parties can't be
altered by an attacker.</t> altered by an attacker.</t>
<section anchor="id-example" numbered="true" toc="default"> <section anchor="id-example" numbered="true" toc="include" removeInRFC="fa
<name>Example</name> lse" pn="section-3.1">
<t>In the example shown in <xref target="identity-attack" format="defaul <name slugifiedName="name-example">Example</name>
t"/>, it is assumed that the attacker <t indent="0" pn="section-3.1-1">In the example shown in <xref target="i
dentity-attack" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
it is assumed that the attacker
also controls the signaling channel.</t> also controls the signaling channel.</t>
<t>Mallory (the attacker) presents two victims, Norma and Patsy, with tw o separate <t indent="0" pn="section-3.1-2">Mallory (the attacker) presents two vic tims, Norma and Patsy, with two separate
sessions. In the first session, Norma is presented with the option to 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> communicate with Mallory; a second session with Norma is presented to Patsy.</t>
<figure anchor="identity-attack"> <figure anchor="identity-attack" align="left" suppress-title="false" pn=
<name>Example Attack on Identity Bindings</name> "figure-1">
<artwork align="left" alt=""><![CDATA[ <name slugifiedName="name-example-attack-on-identity-">Example Attack
on Identity Bindings</name>
<artwork align="left" alt="" pn="section-3.1-3.1">
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
|<---- Signaling1 ------&gt;| | |<---- Signaling1 ------&gt;| |
| Norma=N Mallory=P | | | Norma=N Mallory=P | |
| |<---- Signaling2 ------&gt;| | |<---- Signaling2 ------&gt;|
| | Norma=N Patsy=P | | | Norma=N Patsy=P |
| | | |
|<=================DTLS (fp=N,P)=================&gt;| |<=================DTLS (fp=N,P)=================&gt;|
| | | |
(peer = Mallory!) (peer = Norma) (peer = Mallory!) (peer = Norma)
]]></artwork> </artwork>
</figure> </figure>
<t>The attack requires that Mallory obtain an identity binding for her o wn identity <t indent="0" pn="section-3.1-4">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 with the fingerprints presented by Patsy (P), which Mallory might have obtained
previously. This false binding is then presented to Norma ('Signaling1' in previously. This false binding is then presented to Norma ('Signaling1' in
<xref target="identity-attack" format="default"/>).</t> <xref target="identity-attack" format="default" sectionFormat="of" derivedConten
<t>Patsy could be similarly duped, but in this example, a correct bindin t="Figure 1"/>).</t>
g between <t indent="0" pn="section-3.1-5">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 Norma's identity and fingerprint (N) is faithfully presented by Mallory. This
session ('Signaling2' in <xref target="identity-attack" format="default"/>) can session ('Signaling2' in <xref target="identity-attack" format="default" section
be entirely legitimate.</t> Format="of" derivedContent="Figure 1"/>) can be entirely legitimate.</t>
<t>A DTLS session is established directly between Norma and Patsy. <t indent="0" pn="section-3.1-6">A DTLS session is established directly
between Norma and Patsy.
In order for this to happen, Mallory can substitute transport-level In order for this to happen, Mallory can substitute transport-level
information in both sessions, though this is not necessary if Mallory information in both sessions, though this is not necessary if Mallory
is on the network path between Norma and Patsy. is on the network path between Norma and Patsy.
</t> </t>
<t>As a result, Patsy correctly believes that she is communicating with Norma. <t indent="0" pn="section-3.1-7">As a result, Patsy correctly believes t hat she is communicating with Norma.
However, Norma incorrectly believes that she is talking to Mallory. As stated i n However, Norma incorrectly believes that she is talking to Mallory. As stated i n
<xref target="uks" format="default"/>, Mallory cannot access media, but Norma mi ght send information to Patsy <xref target="uks" format="default" sectionFormat="of" derivedContent="Section 2 "/>, Mallory cannot access media, but Norma might send information to Patsy
that Norma might not intend or that Patsy might misinterpret.</t> that Norma might not intend or that Patsy might misinterpret.</t>
</section> </section>
<section anchor="external_id_hash" numbered="true" toc="default"> <section anchor="external_id_hash" numbered="true" toc="include" removeInR
<name>The <tt>external_id_hash</tt> TLS Extension</name> FC="false" pn="section-3.2">
<t>The <tt>external_id_hash</tt> TLS extension carries a hash of the ide <name slugifiedName="name-the-external_id_hash-tls-ex">The <tt>external_
ntity assertion id_hash</tt> TLS Extension</name>
<t indent="0" pn="section-3.2-1">The <tt>external_id_hash</tt> TLS exten
sion carries a hash of the identity assertion
that the endpoint sending the extension has asserted to its peer. Both peers that the endpoint sending the extension has asserted to its peer. Both peers
include a hash of their own identity assertion.</t> include a hash of their own identity assertion.</t>
<t>The <tt>extension_data</tt> for the <tt>external_id_hash</tt> extensi on contains a <t indent="0" pn="section-3.2-2">The <tt>extension_data</tt> for the <tt >external_id_hash</tt> extension contains a
<tt>ExternalIdentityHash</tt> struct, described below using the syntax defined i n <tt>ExternalIdentityHash</tt> struct, described below using the syntax defined i n
<xref target="RFC8446" sectionFormat="of" section="3" format="default"/>:</t> <xref target="RFC8446" sectionFormat="of" section="3" format="default" derivedLi
nk="https://rfc-editor.org/rfc/rfc8446#section-3" derivedContent="TLS13"/>:</t>
<sourcecode type="tls-presentation"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-3.2-3">
struct { struct {
opaque binding_hash<0..32&gt;; opaque binding_hash<0..32&gt;;
} ExternalIdentityHash; } ExternalIdentityHash;
]]></sourcecode> </sourcecode>
<t>Where an identity assertion has been asserted by a peer, this extensi <t indent="0" pn="section-3.2-4">Where an identity assertion has been as
on includes serted by a peer, this extension includes
a SHA-&wj;256 hash of the assertion. An empty value is used to indicate support a SHA-⁠256 hash of the assertion. An empty value is used to indicate support fo
for r
the extension.</t> the extension.</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal" indent="3" pn="section-3.2-5">
<dt>Note:</dt> <dt pn="section-3.2-5.1">Note:</dt>
<dd> <dd pn="section-3.2-5.2">
For both types of identity assertion, if SHA-&wj;256 should prove to be inadeq For both types of identity assertion, if SHA-⁠256 should prove to be inadequat
uate e
in the future (see <xref target="RFC7696" format="default"/>), a new TLS extensi in the future (see <xref target="RFC7696" format="default" sectionFormat="of" de
on rivedContent="AGILITY"/>), a new TLS extension
that uses a different hash function can be defined.</dd> that uses a different hash function can be defined.</dd>
</dl> </dl>
<t indent="0" pn="section-3.2-6">Identity bindings might be provided by
<t>Identity bindings might be provided by only one peer. An endpoint th only one peer. An endpoint that does not
at does not
produce an identity binding <bcp14>MUST</bcp14> generate an empty <tt>external_i d_hash</tt> extension produce an identity binding <bcp14>MUST</bcp14> generate an empty <tt>external_i d_hash</tt> extension
in its ClientHello or -- if a client provides the extension -- in ServerHello or in its ClientHello or -- if a client provides the extension -- in ServerHello or
EncryptedExtensions. An empty extension has a zero-length <tt>binding_hash</tt> field.</t> EncryptedExtensions. An empty extension has a zero-length <tt>binding_hash</tt> field.</t>
<t>A peer that receives an <tt>external_id_hash</tt> extension that does not match the <t indent="0" pn="section-3.2-7">A peer that receives an <tt>external_id _hash</tt> extension that does not match the
value of the identity binding from its peer <bcp14>MUST</bcp14> immediately fail the TLS value of the identity binding from its peer <bcp14>MUST</bcp14> immediately fail the TLS
handshake with an <tt>illegal_parameter</tt> alert. The absence of an identity binding handshake with 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 does not relax this requirement; if a peer provided no identity binding, a
zero-length extension <bcp14>MUST</bcp14> be present to be considered valid.</t> zero-length extension <bcp14>MUST</bcp14> be present to be considered valid.</t>
<t>Implementations written prior to the definition of the extensions in this <t indent="0" pn="section-3.2-8">Implementations written prior to the de finition of the extensions in this
document will not support this extension for some time. A peer that receives an document will not support this extension for some time. A peer that receives an
identity binding but does not receive an <tt>external_id_hash</tt> extension <bc p14>MAY</bcp14> accept identity binding but does not receive an <tt>external_id_hash</tt> extension <bc p14>MAY</bcp14> accept
a TLS connection rather than fail a connection where the extension is absent.</t > a TLS connection rather than fail a connection where the extension is absent.</t >
<t indent="0" pn="section-3.2-9">
<t>
The endpoint performs the validation of the <tt>external_id_hash</tt> extensi on The endpoint performs the validation of the <tt>external_id_hash</tt> extensi on
in addition to the validation required by <xref target="RFC8122" format="defa in addition to the validation required by <xref target="RFC8122" format="defa
ult"/> and any verification ult" sectionFormat="of" derivedContent="FINGERPRINT"/> and any verification
of the identity assertion <xref target="RFC8827" format="default"/> <xref tar of the identity assertion <xref target="RFC8827" format="default" sectionForm
get="RFC8224" format="default"/>. at="of" derivedContent="WEBRTC-SEC"/> <xref target="RFC8224" format="default" se
An endpoint <bcp14>MUST</bcp14> validate any external_session_id value that i ctionFormat="of" derivedContent="SIP-ID"/>.
s present; see <xref target="external_session_id" format="default"/>. An endpoint <bcp14>MUST</bcp14> validate any external_session_id value that i
s present; see <xref target="external_session_id" format="default" sectionFormat
="of" derivedContent="Section 4.3"/>.
</t> </t>
<t indent="0" pn="section-3.2-10">An <tt>external_id_hash</tt> extension
<t>An <tt>external_id_hash</tt> extension with a <tt>binding_hash</tt> f with a <tt>binding_hash</tt> field
ield
that is any length other than 0 or 32 is invalid that is any length other than 0 or 32 is invalid
and <bcp14>MUST</bcp14> cause the receiving endpoint to generate a fatal <tt>dec ode_error</tt> alert.</t> and <bcp14>MUST</bcp14> cause the receiving endpoint to generate a fatal <tt>dec ode_error</tt> alert.</t>
<t>In TLS 1.3, an <tt>external_id_hash</tt> extension sent by a server < bcp14>MUST</bcp14> be sent in the <t indent="0" pn="section-3.2-11">In TLS 1.3, an <tt>external_id_hash</t t> extension sent by a server <bcp14>MUST</bcp14> be sent in the
EncryptedExtensions message.</t> EncryptedExtensions message.</t>
<section anchor="calculating-externalidhash-for-webrtc-identity" numbere <section anchor="calculating-externalidhash-for-webrtc-identity" numbere
d="true" toc="default"> d="true" toc="include" removeInRFC="false" pn="section-3.2.1">
<name>Calculating <tt>external_id_hash</tt> for WebRTC Identity</name> <name slugifiedName="name-calculating-external_id_has">Calculating <tt
<t>A WebRTC identity assertion >external_id_hash</tt> for WebRTC Identity</name>
(<xref target="RFC8827" sectionFormat="of" section="7" format="default"/>) is pr <t indent="0" pn="section-3.2.1-1">A WebRTC identity assertion
ovided as a JSON (<xref target="RFC8827" sectionFormat="of" section="7" format="default" derivedL
<xref target="RFC8259" format="default"/> object that is encoded into a JSON tex ink="https://rfc-editor.org/rfc/rfc8827#section-7" derivedContent="WEBRTC-SEC"/>
t. The JSON text is ) is provided as a JSON
encoded using UTF-8 <xref target="RFC3629" format="default"/> as described by <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="JSON"
<xref target="RFC8259" sectionFormat="of" section="8.1" format="default"/>. /> object that is encoded into a JSON text. The JSON text is
encoded using UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" d
erivedContent="UTF8"/> as described by
<xref target="RFC8259" sectionFormat="of" section="8.1" format="default" derived
Link="https://rfc-editor.org/rfc/rfc8259#section-8.1" derivedContent="JSON"/>.
The content of the <tt>external_id_hash</tt> extension is produced by hashing th e The content of the <tt>external_id_hash</tt> extension is produced by hashing th e
resulting octets with SHA-&wj;256 <xref target="RFC6234" format="default"/>. Th is produces the 32 octets of resulting octets with SHA-⁠256 <xref target="RFC6234" format="default" sectionFo rmat="of" derivedContent="SHA"/>. This produces the 32 octets of
the <tt>binding_hash</tt> parameter, which is the sole contents of the extension .</t> the <tt>binding_hash</tt> parameter, which is the sole contents of the extension .</t>
<t>The SDP <tt>identity</tt> attribute includes the base64 <xref targe t="RFC4648" format="default"/> encoding of <t indent="0" pn="section-3.2.1-2">The SDP <tt>identity</tt> attribute includes the base64 <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="BASE64"/> encoding of
the UTF-8 encoding of the same JSON text. The <tt>external_id_hash</tt> extensi on is the UTF-8 encoding of the same JSON text. The <tt>external_id_hash</tt> extensi on is
validated by performing base64 decoding on the value of the SDP <tt>identity</tt > validated by performing base64 decoding on the value of the SDP <tt>identity</tt >
attribute, hashing the resulting octets using SHA-&wj;256, and comparing the res ults attribute, hashing the resulting octets using SHA-⁠256, and comparing the result s
with the content of the extension. In pseudocode form, using the with the content of the extension. In pseudocode form, using the
<tt>identity-assertion-value</tt> field from the SDP <tt>identity</tt> attribute grammar as <tt>identity-assertion-value</tt> field from the SDP <tt>identity</tt> attribute grammar as
defined in <xref target="RFC8827" format="default"/>:</t> defined in <xref target="RFC8827" format="default" sectionFormat="of" derivedCon
<sourcecode type="pseudocode"><![CDATA[ tent="WEBRTC-SEC"/>:</t>
<sourcecode type="pseudocode" markers="false" pn="section-3.2.1-3">
external_id_hash = SHA-256(b64decode(identity-assertion-value)) external_id_hash = SHA-256(b64decode(identity-assertion-value))
]]></sourcecode> </sourcecode>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal" indent="3" pn="section-3.2.1-4">
<dt>Note:</dt> <dt pn="section-3.2.1-4.1">Note:</dt>
<dd> <dd pn="section-3.2.1-4.2">
The base64 of the SDP <tt>identity</tt> attribute is decoded to avoid capturin g The base64 of the SDP <tt>identity</tt> attribute is decoded to avoid capturin g
variations in padding. The base64-decoded identity assertion could include variations in padding. The base64-decoded identity assertion could include
leading or trailing whitespace octets. WebRTC identity assertions are not leading or trailing whitespace octets. WebRTC identity assertions are not
canonicalized; all octets are hashed.</dd> canonicalized; all octets are hashed.</dd>
</dl> </dl>
</section> </section>
<section anchor="calculating-externalidhash-for-passport" numbered="true <section anchor="calculating-externalidhash-for-passport" numbered="true
" toc="default"> " toc="include" removeInRFC="false" pn="section-3.2.2">
<name>Calculating external_id_hash for PASSporT</name> <name slugifiedName="name-calculating-external_id_hash">Calculating ex
<t>Where the compact form of PASSporT <xref target="RFC8225" format="d ternal_id_hash for PASSporT</name>
efault"/> <t indent="0" pn="section-3.2.2-1">Where the compact form of PASSporT
<xref target="RFC8225" format="default" sectionFormat="of" derivedContent="PASSP
ORT"/>
is used, it <bcp14>MUST</bcp14> be expanded is used, it <bcp14>MUST</bcp14> be expanded
into the full form. The base64 encoding used in the SIP Identity (or 'y') into the full form. The base64 encoding used in the SIP Identity (or 'y')
header field <bcp14>MUST</bcp14> be decoded then used as input to SHA-&wj;256. This produces the header field <bcp14>MUST</bcp14> be decoded then used as input to SHA-⁠256. Thi s produces the
32-octet <tt>binding_hash</tt> value used for creating or validating the extensi on. In 32-octet <tt>binding_hash</tt> value used for creating or validating the extensi on. In
pseudocode, using the <tt>signed-identity-digest</tt> parameter from the <tt>Ide ntity</tt> header field grammar pseudocode, using the <tt>signed-identity-digest</tt> parameter from the <tt>Ide ntity</tt> header field grammar
defined <xref target="RFC8224" format="default"/>:</t> defined <xref target="RFC8224" format="default" sectionFormat="of" derivedConten
<sourcecode type="pseudocode"><![CDATA[ t="SIP-ID"/>:</t>
<sourcecode type="pseudocode" markers="false" pn="section-3.2.2-2">
external_id_hash = SHA-256(b64decode(signed-identity-digest)) external_id_hash = SHA-256(b64decode(signed-identity-digest))
]]></sourcecode> </sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="fp" numbered="true" toc="default"> <section anchor="fp" numbered="true" toc="include" removeInRFC="false" pn="s
<name>Unknown Key-Share Attack with Fingerprints</name> ection-4">
<t>An attack on DTLS-SRTP is possible because the identity of peers involv <name slugifiedName="name-unknown-key-share-attack-wit">Unknown Key-Share
ed is not Attack with Fingerprints</name>
<t indent="0" pn="section-4-1">An attack on DTLS-SRTP is possible because
the identity of peers involved is not
established prior to establishing the call. Endpoints use certificate established prior to establishing the call. Endpoints use certificate
fingerprints as a proxy for authentication, but as long as fingerprints are used fingerprints as a proxy for authentication, but as long as fingerprints are used
in multiple calls, they are vulnerable to attack.</t> in multiple calls, they are vulnerable to attack.</t>
<t>Even if the integrity of session signaling can be relied upon, an attac ker might <t indent="0" pn="section-4-2">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 still be able to create a session where there is confusion about the
communicating endpoints by substituting the fingerprint of a communicating communicating endpoints by substituting the fingerprint of a communicating
endpoint.</t> endpoint.</t>
<t>An endpoint that is configured to reuse a certificate can be attacked i f it is <t indent="0" pn="section-4-3">An endpoint that is configured to reuse a c ertificate can be attacked if it is
willing to initiate two calls at the same time, one of which is with an 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 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 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> 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 <t indent="0" pn="section-4-4">As with the attack on identity bindings, th is can be used to cause two victims
to both believe they are talking to the attacker when they are talking to each to both believe they are talking to the attacker when they are talking to each
other.</t> other.</t>
<section anchor="fp-example" numbered="true" toc="default"> <section anchor="fp-example" numbered="true" toc="include" removeInRFC="fa
<name>Example</name> lse" pn="section-4.1">
<t>To mount this attack, two sessions need to be created with the same e <name slugifiedName="name-example-2">Example</name>
ndpoint at <t indent="0" pn="section-4.1-1">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 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, the second session is created toward another honest endpoint. The
attacker convinces the first endpoint that their session with the attacker has attacker convinces the first endpoint that their session with the attacker has
been successfully established, but media is exchanged with the other honest been successfully established, but media is exchanged with the other honest
endpoint. The attacker permits the session with the other honest endpoint to 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 complete only to the extent necessary to convince the other honest endpoint to
participate in the attacked session.</t> participate in the attacked session.</t>
<t>In addition to the constraints described in <xref target="limits" for mat="default"/>, the attacker in this <t indent="0" pn="section-4.1-2">In addition to the constraints describe d in <xref target="limits" format="default" sectionFormat="of" derivedContent="S ection 2.1"/>, the attacker in this
example also needs the ability to view and drop packets between victims. example also needs the ability to view and drop packets between victims.
That is, the attacker needs to be on path for media.</t> That is, the attacker needs to be on path for media.</t>
<t>The attack shown in <xref target="implausible-attack" format="default "/> depends on a somewhat implausible set <t indent="0" pn="section-4.1-3">The attack shown in <xref target="impla usible-attack" format="default" sectionFormat="of" derivedContent="Figure 2"/> d epends on a somewhat implausible set
of conditions. It is intended to demonstrate what sort of attack is possible 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> and what conditions are necessary to exploit this weakness in the protocol.</t>
<figure anchor="implausible-attack"> <figure anchor="implausible-attack" align="left" suppress-title="false"
<name>Example Attack Scenario Using Fingerprints</name> pn="figure-2">
<artwork align="left" alt=""><![CDATA[ <name slugifiedName="name-example-attack-scenario-usi">Example Attack
Scenario Using Fingerprints</name>
<artwork align="left" alt="" pn="section-4.1-4.1">
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
+---Signaling1 (fp=N)--->| | +---Signaling1 (fp=N)---&gt;| |
+-----Signaling2 (fp=N)------------------------>| +-----Signaling2 (fp=N)------------------------&gt;|
|<-------------------------Signaling2 (fp=P)----+ |&lt;-------------------------Signaling2 (fp=P)----+
|<---Signaling1 (fp=P)---+ | |&lt;---Signaling1 (fp=P)---+ |
| | | | | |
|=======DTLS1=======>(Forward)======DTLS1======>| |=======DTLS1=======&gt;(Forward)======DTLS1======&gt;|
|<======DTLS2========(Forward)<=====DTLS2=======| |&lt;======DTLS2========(Forward)&lt;=====DTLS2=======|
|=======Media1======>(Forward)======Media1=====>| |=======Media1======&gt;(Forward)======Media1=====&gt;|
|<======Media2=======(Forward)<=====Media2======| |&lt;======Media2=======(Forward)&lt;=====Media2======|
| | | | | |
|=======DTLS2========>(Drop) | |=======DTLS2========&gt;(Drop) |
| | | | | |
]]></artwork> </artwork>
</figure> </figure>
<t>In this scenario, there are two sessions initiated at the same time b y Norma. <t indent="0" pn="section-4.1-5">In this scenario, there are two session s initiated at the same time by Norma.
Signaling is shown with single lines ('-'), DTLS and media with double lines Signaling is shown with single lines ('-'), DTLS and media with double lines
('=').</t> ('=').</t>
<t>The first session is established with Mallory, who falsely uses Patsy 's <t indent="0" pn="section-4.1-6">The first session is established with M allory, who falsely uses Patsy's
certificate fingerprint (denoted with 'fp=P'). A second session is initiated certificate fingerprint (denoted with 'fp=P'). A second session is initiated
between Norma and Patsy. Signaling for both sessions is permitted to complete.< /t> 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 <t indent="0" pn="section-4.1-7">Once signaling is complete on the first session, a DTLS connection is
established. Ostensibly, this connection is between Mallory and Norma, but established. Ostensibly, this connection is between Mallory and Norma, but
Mallory forwards DTLS and media packets sent to her by Norma to Patsy. These 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 packets are denoted 'DTLS1' because Norma associates these with the first
signaling session ('Signaling1').</t> signaling session ('Signaling1').</t>
<t>Mallory also intercepts packets from Patsy and forwards those to Norm a at the <t indent="0" pn="section-4.1-8">Mallory also intercepts packets from Pa tsy and forwards those to Norma at the
transport address that Norma associates with Mallory. These packets are denoted transport address that Norma associates with Mallory. These packets are denoted
'DTLS2' to indicate that Patsy associates these with the second signaling 'DTLS2' to indicate that Patsy associates these with the second signaling
session ('Signaling2'); however, Norma will interpret these as being associated session ('Signaling2'); however, Norma will interpret these as being associated
with the first signaling session ('Signaling1').</t> with the first signaling session ('Signaling1').</t>
<t>The second signaling exchange ('Signaling2'), which is between Norma and Patsy, is <t indent="0" pn="section-4.1-9">The second signaling exchange ('Signali ng2'), which is between Norma and Patsy, is
permitted to continue to the point where Patsy believes that it has succeeded. 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 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 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" fo rmat="default"/>, Mallory communicating with Patsy. Just like the example in <xref target="id-example" fo rmat="default" sectionFormat="of" derivedContent="Section 3.1"/>, Mallory
cannot access media, but Norma might send information to Patsy that Norma cannot access media, but Norma might send information to Patsy that Norma
might not intend or that Patsy might misinterpret.</t> might not intend or that Patsy might misinterpret.</t>
<t>Though Patsy needs to believe that the second signaling session has b een <t indent="0" pn="section-4.1-10">Though Patsy needs to believe that the second signaling session has been
successfully established, Mallory has no real interest in seeing that session successfully established, Mallory has no real interest in seeing that session
also be established. Mallory only needs to ensure that Patsy maintains the also be established. Mallory only needs to ensure that Patsy maintains the
active session and does not abandon the session prematurely. For this reason, 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 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 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 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 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 likely that Patsy will discard them as Patsy will already have a successful DTLS
connection established.</t> connection established.</t>
<t>For the attacked session to be sustained beyond the point that Norma detects <t indent="0" pn="section-4.1-11">For the attacked session to be sustain ed beyond the point that Norma detects
errors in the second session, Mallory also needs to block any signaling that 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 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.</t> might receive a notice that the call has failed and thereby abort the call.</t>
<t indent="0" pn="section-4.1-12">This attack creates an asymmetry in th
<t>This attack creates an asymmetry in the beliefs about the identity of e beliefs about the identity of peers.
peers.
However, this attack is only possible if the victim (Norma) is willing to 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 conduct two sessions nearly simultaneously; if the attacker (Mallory) is on the
network path between the victims; and if the same certificate -- and therefore network path between the victims; and if the same certificate -- and therefore
the SDP <tt>fingerprint</tt> attribute value -- is used by Norma for both sessio ns.</t> the SDP <tt>fingerprint</tt> attribute value -- is used by Norma for both sessio ns.</t>
<t>Where Interactive Connectivity Establishment (ICE) <xref target="RFC8 445" format="default"/> <t indent="0" pn="section-4.1-13">Where Interactive Connectivity Establi shment (ICE) <xref target="RFC8445" format="default" sectionFormat="of" derivedC ontent="ICE"/>
is used, Mallory also needs to ensure that is used, Mallory also needs to ensure that
connectivity checks between Patsy and Norma succeed, either by forwarding checks connectivity checks between Patsy and Norma succeed, either by forwarding checks
or by answering and generating the necessary messages.</t> or by answering and generating the necessary messages.</t>
</section> </section>
<section anchor="sess-id" numbered="true" toc="default"> <section anchor="sess-id" numbered="true" toc="include" removeInRFC="false
<name>Unique Session Identity Solution</name> " pn="section-4.2">
<t>The solution to this problem is to assign a new identifier to communi <name slugifiedName="name-unique-session-identity-sol">Unique Session Id
cating entity Solution</name>
<t indent="0" pn="section-4.2-1">The solution to this problem is to assi
gn a new identifier to communicating
peers. Each endpoint assigns their peer a unique identifier during call peers. Each endpoint assigns their peer a unique identifier during call
signaling. The peer echoes that identifier in the TLS handshake, binding that signaling. The peer echoes that identifier in the TLS handshake, binding that
identity into the session. Including this new identity in the TLS handshake 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 means that it will be covered by the TLS Finished message, which is necessary to
authenticate it (see <xref target="SIGMA" format="default"/>).</t> authenticate it (see <xref target="SIGMA" format="default" sectionFormat="of" de
<t>Successfully validating that the identifier matches the expected valu rivedContent="SIGMA"/>).</t>
e means that <t indent="0" pn="section-4.2-2">Successfully validating that the identi
fier matches the expected value means that
the connection corresponds to the signaled session and is therefore established the connection corresponds to the signaled session and is therefore established
between the correct two endpoints.</t> between the correct two endpoints.</t>
<t>This solution relies on the unique identifier given to DTLS sessions <t indent="0" pn="section-4.2-3">This solution relies on the unique iden
using the tifier given to DTLS sessions using the
SDP <tt>tls-id</tt> attribute <xref target="RFC8842" format="default"/>. This f SDP <tt>tls-id</tt> attribute <xref target="RFC8842" format="default" sectionFor
ield is mat="of" derivedContent="DTLS-SDP"/>. This field is
already required to be unique. Thus, no two offers or answers from the same already required to be unique. Thus, no two offers or answers from the same
client will have the same value.</t> client will have the same value.</t>
<t>A new <tt>external_session_id</tt> extension is added to the TLS or D TLS handshake for <t indent="0" pn="section-4.2-4">A new <tt>external_session_id</tt> exte nsion is added to the TLS or DTLS handshake for
connections that are established as part of the same call or real-time session. connections that are established as part of the same call or real-time session.
This carries the value of the <tt>tls-id</tt> attribute and provides integrity This carries the value of the <tt>tls-id</tt> attribute and provides integrity
protection for its exchange as part of the TLS or DTLS handshake.</t> protection for its exchange as part of the TLS or DTLS handshake.</t>
</section> </section>
<section anchor="external_session_id" numbered="true" toc="default"> <section anchor="external_session_id" numbered="true" toc="include" remove
<name>The external_session_id TLS Extension</name> InRFC="false" pn="section-4.3">
<t>The <tt>external_session_id</tt> TLS extension carries the unique ide <name slugifiedName="name-the-external_session_id-tls">The external_sess
ntifier that an ion_id TLS Extension</name>
<t indent="0" pn="section-4.3-1">The <tt>external_session_id</tt> TLS ex
tension carries the unique identifier that an
endpoint selects. When used with SDP, the value <bcp14>MUST</bcp14> include the <tt>tls-id</tt> endpoint selects. When used with SDP, the value <bcp14>MUST</bcp14> include the <tt>tls-id</tt>
attribute from the SDP that the endpoint generated when negotiating the session. 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 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 external session negotiation can use this extension to include a unique session
identifier.</t> identifier.</t>
<t>The <tt>extension_data</tt> for the <tt>external_session_id</tt> exte nsion contains an <t indent="0" pn="section-4.3-2">The <tt>extension_data</tt> for the <tt >external_session_id</tt> extension contains an
ExternalSessionId struct, described below using the syntax defined in ExternalSessionId struct, described below using the syntax defined in
<xref target="RFC8446" format="default"/>:</t> <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS13
<sourcecode type="tls-presentation"><![CDATA[ "/>:</t>
<sourcecode type="tls-presentation" markers="false" pn="section-4.3-3">
struct { struct {
opaque session_id<20..255&gt;; opaque session_id<20..255&gt;;
} ExternalSessionId; } ExternalSessionId;
]]></sourcecode> </sourcecode>
<t>For SDP, the <tt>session_id</tt> field of the extension includes the <t indent="0" pn="section-4.3-4">For SDP, the <tt>session_id</tt> field
value of the of the extension includes the value of the
<tt>tls-id</tt> SDP attribute as defined in <xref target="RFC8842" format="defau <tt>tls-id</tt> SDP attribute as defined in <xref target="RFC8842" format="defau
lt"/> lt" sectionFormat="of" derivedContent="DTLS-SDP"/>
(that is, the <tt>tls-id-value</tt> ABNF production). The value of the <tt>tls- id</tt> (that is, the <tt>tls-id-value</tt> ABNF production). The value of the <tt>tls- id</tt>
attribute is encoded using ASCII <xref target="RFC0020" format="default"/>.</t> attribute is encoded using ASCII <xref target="RFC0020" format="default" section
<t>Where RTP and RTCP <xref target="RFC3550" format="default"/> are not Format="of" derivedContent="ASCII"/>.</t>
multiplexed, it is possible that the <t indent="0" pn="section-4.3-5">Where RTP and RTCP <xref target="RFC355
0" format="default" sectionFormat="of" derivedContent="RTP"/> are not multiplexe
d, it is possible that the
two separate DTLS connections carrying RTP and RTCP can be switched. This is two separate DTLS connections carrying RTP and RTCP can be switched. This is
considered benign since these protocols are designed to be distinguishable as considered benign since these protocols are designed to be distinguishable as
SRTP <xref target="RFC3711" format="default"/> provides key separation. Using R SRTP <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="
TP/RTCP multiplexing SRTP"/> provides key separation. Using RTP/RTCP multiplexing
<xref target="RFC5761" format="default"/> further avoids this problem.</t> <xref target="RFC5761" format="default" sectionFormat="of" derivedContent="RTCP-
<t>The <tt>external_session_id</tt> extension is included in a ClientHel MUX"/> further avoids this problem.</t>
lo, and if the <t indent="0" pn="section-4.3-6">The <tt>external_session_id</tt> extens
ion is included in a ClientHello, and if the
extension is present in the ClientHello, either ServerHello (for TLS and DTLS extension is present in the ClientHello, either ServerHello (for TLS and DTLS
versions older than 1.3) or EncryptedExtensions (for TLS 1.3).</t> versions older than 1.3) or EncryptedExtensions (for TLS 1.3).</t>
<t>Endpoints <bcp14>MUST</bcp14> check that the <tt>session_id</tt> para meter in the extension that they <t indent="0" pn="section-4.3-7">Endpoints <bcp14>MUST</bcp14> check tha t the <tt>session_id</tt> parameter in the extension that they
receive includes the <tt>tls-id</tt> attribute value that they received in their peer's receive includes the <tt>tls-id</tt> attribute value that they received in their peer's
session description. Endpoints can perform string comparison by ASCII decoding session description. Endpoints can perform string comparison by ASCII decoding
the TLS extension value and comparing it to the SDP attribute value or by compar ing the TLS extension value and comparing it to the SDP attribute value or by compar ing
the encoded TLS extension octets with the encoded SDP attribute value. An the encoded TLS extension octets with the encoded SDP attribute value. An
endpoint that receives an <tt>external_session_id</tt> extension that is not ide ntical endpoint that receives an <tt>external_session_id</tt> extension that is not ide ntical
to the value that it expects <bcp14>MUST</bcp14> abort the connection with a fat al to the value that it expects <bcp14>MUST</bcp14> abort the connection with a fat al
<tt>illegal_parameter</tt> alert.</t> <tt>illegal_parameter</tt> alert.</t>
<t> <t indent="0" pn="section-4.3-8">
The endpoint performs the validation of the <tt>external_id_hash</tt> extensi on in The endpoint performs the validation of the <tt>external_id_hash</tt> extensi on in
addition to the validation required by <xref target="RFC8122" format="default "/>. addition to the validation required by <xref target="RFC8122" format="default " sectionFormat="of" derivedContent="FINGERPRINT"/>.
</t> </t>
<t>If an endpoint communicates with a peer that does not support this <t indent="0" pn="section-4.3-9">If an endpoint communicates with a peer that does not support this
extension, it will receive a ClientHello, ServerHello, or EncryptedExtensions me ssage that extension, it will receive a ClientHello, ServerHello, or EncryptedExtensions me ssage that
does not include this extension. An endpoint <bcp14>MAY</bcp14> choose to conti nue a session does not include this extension. An endpoint <bcp14>MAY</bcp14> choose to conti nue a session
without this extension in order to interoperate with peers that do not implement without this extension in order to interoperate with peers that do not implement
this specification.</t> this specification.</t>
<t>In TLS 1.3, an <tt>external_session_id</tt> extension sent by a serve r <bcp14>MUST</bcp14> be sent in <t indent="0" pn="section-4.3-10">In TLS 1.3, an <tt>external_session_id </tt> extension sent by a server <bcp14>MUST</bcp14> be sent in
the EncryptedExtensions message.</t> the EncryptedExtensions message.</t>
<t>This defense is not effective if an attacker can rewrite <tt>tls-id</ tt> values in <t indent="0" pn="section-4.3-11">This defense is not effective if an at tacker can rewrite <tt>tls-id</tt> values in
signaling. Only the mechanism in <tt>external_id_hash</tt> is able to defend ag ainst signaling. Only the mechanism in <tt>external_id_hash</tt> is able to defend ag ainst
an attacker that can compromise session integrity.</t> an attacker that can compromise session integrity.</t>
</section> </section>
</section> </section>
<section anchor="concat" numbered="true" toc="default"> <section anchor="concat" numbered="true" toc="include" removeInRFC="false" p
<name>Session Concatenation</name> n="section-5">
<t>Use of session identifiers does not prevent an attacker from <name slugifiedName="name-session-concatenation">Session Concatenation</na
me>
<t indent="0" pn="section-5-1">Use of session identifiers does not prevent
an attacker from
establishing two concurrent sessions with different peers and establishing two concurrent sessions with different peers and
forwarding signaling from those peers to each other. Concatenating forwarding signaling from those peers to each other. Concatenating
two signaling sessions in this way creates two signaling sessions, two signaling sessions in this way creates two signaling sessions,
with two session identifiers, but only the TLS connections from a with two session identifiers, but only the TLS connections from a
single session are established as a result. In doing so, the single session are established as a result. In doing so, the
attacker creates a situation where both peers believe that they are attacker creates a situation where both peers believe that they are
talking to the attacker when they are talking to each other.</t> talking to the attacker when they are talking to each other.</t>
<t>In the absence of any higher-level concept of peer identity, an <t indent="0" pn="section-5-2">In the absence of any higher-level concept of peer identity, an
attacker who is able to copy the session identifier from attacker who is able to copy the session identifier from
one signaling session to another can cause the peers to establish a one signaling session to another can cause the peers to establish a
direct TLS connection even while they think that they are connecting direct TLS connection even while they think that they are connecting
to the attacker. This differs from the attack described in the to the attacker. This differs from the attack described in the
previous section in that there is only one TLS connection rather than previous section in that there is only one TLS connection rather than
two. This kind of attack is prevented by systems that enable peer two. This kind of attack is prevented by systems that enable peer
authentication, such as WebRTC identity <xref target="RFC8827" format="default"/ authentication, such as WebRTC identity <xref target="RFC8827" format="default"
> or SIP identity sectionFormat="of" derivedContent="WEBRTC-SEC"/> or SIP identity
<xref target="RFC8224" format="default"/>; however, these systems do not prevent <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="SIP-I
establishing D"/>; however, these systems do not prevent establishing
two back-to-back connections as described in the previous paragraph.</t> two back-to-back connections as described in the previous paragraph.</t>
<t>Use of the <tt>external_session_id</tt> does not guarantee that the ide ntity of the <t indent="0" pn="section-5-3">Use of the <tt>external_session_id</tt> doe s not guarantee that the identity of the
peer at the TLS layer is the same as the identity of the signaling peer. 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 dat a is advantage that an attacker gains by concatenating sessions is limited unless dat a is
exchanged based on the assumption that signaling and TLS peers are the same. If a 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 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 . 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 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 connecti ons.</t> requires that the signaling layer is authenticated and bound to any TLS connecti ons.</t>
<t>It is important to note that multiple connections can be created within the same <t indent="0" pn="section-5-4">It is important to note that multiple conne ctions can be created within the same
signaling session. An attacker might concatenate only part of a session, signaling session. An attacker might concatenate only part of a session,
choosing to terminate some connections (and optionally forward data) while choosing to terminate some connections (and optionally forward data) while
arranging to have peers interact directly for other connections. It is even arranging to have peers interact directly for other connections. It is even
possible to have different peers interact for each connection. This means that 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 the actual identity of the peer for one connection might differ from the peer on
another connection.</t> another connection.</t>
<t>Critically, information about the identity of TLS peers provides no ass urances <t indent="0" pn="section-5-5">Critically, information about the identity of TLS peers provides no assurances
about the identity of signaling peers and does not transfer between TLS about the identity of signaling peers and does not transfer between TLS
connections in the same session. Information extracted from a TLS connection connections in the same session. Information extracted from a TLS connection
therefore <bcp14>MUST NOT</bcp14> be used in a secondary protocol outside of tha t connection if therefore <bcp14>MUST NOT</bcp14> be used in a secondary protocol outside of tha t connection if
that protocol assumes that the signaling protocol has the same peers. that protocol assumes that the signaling protocol has the same peers.
Similarly, security-sensitive information from one TLS connection <bcp14>MUST NO T</bcp14> be Similarly, security-sensitive information from one TLS connection <bcp14>MUST NO T</bcp14> be
used in other TLS connections even if they are established as a result of the used in other TLS connections even if they are established as a result of the
same signaling session.</t> same signaling session.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="include" remo
<name>Security Considerations</name> veInRFC="false" pn="section-6">
<t>When combined with identity assertions, the mitigations in this documen <name slugifiedName="name-security-considerations">Security Considerations
t ensure </name>
<t indent="0" pn="section-6-1">When combined with identity assertions, the
mitigations in this document ensure
that there is no opportunity to misrepresent the identity of TLS peers. This 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> assurance is provided even if an attacker can modify signaling messages.</t>
<t indent="0" pn="section-6-2">Without identity assertions, the mitigation
<t>Without identity assertions, the mitigations in this document prevent t s in this document prevent the
he session splicing attack described in <xref target="fp" format="default" sectionF
session splicing attack described in <xref target="fp" format="default"/>. Defe ormat="of" derivedContent="Section 4"/>. Defense against session
nse against session concatenation (<xref target="concat" format="default" sectionFormat="of" derived
concatenation (<xref target="concat" format="default"/>) additionally requires t Content="Section 5"/>) additionally requires that protocol peers are not able to
hat protocol peers are not able to
claim the certificate fingerprints of other entities.</t> claim the certificate fingerprints of other entities.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="include" removeIn
<section anchor="iana-considerations" numbered="true" toc="default"> RFC="false" pn="section-7">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document registers two extensions in the "TLS ExtensionType Values <t indent="0" pn="section-7-1">This document registers two extensions in t
" he "TLS ExtensionType Values"
registry established in <xref target="RFC8446" format="default"/>:</t> registry established in <xref target="RFC8446" format="default" sectionFormat="o
<ul spacing="normal"> f" derivedContent="TLS13"/>:</t>
<li>The <tt>external_id_hash</tt> extension defined in <xref target="ext <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-2
ernal_id_hash" format="default"/> has been ">
<li pn="section-7-2.1">The <tt>external_id_hash</tt> extension defined i
n <xref target="external_id_hash" format="default" sectionFormat="of" derivedCon
tent="Section 3.2"/> has been
assigned a code point of 55; it is recommended and is marked as "CH, EE" assigned a code point of 55; it is recommended and is marked as "CH, EE"
in TLS 1.3.</li> in TLS 1.3.</li>
<li>The <tt>external_session_id</tt> extension defined in <xref target=" external_session_id" format="default"/> has <li pn="section-7-2.2">The <tt>external_session_id</tt> extension define d in <xref target="external_session_id" format="default" sectionFormat="of" deri vedContent="Section 4.3"/> has
been assigned a code point of 56; it is recommended and is marked as been assigned a code point of 56; it is recommended and is marked as
"CH, EE" in TLS 1.3.</li> "CH, EE" in TLS 1.3.</li>
</ul> </ul>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC0020" to="ASCII"/> <displayreference target="RFC0020" to="ASCII"/>
<displayreference target="RFC3550" to="RTP"/> <displayreference target="RFC3550" to="RTP"/>
<displayreference target="RFC3629" to="UTF8"/> <displayreference target="RFC3629" to="UTF8"/>
<displayreference target="RFC3711" to="SRTP"/> <displayreference target="RFC3711" to="SRTP"/>
skipping to change at line 648 skipping to change at line 739
<displayreference target="RFC6347" to="DTLS"/> <displayreference target="RFC6347" to="DTLS"/>
<displayreference target="RFC7696" to="AGILITY"/> <displayreference target="RFC7696" to="AGILITY"/>
<displayreference target="RFC8122" to="FINGERPRINT"/> <displayreference target="RFC8122" to="FINGERPRINT"/>
<displayreference target="RFC8224" to="SIP-ID"/> <displayreference target="RFC8224" to="SIP-ID"/>
<displayreference target="RFC8225" to="PASSPORT"/> <displayreference target="RFC8225" to="PASSPORT"/>
<displayreference target="RFC8259" to="JSON"/> <displayreference target="RFC8259" to="JSON"/>
<displayreference target="RFC8445" to="ICE"/> <displayreference target="RFC8445" to="ICE"/>
<displayreference target="RFC8446" to="TLS13"/> <displayreference target="RFC8446" to="TLS13"/>
<displayreference target="RFC8827" to="WEBRTC-SEC"/> <displayreference target="RFC8827" to="WEBRTC-SEC"/>
<displayreference target="RFC8842" to="DTLS-SDP"/> <displayreference target="RFC8842" to="DTLS-SDP"/>
<references> <references pn="section-8">
<name>References</name> <name slugifiedName="name-references">References</name>
<references> <references pn="section-8.1">
<name>Normative References</name> <name slugifiedName="name-normative-references">Normative References</na
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer me>
ence.RFC.8446.xml"/> <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc2
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer 0" quoteTitle="true" derivedAnchor="ASCII">
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3711.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5763.xml"/>
<!-- draft-ietf-rtcweb-security-arch in C238; RFC 8827 -->
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='May' year='2020'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8224.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8225.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3629.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4648.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
0020.xml"/>
<!-- draft-ietf-mmusic-dtls-sdp-32 in C238; RFC 8842 -->
<reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8842">
<front>
<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>
<author initials="R." surname="Shpount" fullname="Roman Shpount">
<organization />
</author>
<date month="May" year="2020" />
</front>
<seriesInfo name="RFC" value="8842" />
<seriesInfo name="DOI" value="10.17487/RFC8842"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="UKS">
<front> <front>
<title>Unknown Key-Share Attacks on the Station-to-Station (STS) Pro <title>ASCII format for network interchange</title>
tocol</title> <author initials="V.G." surname="Cerf" fullname="V.G. Cerf">
<author initials="S." surname="Blake-Wilson"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="A." surname="Menezes"> <date year="1969" month="October"/>
<organization/> </front>
<seriesInfo name="STD" value="80"/>
<seriesInfo name="RFC" value="20"/>
<seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648" quoteTitle="true" derivedAnchor="BASE64">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="1999" month="March"/> <date year="2006" month="October"/>
<abstract>
<t indent="0">This document describes the commonly used base 64, b
ase 32, and base 16 encoding schemes. It also discusses the use of line-feeds i
n encoded data, use of padding in encoded data, use of non-alphabet characters i
n encoded data, use of different encoding alphabets, and canonical encodings. [
STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="DOI" value="10.1007/3-540-49162-7_12"/> <seriesInfo name="RFC" value="4648"/>
<refcontent>Public Key Cryptography</refcontent> <seriesInfo name="DOI" value="10.17487/RFC4648"/>
<refcontent>Lecture Notes in Computer Science</refcontent>
<refcontent>Vol. 1560</refcontent>
</reference> </reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
<reference anchor="SIGMA"> 347" quoteTitle="true" derivedAnchor="DTLS">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t indent="0">This document specifies version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol. This documen
t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8
842" quoteTitle="true" derivedAnchor="DTLS-SDP">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Consideration
s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS
)</title>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg
">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shpount" fullname="Roman Shpount">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8842"/>
<seriesInfo name="DOI" value="10.17487/RFC8842"/>
</reference>
<reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5
763" quoteTitle="true" derivedAnchor="DTLS-SRTP">
<front>
<title>Framework for Establishing a Secure Real-time Transport Proto
col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
e>
<author initials="J." surname="Fischl" fullname="J. Fischl">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="May"/>
<abstract>
<t indent="0">This document specifies how to use the Session Initi
ation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) s
ecurity context using the Datagram Transport Layer Security (DTLS) protocol. It
describes a mechanism of transporting a fingerprint attribute in the Session De
scription Protocol (SDP) that identifies the key that will be presented during t
he 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 integ
rity of the fingerprint attribute from modification by intermediate proxies. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5763"/>
<seriesInfo name="DOI" value="10.17487/RFC5763"/>
</reference>
<reference anchor="RFC8122" target="https://www.rfc-editor.org/info/rfc8
122" quoteTitle="true" derivedAnchor="FINGERPRINT">
<front>
<title>Connection-Oriented Media Transport over the Transport Layer
Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">This document specifies how to establish secure conn
ection-oriented media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines the SDP prot
ocol 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 indent="0">This document obsoletes RFC 4572 by clarifying the u
sage of multiple fingerprints.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8122"/>
<seriesInfo name="DOI" value="10.17487/RFC8122"/>
</reference>
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
259" quoteTitle="true" derivedAnchor="JSON">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="December"/>
<abstract>
<t indent="0">JavaScript Object Notation (JSON) is a lightweight,
text-based, language-independent data interchange format. It was derived from t
he ECMAScript Programming Language Standard. JSON defines a small set of format
ting rules for the portable representation of structured data.</t>
<t indent="0">This document removes inconsistencies with other spe
cifications of JSON, repairs specification errors, and offers experience-based i
nteroperability guidance.</t>
</abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>
<reference anchor="RFC8225" target="https://www.rfc-editor.org/info/rfc8
225" quoteTitle="true" derivedAnchor="PASSPORT">
<front>
<title>PASSporT: Personal Assertion Token</title>
<author initials="C." surname="Wendt" fullname="C. Wendt">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">This document defines a method for creating and vali
dating a token that cryptographically verifies an originating identity or, more
generally, a URI or telephone number representing the originator of personal com
munications. The Personal Assertion Token, PASSporT, is cryptographically signe
d to protect the integrity of the identity of the originator and to verify the a
ssertion of the identity information at the destination. The cryptographic sign
ature is defined with the intention that it can confidently verify the originati
ng persona even when the signature is sent to the destination party over an inse
cure channel. PASSporT is particularly useful for many personal-communications
applications over IP networks and other multi-hop interconnection scenarios wher
e the originating and destination parties may not have a direct trusted relation
ship.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8225"/>
<seriesInfo name="DOI" value="10.17487/RFC8225"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
566" quoteTitle="true" derivedAnchor="SDP">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">This memo defines the Session Description Protocol (
SDP). SDP is intended for describing multimedia sessions for the purposes of se
ssion announcement, session invitation, and other forms of multimedia session in
itiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4566"/>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
</reference>
<reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6
234" quoteTitle="true" derivedAnchor="SHA">
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</
title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Hansen" fullname="T. Hansen">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="May"/>
<abstract>
<t indent="0">Federal Information Processing Standard, FIPS</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6234"/>
<seriesInfo name="DOI" value="10.17487/RFC6234"/>
</reference>
<reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8
224" quoteTitle="true" derivedAnchor="SIP-ID">
<front>
<title>Authenticated Identity Management in the Session Initiation P
rotocol (SIP)</title>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Jennings" fullname="C. Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Wendt" fullname="C. Wendt">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">The baseline security mechanisms in the Session Init
iation Protocol (SIP) are inadequate for cryptographically assuring the identity
of the end users that originate SIP requests, especially in an interdomain cont
ext. This document defines a mechanism for securely identifying originators of
SIP requests. It does so by defining a SIP header field for conveying a signatu
re used for validating the identity and for conveying a reference to the credent
ials of the signer.</t>
<t indent="0">This document obsoletes RFC 4474.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8224"/>
<seriesInfo name="DOI" value="10.17487/RFC8224"/>
</reference>
<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3
711" quoteTitle="true" derivedAnchor="SRTP">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Naslund" fullname="M. Naslund">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Norrman" fullname="K. Norrman">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="March"/>
<abstract>
<t indent="0">This document describes the Secure Real-time Transpo
rt Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which c
an 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>
</front>
<seriesInfo name="RFC" value="3711"/>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="TLS13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3
629" quoteTitle="true" derivedAnchor="UTF8">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" fullname="F. Yergeau">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="November"/>
<abstract>
<t indent="0">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 compa
tible with many current applications and protocols, and this has led to the deve
lopment of UTF-8, the object of this memo. UTF-8 has the characteristic of pres
erving the full US-ASCII range, providing compatibility with file systems, parse
rs and other software that rely on US-ASCII values but are transparent to other
values. This memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
827" quoteTitle="true" derivedAnchor="WEBRTC-SEC">
<front>
<title>WebRTC Security Architecture</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC7696" target="https://www.rfc-editor.org/info/rfc7
696" quoteTitle="true" derivedAnchor="AGILITY">
<front>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting
Mandatory-to-Implement Algorithms</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">Many IETF protocols use cryptographic algorithms to
provide confidentiality, integrity, authentication, or digital signature. Commu
nicating peers must support a common set of cryptographic algorithms for these m
echanisms to work properly. This memo provides guidelines to ensure that protoc
ols have the ability to migrate from one mandatory-to-implement algorithm suite
to another over time.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="201"/>
<seriesInfo name="RFC" value="7696"/>
<seriesInfo name="DOI" value="10.17487/RFC7696"/>
</reference>
<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
445" quoteTitle="true" derivedAnchor="ICE">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">This document describes a protocol for Network Addre
ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
elay NAT (TURN).</t>
<t indent="0">This document obsoletes RFC 5245.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
<reference anchor="RFC3725" target="https://www.rfc-editor.org/info/rfc3
725" quoteTitle="true" derivedAnchor="RFC3725">
<front>
<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 showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="April"/>
<abstract>
<t indent="0">Third party call control refers to the ability of on
e entity to create a call in which communication is actually between other parti
es. Third party call control is possible using the mechanisms specified within
the Session Initiation Protocol (SIP). However, there are several possible appr
oaches, each with different benefits and drawbacks. This document discusses bes
t current practices for the usage of SIP for third party call control. This doc
ument specifies an Internet Best Current Practices for the Internet Community, a
nd requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="85"/>
<seriesInfo name="RFC" value="3725"/>
<seriesInfo name="DOI" value="10.17487/RFC3725"/>
</reference>
<reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5
761" quoteTitle="true" derivedAnchor="RTCP-MUX">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</t
itle>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="April"/>
<abstract>
<t indent="0">This memo discusses issues that arise when multiplex
ing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP por
t. 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>
</front>
<seriesInfo name="RFC" value="5761"/>
<seriesInfo name="DOI" value="10.17487/RFC5761"/>
</reference>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
550" quoteTitle="true" derivedAnchor="RTP">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
rt protocol. RTP provides end-to-end network transport functions suitable for a
pplications transmitting real-time data, such as audio, video or simulation data
, over multicast or unicast network services. RTP does not address resource res
ervation 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 prov
ide 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 govern
ing how the protocol is used. The biggest change is an enhancement to the scalab
le timer algorithm for calculating when to send RTCP packets in order to minimiz
e transmission in excess of the intended rate when many participants join a sess
ion simultaneously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="SIGMA" quoteTitle="true" target="https://doi.org/10.1
007/978-3-540-45146-4_24" derivedAnchor="SIGMA">
<front> <front>
<title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-He llman and Its Use in the IKE Protocols</title> <title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-He llman and Its Use in the IKE Protocols</title>
<author initials="H." surname="Krawczyk"> <author initials="H." surname="Krawczyk">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2003" month="August"/> <date year="2003" month="August"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_24"/> <seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_24"/>
<refcontent>Advances in Cryptology -- CRYPTO 2003</refcontent> <refcontent>Advances in Cryptology -- CRYPTO 2003</refcontent>
<refcontent>Lecture Notes in Computer Science</refcontent> <refcontent>Lecture Notes in Computer Science</refcontent>
<refcontent>Vol. 2729</refcontent> <refcontent>Vol. 2729</refcontent>
</reference> </reference>
<reference anchor="UKS" quoteTitle="true" target="https://doi.org/10.100
<reference anchor="WEBRTC" target="https://www.w3.org/TR/2019/CR-webrtc- 7/3-540-49162-7_12" derivedAnchor="UKS">
20191213/"> <front>
<title>Unknown Key-Share Attacks on the Station-to-Station (STS) Pro
tocol</title>
<author initials="S." surname="Blake-Wilson">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Menezes">
<organization showOnFrontPage="true"/>
</author>
<date year="1999" month="March"/>
</front>
<seriesInfo 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>
<reference anchor="WEBRTC" target="https://www.w3.org/TR/2019/CR-webrtc-
20191213/" quoteTitle="true" derivedAnchor="WEBRTC">
<front> <front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title> <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials="C." surname="Jennings"> <author initials="C." surname="Jennings">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="H." surname="Boström"> <author initials="H." surname="Boström">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J-I." surname="Bruaroey"> <author initials="J-I." surname="Bruaroey">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2019" month="December" day="13"/> <date year="2019" month="December" day="13"/>
</front> </front>
<refcontent>W3C Candidate Recommendation</refcontent> <refcontent>W3C Candidate Recommendation</refcontent>
</reference> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <reference anchor="RFC6189" target="https://www.rfc-editor.org/info/rfc6
ence.RFC.3725.xml"/> 189" quoteTitle="true" derivedAnchor="ZRTP">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <front>
ence.RFC.6189.xml"/> <title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <author initials="P." surname="Zimmermann" fullname="P. Zimmermann">
ence.RFC.7696.xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer </author>
ence.RFC.8445.xml"/> <author initials="A." surname="Johnston" fullname="A. Johnston" role
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ="editor">
ence.RFC.3550.xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer </author>
ence.RFC.5761.xml"/> <author initials="J." surname="Callas" fullname="J. Callas">
</references> <organization showOnFrontPage="true"/>
</author>
<date year="2011" month="April"/>
<abstract>
<t indent="0">This document defines ZRTP, a protocol for media pat
h Diffie-Hellman exchange to agree on a session key and parameters for establish
ing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over I
P (VoIP) applications. The ZRTP protocol is media path keying because it is mul
tiplexed on the same port as RTP and does not require support in the signaling p
rotocol. 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 c
ases where the signaling protocol provides end-to-end integrity protection, auth
entication. 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 secur
e media sessions that do not include voice by using an optional digital signatur
e. This document is not an Internet Standards Track specification; it is publi
shed for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6189"/>
<seriesInfo name="DOI" value="10.17487/RFC6189"/>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default"> <section anchor="acknowledgements" numbered="false" toc="include" removeInRF
<name>Acknowledgements</name> C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t>This problem would not have been discovered if it weren't for <t indent="0" pn="section-appendix.a-1">This problem would not have been d
discussions with <contact fullname="Sam Scott"/>, <contact iscovered if it weren't for
fullname="Hugo Krawczyk"/>, and <contact fullname="Richard Barnes"/>. A discussions with <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 solution similar to the one presented here was first proposed by
<contact fullname="Karthik Bhargavan"/>, who provided valuable input on <contact fullname="Karthik Bhargavan"/>, who provided valuable input on
this document. <contact fullname="Thyla van der Merwe"/> assisted with this document. <contact fullname="Thyla van der Merwe"/> assisted with
a formal model of the solution. <contact fullname="Adam Roach"/> and a formal model of the solution. <contact fullname="Adam Roach"/> and
<contact fullname="Paul E. Jones"/> provided significant review and <contact fullname="Paul E. Jones"/> provided significant review and
input.</t> input.</t>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>mt@lowentropy.net</email>
</address>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>ekr@rtfm.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 151 change blocks. 
452 lines changed or deleted 1220 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/