rfc8844xml2.original.xml   rfc8844.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 --> nsus="true" docName="draft-ietf-mmusic-sdp-uks-07" indexInclude="true" ipr="trus
t200902" number="8844" prepTime="2021-01-16T23:06:51" scripts="Common,Latin" sor
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ tRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true"
]> updates="8122" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks-07" rel
<rfc ipr="trust200902" docName="draft-ietf-mmusic-sdp-uks-07" category="std" upd ="prev"/>
ates="8122"> <link href="https://dx.doi.org/10.17487/rfc8844" rel="alternate"/>
<?rfc toc="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<front> <front>
<title abbrev="SDP UKS">Unknown Key Share Attacks on uses of TLS with the Se <title abbrev="SDP UKS">Unknown Key-Share Attacks on Uses of TLS with the Se
ssion Description Protocol (SDP)</title> ssion Description Protocol (SDP)</title>
<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@rftm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date year="2019" month="August" day="09"/> <keyword>Unknown Key-Share Attack</keyword>
<keyword>SDP</keyword>
<abstract> <keyword>DTLS-SRTP</keyword>
<keyword>WebRTC</keyword>
<t>This document describes unknown key-share attacks on the use of Datagram <keyword>SIP identity</keyword>
Transport Layer Security for the Secure Real-Time Transport Protocol <abstract pn="section-abstract">
(DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the <t indent="0" pn="section-abstract-1">This document describes unknown key-
identity bindings used in Web Real-Time Communications (WebRTC) and SIP share attacks on the use of
identity. These attacks are difficult to mount, but they cause a victim to be Datagram Transport Layer Security for the Secure Real-Time Transport
mislead about the identity of a communicating peer. Mitigation techniques are Protocol (DTLS-SRTP). Similar attacks are described on the use of
defined that implementations of RFC 8122 are encouraged to deploy.</t> DTLS-SRTP with the identity bindings used in Web Real-Time
Communications (WebRTC) and SIP identity. These attacks are difficult
to mount, but they cause a victim to be misled about the identity of a
communicating peer. This document defines mitigation techniques that
implementations of RFC 8122 are encouraged to deploy.</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="include" removeInRFC="fa
<section anchor="introduction" title="Introduction"> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t>The use of Transport Layer Security (TLS) <xref target="TLS13"/> with the Ses <t indent="0" pn="section-1-1">The use of Transport Layer Security (TLS) <
sion xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS13"
Description Protocol (SDP) <xref target="SDP"/> is defined in /> with the Session Description Protocol (SDP) <xref target="RFC4566" format="de
<xref target="FINGERPRINT"/>. Further use with Datagram Transport Layer Securit fault" sectionFormat="of" derivedContent="SDP"/> is defined in <xref target="RFC
y 8122" format="default" sectionFormat="of" derivedContent="FINGERPRINT"/>. Furth
(DTLS) <xref target="DTLS"/> and the Secure Real-time Transport Protocol (SRTP) er use with Datagram Transport Layer Security
<xref target="SRTP"/> is defined as DTLS-SRTP <xref target="DTLS-SRTP"/>.</t> (DTLS) <xref target="RFC6347" format="default" sectionFormat="of" derivedC
ontent="DTLS"/> and the Secure
<t>In these specifications, key agreement is performed using TLS or DTLS, 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 Section 7 of <xref target="WEBRTC-SEC"/>) sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor
and SIP identity <xref target="SIP-ID"/> both provide a mechanism that binds an .org/rfc/rfc8827#section-7" derivedContent="WEBRTC-SEC"/>)
and SIP identity <xref target="RFC8224" format="default" sectionFormat="of" deri
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 therefore vulnerable to an However, this binding is not integrity protected and is therefore vulnerable to
identity misbinding attack - or unknown key-share (UKS) attack - where the an
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 indent="0" pn="section-1-4">This document describes a TLS extension tha
<t>This document describes a TLS extension that can be used in combination with 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 alone. f certificate fingerprints alone.
Though attacks in this setting are likely infeasible in existing deployments due Though attacks in this setting are likely infeasible in existing
to the narrow conditions necessary (see <xref target="limits"/>), this document deployments due to the narrow preconditions
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 indent="0" pn="section-1-6">The mechanisms defined in this document are
<t>The mechanisms defined in this document are intended to strengthen the protoc intended to strengthen the protocol
ol by preventing the use of unknown key-share attacks in combination with other pro
by preventing the use of unknown key shares in combination with other protocol tocol
or implementation vulnerabilities. RFC 8122 <xref target="FINGERPRINT"/> is upd or implementation vulnerabilities. RFC 8122 <xref target="RFC8122" format="defa
ated by this 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 indent="0" pn="section-1-7">This document assumes that signaling is int
<t>This document assumes that signaling is integrity protected. However, as egrity protected. However, as
Section 7 of <xref target="FINGERPRINT"/> explains, many deployments that use SD <xref target="RFC8122" sectionFormat="of" section="7" format="default" derivedLi
P 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="FINGERPRINT"/> offers key continuity mechanisms as a potential mea ns 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"/> provides some analysis of the effect of key continui ty 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 indent="0" pn="section-1-8">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
xref target="RFC8174"/> OT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
</section> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
<section anchor="uks" title="Unknown Key-Share Attack"> f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
<t>In an unknown key-share attack <xref target="UKS"/>, a malicious participant when, and only when, they appear in all capitals, as shown here.
in a protocol </t>
</section>
<section anchor="uks" numbered="true" toc="include" removeInRFC="false" pn="
section-2">
<name slugifiedName="name-unknown-key-share-attack">Unknown Key-Share Atta
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 indent="0" pn="section-2-2">An endpoint that can acquire the certificat
<t>An endpoint that can acquire the certificate fingerprint of another entity ca e fingerprint of another entity can
n advertise that fingerprint as their own in SDP.
advertise that fingerprint as their own in SDP. An attacker can use a copy of An attacker can use a copy of that fingerprint to cause a victim to
that fingerprint to cause a victim to communicate with another unaware victim, communicate with another unaware victim, even though the first victim believe
even though it believes that it is communicating with the attacker.</t> s
that it is communicating with the attacker.
<t>When the identity of communicating peers is established by higher-layer </t>
signaling constructs, such as those in SIP identity <xref target="SIP-ID"/> or W <t indent="0" pn="section-2-3">When the identity of communicating peers is
ebRTC established by higher-layer
<xref target="WEBRTC-SEC"/>, this allows an attacker to bind their own identity signaling constructs, such as those in SIP identity <xref target="RFC8224" forma
to a session t="default" sectionFormat="of" derivedContent="SIP-ID"/> or WebRTC
<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 indent="0" pn="section-2-4">The attacker obtains an identity assertion
<t>The attacker obtains an identity assertion for an identity it controls, but 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 indent="0" pn="section-2-5">An unknown key-share attack does not result
<t>An unknown key-share attack does not result in the attacker having access to in the attacker having access to any
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 indent="0" pn="section-2-6">A similar attack can be mounted based solel
<t>A similar attack can be mounted based solely on the SDP <spanx style="verb">f y on the SDP <tt>fingerprint</tt> attribute
ingerprint</spanx> attribute <xref target="RFC8122" format="default" sectionFormat="of" derivedContent="FINGE
<xref target="FINGERPRINT"/> without compromising the integrity of the signaling RPRINT"/> without compromising the integrity of the signaling channel.</t>
channel.</t> <t indent="0" pn="section-2-7">This attack is an aspect of SDP-based proto
cols upon which the technique known as
<t>This attack is an aspect of SDP-based protocols that the technique known as third-party call control (3PCC) <xref target="RFC3725" format="default" sectionF
third-party call control (3PCC) <xref target="RFC3725"/> relies on. 3PCC exploi ormat="of" derivedContent="RFC3725"/> relies. 3PCC exploits the
ts 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"/> describes the consequences of the mitigations descr ibed 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="include" removeInRFC="false"
<section anchor="limits" title="Limits on Attack Feasibility"> pn="section-2.1">
<name slugifiedName="name-limits-on-attack-feasibilit">Limits on Attack
<t>The use of TLS with SDP depends on the integrity of session signaling. Assum Feasibility</name>
ing <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" indent="adaptive" start="1" pn="section-2.
<t><list style="numbers"> 1-2">
<t>An attacker can only modify the parts of the session signaling that they ar <li pn="section-2.1-2.1" derivedCounter="1.">An attacker can only modi
e fy the parts of the session signaling that they are
responsible for producing, namely their own offers and answers.</t> responsible for producing, namely their own offers and answers.</li>
<t>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
willing to participate in a session with that peer.</t> ly establish a session with a peer unless they are
</list></t> willing to participate in a session with that peer.</li>
</ol>
<t>The combination of these two constraints make the spectrum of possible attack <t indent="0" pn="section-2.1-3">The combination of these two constraint
s 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"/> 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 indent="0" pn="section-2.1-4">Systems that rely on strong identity bi
<t>Systems that rely on strong identity bindings, such as those defined in ndings, such as those defined in
<xref target="WEBRTC"/> or <xref target="SIP-ID"/>, have a different threat mode <xref target="WEBRTC" format="default" sectionFormat="of" derivedContent="WEBRTC
l, 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 to both observe and modify signaling messages. <xref target="id"/> describ es 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="include" removeInRFC="fa
<section anchor="continuity" title="Interactions with Key Continuity"> lse" pn="section-2.2">
<name slugifiedName="name-interactions-with-key-conti">Interactions with
<t>Systems that use key continuity (as defined in Section 15.1 of <xref target=" Key Continuity</name>
ZRTP"/> <t indent="0" pn="section-2.2-1">Systems that use key continuity (as def
or as recommended in Section 7 of <xref target="FINGERPRINT"/>) might be able to ined in
detect an <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 indent="0" pn="section-2.2-2">Implementations that maintain a single
<t>Implementations that maintain a single database of identities with an index o database of identities with an index of
n
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 indent="0" pn="section-2.2-3">In comparison, implementations that fir
<t>In comparison, implementations that first match based on peer identity could 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="include" removeInRFC="f
<section anchor="byebye-3pcc" title="Third-Party Call Control"> 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"/> is a technique where trol</name>
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 attack.</t> correctly distinguish actions of a 3PCC controller from an attack.</t>
<t indent="0" pn="section-2.3-2">3PCC as described in RFC 3725 is incomp
<t>3PCC as described in RFC 3725 is incompatible with SIP identity <xref target= atible with SIP identity <xref target="RFC8224" format="default" sectionFormat="
"SIP-ID"/> as 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 <spanx style="verb">fingerprin Therefore, in a 3PCC context, only the use of the <tt>fingerprint</tt> attribute
t</spanx> attribute without additional bindings or WebRTC identity <xref target="RFC8827" format="de
without additional bindings or WebRTC identity <xref target="WEBRTC-SEC"/> is po fault" sectionFormat="of" derivedContent="WEBRTC-SEC"/> is possible.</t>
ssible.</t> <t indent="0" pn="section-2.3-3">The attack mitigation mechanisms descri
bed in this document will prevent the use
<t>The attack mitigation mechanisms described in this document will prevent the of 3PCC if peers have different views of the involved identities or the value
use of SDP <tt>tls-id</tt> attributes.</t>
of 3PCC if peers have different views of the involved identities, or the value <t indent="0" pn="section-2.3-4">For 3PCC to work with the proposed mech
of SDP <spanx style="verb">tls-id</spanx> attributes.</t> anisms, TLS peers need to be aware of the
<t>For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of
the
signaling so that they can correctly generate and check the TLS extensions. For signaling so that they can correctly generate and check the TLS extensions. For
a connection to be successfully established, a 3PCC controller needs to either a connection to be successfully established, a 3PCC controller needs either to
forward SDP without modification, or to avoid modifications to <spanx style="ver forward SDP without modification or to avoid modifications to <tt>fingerprint</t
b">fingerprint</spanx>, t>,
<spanx style="verb">tls-id</spanx>, and <spanx style="verb">identity</spanx> att <tt>tls-id</tt>, and <tt>identity</tt> attributes. A controller that follows th
ributes. A controller that follows the best 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="include" removeInRFC="false" pn="s
<section anchor="id" title="Unknown Key-Share with Identity Bindings"> ection-3">
<name slugifiedName="name-unknown-key-share-attack-wi">Unknown Key-Share A
<t>The identity assertions used for WebRTC (Section 7 of <xref target="WEBRTC-SE ttack with Identity Bindings</name>
C"/>) and the <t indent="0" pn="section-3-1">The identity assertions used for WebRTC
SIP PASSPoRT used in SIP identity (<xref target="SIP-ID"/>, <xref target="PASSPo (<xref target="RFC8827" sectionFormat="of" section="7" format="default" derivedL
RT"/>) 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 indent="0" pn="section-3-2">An attacker can thereby cause a second vict
<t>An attacker can thereby cause a second victim to believe that they are 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 indent="0" pn="section-3-3">A variation on the same technique can be us
<t>A variation on the same technique can be used to cause both victims to both 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 indent="0" pn="section-3-4">The authority certifying the identity bindi
<t>The problem might appear to be caused by the fact that the authority that ng is not required to
certifies the identity binding is not required to verify that the entity verify that the entity requesting the binding actually controls the
requesting the binding controls the keys associated with the fingerprints. keys associated with the fingerprints, and this might appear to be
SIP and WebRTC identity providers are not required to perform this the cause of the problem. SIP and WebRTC identity providers are not
validation. However, validation of keys by the identity provider is not required to perform this validation.</t>
relevant because verifying control of the associated keys is not a necessary <t indent="0" pn="section-3-5">A simple solution to this problem is sugges
condition for a secure protocol, nor would it be sufficient to prevent attack ted by <xref target="SIGMA" format="default" sectionFormat="of" derivedContent="
<xref target="SIGMA"/>.</t> SIGMA"/>. The identity of
<t>A simple solution to this problem is suggested by <xref target="SIGMA"/>. Th
e 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 indent="0" pn="section-3-6">Rather than include a complete identity bin
<t>Rather than include a complete identity binding - which could be ding, which could be
sizeable - a collision- and pre-image-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"/>. Endpoints in a TLS extension as described in <xref target="external_id_hash" format="defau
then need 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 indent="0" pn="section-3-7">This form of unknown key-share attack is po
<t>This form of unknown key-share attack is possible without compromising signal ssible without compromising signaling
ing integrity, unless the defenses described in <xref target="fp" format="default" s
integrity, unless the defenses described in <xref target="fp"/> are used. In or ectionFormat="of" derivedContent="Section 4"/> are used. In order to
der to prevent both forms of attack, endpoints <bcp14>MUST</bcp14> use the <tt>external
prevent both forms of attack, endpoints MUST use the <spanx style="verb">externa _session_id</tt>
l_session_id</spanx> extension (see <xref target="external_session_id" format="default" sectionFormat
extension (see <xref target="external_session_id"/>) in addition to the <spanx s ="of" derivedContent="Section 4.3"/>) in addition to the <tt>external_id_hash</t
tyle="verb">external_id_hash</spanx> t>
(<xref target="external_id_hash"/>) so that two calls between the same parties c (<xref target="external_id_hash" format="default" sectionFormat="of" derivedCont
an’t be 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="include" removeInRFC="fa
<section anchor="id-example" title="Example"> lse" pn="section-3.1">
<name slugifiedName="name-example">Example</name>
<t>In the example shown in <xref target="identity-attack"/>, it is assumed that <t indent="0" pn="section-3.1-1">In the example shown in <xref target="i
the attacker 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 indent="0" pn="section-3.1-2">Mallory (the attacker) presents two vic
<t>Mallory (the attacker) presents two victims, Norma and Patsy, with two separa tims, Norma and Patsy, with two separate
te
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" align="left" suppress-title="false" pn=
<figure title="Example Attack on Identity Bindings" anchor="identity-attack"><ar "figure-1">
twork><![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></figure> </artwork>
</figure>
<t>The attack requires that Mallory obtain an identity binding for her own ident <t indent="0" pn="section-3.1-4">The attack requires that Mallory obtain
ity 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 the previously. This false binding is then presented to Norma ('Signaling1' in
figure).</t> <xref target="identity-attack" format="default" sectionFormat="of" derivedConten
t="Figure 1"/>).</t>
<t>Patsy could be similarly duped, but in this example, a correct binding betwee <t indent="0" pn="section-3.1-5">Patsy could be similarly duped, but in
n 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 the figure) can be entirely legitimate.</t> session ('Signaling2' in <xref target="identity-attack" format="default" section
Format="of" derivedContent="Figure 1"/>) can be entirely legitimate.</t>
<t>A DTLS session is established directly between Norma and Patsy. In order for <t indent="0" pn="section-3.1-6">A DTLS session is established directly
this to happen Mallory can substitute transport-level information in both between Norma and Patsy.
sessions to facilitate this, though this is not necessary if Mallory is on the In order for this to happen, Mallory can substitute transport-level
network path between Norma and Patsy.</t> information in both sessions, though this is not necessary if Mallory
is on the network path between Norma and Patsy.
<t>As a result, Patsy correctly believes that she is communicating with Norma. </t>
However, Norma incorrectly believes she is talking to Mallory. As stated in <t indent="0" pn="section-3.1-7">As a result, Patsy correctly believes t
<xref target="uks"/>, Mallory cannot access media, but Norma might send informat hat she is communicating with Norma.
ion to Patsy However, Norma incorrectly believes that she is talking to Mallory. As stated i
that is Norma might not intend or that Patsy might misinterpret.</t> n
<xref target="uks" format="default" sectionFormat="of" derivedContent="Section 2
</section> "/>, Mallory cannot access media, but Norma might send information to Patsy
<section anchor="external_id_hash" title="The external_id_hash TLS Extension"> that Norma might not intend or that Patsy might misinterpret.</t>
</section>
<t>The <spanx style="verb">external_id_hash</spanx> TLS extension carries a hash <section anchor="external_id_hash" numbered="true" toc="include" removeInR
of the identity assertion FC="false" pn="section-3.2">
<name slugifiedName="name-the-external_id_hash-tls-ex">The <tt>external_
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 indent="0" pn="section-3.2-2">The <tt>extension_data</tt> for the <tt
<t>The <spanx style="verb">extension_data</spanx> for the <spanx style="verb">ex >external_id_hash</tt> extension contains a
ternal_id_hash</spanx> extension contains a <tt>ExternalIdentityHash</tt> struct, described below using the syntax defined i
<spanx style="verb">ExternalIdentityHash</spanx> struct, described below using t n
he syntax defined in <xref target="RFC8446" sectionFormat="of" section="3" format="default" derivedLi
Section 3 of <xref target="TLS13"/>:</t> nk="https://rfc-editor.org/rfc/rfc8446#section-3" derivedContent="TLS13"/>:</t>
<sourcecode type="tls-presentation" markers="false" pn="section-3.2-3">
<figure><artwork><![CDATA[
struct { struct {
opaque binding_hash<0..32&gt;; opaque binding_hash<0..32&gt;;
} ExternalIdentityHash; } ExternalIdentityHash;
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-3.2-4">Where an identity assertion has been as
<t>Where an identity assertion has been asserted by a peer, this extension inclu serted by a peer, this extension includes
des a SHA-⁠256 hash of the assertion. An empty value is used to indicate support fo
a SHA-256 hash of the assertion. An empty value is used to indicate support for r
the extension.</t> the extension.</t>
<dl newline="false" spacing="normal" indent="3" pn="section-3.2-5">
<t><list style="hanging"> <dt pn="section-3.2-5.1">Note:</dt>
<t hangText='Note:'> <dd pn="section-3.2-5.2">
For both types of identity assertion, if SHA-256 should prove to be inadequate For both types of identity assertion, if SHA-⁠256 should prove to be inadequat
at some point in the future (see <xref target="AGILITY"/>), a new TLS extension e
can be defined that uses a different hash function.</t> in the future (see <xref target="RFC7696" format="default" sectionFormat="of" de
</list></t> rivedContent="AGILITY"/>), a new TLS extension
that uses a different hash function can be defined.</dd>
<t>Identity bindings might be provided by only one peer. An endpoint that does </dl>
not <t indent="0" pn="section-3.2-6">Identity bindings might be provided by
produce an identity binding MUST generate an empty <spanx style="verb">external_ only one peer. An endpoint that does not
id_hash</spanx> extension produce an identity binding <bcp14>MUST</bcp14> generate an empty <tt>external_i
in its ClientHello or - if a client provides the extension - in ServerHello or d_hash</tt> extension
EncryptedExtensions. An empty extension has a zero-length binding_hash field.</ in its ClientHello or -- if a client provides the extension -- in ServerHello or
t> EncryptedExtensions. An empty extension has a zero-length <tt>binding_hash</tt>
field.</t>
<t>A peer that receives an <spanx style="verb">external_id_hash</spanx> extensio <t indent="0" pn="section-3.2-7">A peer that receives an <tt>external_id
n that does not match the _hash</tt> extension that does not match the
value of the identity binding from its peer MUST immediately fail the TLS value of the identity binding from its peer <bcp14>MUST</bcp14> immediately fail
handshake with a illegal_parameter alert. The absence of an identity binding the TLS
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 MUST be present to be considered valid.</t> zero-length extension <bcp14>MUST</bcp14> be present to be considered valid.</t>
<t indent="0" pn="section-3.2-8">Implementations written prior to the de
<t>Implementations written prior to the definition of the extensions in this 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 <spanx style="verb">external_id_hash</s panx> extension MAY 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>Any validation performed of the <spanx style="verb">external_id_hash</spanx> The endpoint performs the validation of the <tt>external_id_hash</tt> extensi
extension is done in addition on
to the validation required by <xref target="FINGERPRINT"/> and any identity asse in addition to the validation required by <xref target="RFC8122" format="defa
rtion ult" sectionFormat="of" derivedContent="FINGERPRINT"/> and any verification
definition.</t> of the identity assertion <xref target="RFC8827" format="default" sectionForm
at="of" derivedContent="WEBRTC-SEC"/> <xref target="RFC8224" format="default" se
<t>An <spanx style="verb">external_id_hash</spanx> extension that is any length ctionFormat="of" derivedContent="SIP-ID"/>.
other than 0 or 32 is invalid An endpoint <bcp14>MUST</bcp14> validate any external_session_id value that i
and MUST cause the receiving endpoint to generate a fatal <spanx style="verb">de s present; see <xref target="external_session_id" format="default" sectionFormat
code_error</spanx> alert.</t> ="of" derivedContent="Section 4.3"/>.
</t>
<t>In TLS 1.3, an <spanx style="verb">external_id_hash</spanx> extension sent by <t indent="0" pn="section-3.2-10">An <tt>external_id_hash</tt> extension
a server MUST be sent in the with a <tt>binding_hash</tt> field
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>
<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" title="Calculat d="true" toc="include" removeInRFC="false" pn="section-3.2.1">
ing external_id_hash for WebRTC Identity"> <name slugifiedName="name-calculating-external_id_has">Calculating <tt
>external_id_hash</tt> for WebRTC Identity</name>
<t>A WebRTC identity assertion (Section 7 of <xref target="WEBRTC-SEC"/>) is pro <t indent="0" pn="section-3.2.1-1">A WebRTC identity assertion
vided as a JSON (<xref target="RFC8827" sectionFormat="of" section="7" format="default" derivedL
<xref target="JSON"/> object that is encoded into a JSON text. The JSON text is ink="https://rfc-editor.org/rfc/rfc8827#section-7" derivedContent="WEBRTC-SEC"/>
encoded using UTF-8 <xref target="UTF8"/> as described by Section 8.1 of <xref t ) is provided as a JSON
arget="JSON"/>. <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="JSON"
The content of the <spanx style="verb">external_id_hash</spanx> extension is pro /> object that is encoded into a JSON text. The JSON text is
duced by hashing the encoded using UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" d
resulting octets with SHA-256 <xref target="SHA"/>. This produces the 32 octets erivedContent="UTF8"/> as described by
of <xref target="RFC8259" sectionFormat="of" section="8.1" format="default" derived
the <spanx style="verb">binding_hash</spanx> parameter, which is the sole conten Link="https://rfc-editor.org/rfc/rfc8259#section-8.1" derivedContent="JSON"/>.
ts of the extension.</t> The content of the <tt>external_id_hash</tt> extension is produced by hashing th
e
<t>The SDP <spanx style="verb">identity</spanx> attribute includes the base64 <x resulting octets with SHA-⁠256 <xref target="RFC6234" format="default" sectionFo
ref target="BASE64"/> encoding of rmat="of" derivedContent="SHA"/>. This produces the 32 octets of
the UTF-8 encoding of the same JSON text. The <spanx style="verb">external_id_h the <tt>binding_hash</tt> parameter, which is the sole contents of the extension
ash</spanx> extension is .</t>
validated by performing base64 decoding on the value of the SDP <spanx style="ve <t indent="0" pn="section-3.2.1-2">The SDP <tt>identity</tt> attribute
rb">identity</spanx> includes the base64 <xref target="RFC4648" format="default" sectionFormat="of"
attribute, hashing the resulting octets using SHA-256, and comparing the results derivedContent="BASE64"/> encoding of
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
>
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
<spanx style="verb">identity-assertion-value</spanx> field from the <spanx style <tt>identity-assertion-value</tt> field from the SDP <tt>identity</tt> attribute
="verb">identity</spanx> attribute grammar as grammar as
defined in <xref target="WEBRTC-SEC"/>:</t> defined in <xref target="RFC8827" format="default" sectionFormat="of" derivedCon
tent="WEBRTC-SEC"/>:</t>
<t><spanx style="verb"> <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))
</spanx></t> </sourcecode>
<dl newline="false" spacing="normal" indent="3" pn="section-3.2.1-4">
<t><list style="hanging"> <dt pn="section-3.2.1-4.1">Note:</dt>
<t hangText='Note:'> <dd pn="section-3.2.1-4.2">
The base64 of the SDP <spanx style="verb">identity</spanx> attribute is decode The base64 of the SDP <tt>identity</tt> attribute is decoded to avoid capturin
d to avoid capturing 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.</t> canonicalized; all octets are hashed.</dd>
</list></t> </dl>
</section>
</section> <section anchor="calculating-externalidhash-for-passport" numbered="true
<section anchor="calculating-externalidhash-for-passport" title="Calculating ext " toc="include" removeInRFC="false" pn="section-3.2.2">
ernal_id_hash for PASSPoRT"> <name slugifiedName="name-calculating-external_id_hash">Calculating ex
ternal_id_hash for PASSporT</name>
<t>Where the compact form of PASSPoRT <xref target="PASSPoRT"/> is used, it MUST <t indent="0" pn="section-3.2.2-1">Where the compact form of PASSporT
be expanded <xref target="RFC8225" format="default" sectionFormat="of" derivedContent="PASSP
into the full form. The base64 encoding used in the SIP Identity (or ‘y’) ORT"/>
header field MUST be decoded then used as input to SHA-256. This produces the is used, it <bcp14>MUST</bcp14> be expanded
32 octet <spanx style="verb">binding_hash</spanx> value used for creating or val into the full form. The base64 encoding used in the SIP Identity (or 'y')
idating the extension. In header field <bcp14>MUST</bcp14> be decoded then used as input to SHA-⁠256. Thi
pseudocode, using the <spanx style="verb">signed-identity-digest</spanx> field f s produces the
rom the <spanx style="verb">Identity</spanx> grammar 32-octet <tt>binding_hash</tt> value used for creating or validating the extensi
defined <xref target="SIP-ID"/>:</t> on. In
pseudocode, using the <tt>signed-identity-digest</tt> parameter from the <tt>Ide
<t><spanx style="verb"> ntity</tt> header field grammar
defined <xref target="RFC8224" format="default" sectionFormat="of" derivedConten
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))
</spanx></t> </sourcecode>
</section>
</section> </section>
</section> </section>
</section> <section anchor="fp" numbered="true" toc="include" removeInRFC="false" pn="s
<section anchor="fp" title="Unknown Key-Share with Fingerprints"> ection-4">
<name slugifiedName="name-unknown-key-share-attack-wit">Unknown Key-Share
<t>An attack on DTLS-SRTP is possible because the identity of peers involved is Attack with Fingerprints</name>
not <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 indent="0" pn="section-4-2">Even if the integrity of session signaling
<t>Even if the integrity of session signaling can be relied upon, an attacker mi can be relied upon, an attacker might
ght
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 indent="0" pn="section-4-3">An endpoint that is configured to reuse a c
<t>An endpoint that is configured to reuse a certificate can be attacked if it i ertificate can be attacked if it is
s
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 indent="0" pn="section-4-4">As with the attack on identity bindings, th
<t>As with the attack on identity bindings, this can be used to cause two victim is can be used to cause two victims
s
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="include" removeInRFC="fa
<section anchor="fp-example" title="Example"> lse" pn="section-4.1">
<name slugifiedName="name-example-2">Example</name>
<t>To mount this attack, two sessions need to be created with the same endpoint <t indent="0" pn="section-4.1-1">To mount this attack, two sessions need
at 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 indent="0" pn="section-4.1-2">In addition to the constraints describe
<t>In addition to the constraints described in <xref target="limits"/>, the atta d in <xref target="limits" format="default" sectionFormat="of" derivedContent="S
cker in this 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 is on-path for media.</t> That is, the attacker needs to be on path for media.</t>
<t indent="0" pn="section-4.1-3">The attack shown in <xref target="impla
<t>The attack shown in <xref target="implausible-attack"/> depends on a somewhat usible-attack" format="default" sectionFormat="of" derivedContent="Figure 2"/> d
implausible set 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" align="left" suppress-title="false"
<figure title="Example Attack Scenario using Fingerprints" anchor="implausible-a pn="figure-2">
ttack"><artwork><![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></figure> </artwork>
</figure>
<t>In this scenario, there are two sessions initiated at the same time by Norma. <t indent="0" pn="section-4.1-5">In this scenario, there are two session
Signaling is shown with single lines (‘-‘), DTLS and media with double lines s initiated at the same time by Norma.
(‘=’).</t> Signaling is shown with single lines ('-'), DTLS and media with double lines
('=').</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
certificate fingerprint (denoted with ‘fp=P’). A second session is initiated allory, who falsely uses Patsy's
certificate fingerprint (denoted with 'fp=P'). A second session is initiated
between Norma and Patsy. Signaling for both sessions is permitted to complete.< /t> between Norma and Patsy. Signaling for both sessions is permitted to complete.< /t>
<t indent="0" pn="section-4.1-7">Once signaling is complete on the first
<t>Once signaling is complete on the first session, a DTLS connection is 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 indent="0" pn="section-4.1-8">Mallory also intercepts packets from Pa
<t>Mallory also intercepts packets from Patsy and forwards those to Norma at the 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 indent="0" pn="section-4.1-9">The second signaling exchange ('Signali
<t>The second signaling exchange - ‘signaling2’, between Norma and Patsy - is 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"/>, communicating with Patsy. Just like the example in <xref target="id-example" fo
Mallory rmat="default" sectionFormat="of" derivedContent="Section 3.1"/>, Mallory
cannot access media, but Norma might send information to Patsy that is 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 indent="0" pn="section-4.1-10">Though Patsy needs to believe that the
<t>Though Patsy needs to believe that the second signaling session has been 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 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 indent="0" pn="section-4.1-11">For the attacked session to be sustain
<t>For the attacked session to be sustained beyond the point that Norma detects 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 is 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 peers. e beliefs about the identity of 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
SDP <spanx style="verb">fingerprint</spanx> attribute value - is used by Norma f the SDP <tt>fingerprint</tt> attribute value -- is used by Norma for both sessio
or both sessions.</t> ns.</t>
<t indent="0" pn="section-4.1-13">Where Interactive Connectivity Establi
<t>Where ICE <xref target="ICE"/> is used, Mallory also needs to ensure that shment (ICE) <xref target="RFC8445" format="default" sectionFormat="of" derivedC
ontent="ICE"/>
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 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="include" removeInRFC="false
<section anchor="sess-id" title="Unique Session Identity Solution"> " pn="section-4.2">
<name slugifiedName="name-unique-session-identity-sol">Unique Session Id
<t>The solution to this problem is to assign a new identifier to communicating 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"/>).</t> authenticate it (see <xref target="SIGMA" format="default" sectionFormat="of" de
rivedContent="SIGMA"/>).</t>
<t>Successful validation that the identifier matches the expected value means th <t indent="0" pn="section-4.2-2">Successfully validating that the identi
at 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 indent="0" pn="section-4.2-3">This solution relies on the unique iden
<t>This solution relies on the unique identifier given to DTLS sessions using th tifier given to DTLS sessions using the
e SDP <tt>tls-id</tt> attribute <xref target="RFC8842" format="default" sectionFor
SDP <spanx style="verb">tls-id</spanx> attribute <xref target="DTLS-SDP"/>. Thi mat="of" derivedContent="DTLS-SDP"/>. This field is
s 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 indent="0" pn="section-4.2-4">A new <tt>external_session_id</tt> exte
<t>A new <spanx style="verb">external_session_id</spanx> extension is added to t nsion is added to the TLS or DTLS handshake for
he 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 <spanx style="verb">tls-id</spanx> attribute and p rovides 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="include" remove
<section anchor="external_session_id" title="The external_session_id TLS Extensi InRFC="false" pn="section-4.3">
on"> <name slugifiedName="name-the-external_session_id-tls">The external_sess
ion_id TLS Extension</name>
<t>The <spanx style="verb">external_session_id</spanx> TLS extension carries the <t indent="0" pn="section-4.3-1">The <tt>external_session_id</tt> TLS ex
unique identifier that an tension carries the unique identifier that an
endpoint selects. When used with SDP, the value MUST include the <spanx style=" endpoint selects. When used with SDP, the value <bcp14>MUST</bcp14> include the
verb">tls-id</spanx> <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 indent="0" pn="section-4.3-2">The <tt>extension_data</tt> for the <tt
<t>The <spanx style="verb">extension_data</spanx> for the <spanx style="verb">ex >external_session_id</tt> extension contains an
ternal_session_id</spanx> extension contains an
ExternalSessionId struct, described below using the syntax defined in ExternalSessionId struct, described below using the syntax defined in
<xref target="TLS13"/>:</t> <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS13
"/>:</t>
<figure><artwork><![CDATA[ <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;
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-4.3-4">For SDP, the <tt>session_id</tt> field
<t>For SDP, the <spanx style="verb">session_id</spanx> field of the extension in of the extension includes the value of the
cludes the value of the <tt>tls-id</tt> SDP attribute as defined in <xref target="RFC8842" format="defau
<spanx style="verb">tls-id</spanx> SDP attribute as defined in <xref target="DTL lt" sectionFormat="of" derivedContent="DTLS-SDP"/>
S-SDP"/> (that is, the <tt>tls-id-value</tt> ABNF production). The value of the <tt>tls-
(that is, the <spanx style="verb">tls-id-value</spanx> ABNF production). The va id</tt>
lue of the <spanx style="verb">tls-id</spanx> attribute is encoded using ASCII <xref target="RFC0020" format="default" section
attribute is encoded using ASCII <xref target="ASCII"/>.</t> Format="of" derivedContent="ASCII"/>.</t>
<t indent="0" pn="section-4.3-5">Where RTP and RTCP <xref target="RFC355
<t>Where RTP and RTCP <xref target="RTP"/> are not multiplexed, it is possible t 0" format="default" sectionFormat="of" derivedContent="RTP"/> are not multiplexe
hat the 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="SRTP"/> provides key separation. Using RTP/RTCP multiplexing SRTP <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="
<xref target="RTCP-MUX"/> further avoids this problem.</t> SRTP"/> provides key separation. Using RTP/RTCP multiplexing
<xref target="RFC5761" format="default" sectionFormat="of" derivedContent="RTCP-
<t>The <spanx style="verb">external_session_id</spanx> extension is included in MUX"/> further avoids this problem.</t>
a ClientHello and - if the <t indent="0" pn="section-4.3-6">The <tt>external_session_id</tt> extens
extension is present in the ClientHello - either ServerHello (for TLS and DTLS ion is included in a ClientHello, and if the
versions less than 1.3) or EncryptedExtensions (for TLS 1.3).</t> extension is present in the ClientHello, either ServerHello (for TLS and DTLS
versions older than 1.3) or EncryptedExtensions (for TLS 1.3).</t>
<t>Endpoints MUST check that the <spanx style="verb">session_id</spanx> paramete <t indent="0" pn="section-4.3-7">Endpoints <bcp14>MUST</bcp14> check tha
r in the extension that they t the <tt>session_id</tt> parameter in the extension that they
receive includes the <spanx style="verb">tls-id</spanx> attribute value that the receive includes the <tt>tls-id</tt> attribute value that they received in their
y received in their peer’s 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 compare 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 a <spanx style="verb">external_session_id</spanx> extensi endpoint that receives an <tt>external_session_id</tt> extension that is not ide
on that is not identical ntical
to the value that it expects MUST abort the connection with a fatal to the value that it expects <bcp14>MUST</bcp14> abort the connection with a fat
<spanx style="verb">illegal_parameter</spanx> alert.</t> al
<tt>illegal_parameter</tt> alert.</t>
<t>Any validation performed of the <spanx style="verb">external_session_id</span <t indent="0" pn="section-4.3-8">
x> extension is done in The endpoint performs the validation of the <tt>external_id_hash</tt> extensi
addition to the validation required by <xref target="FINGERPRINT"/>.</t> on in
addition to the validation required by <xref target="RFC8122" format="default
<t>An endpoint that is communicating with a peer that does not support this " sectionFormat="of" derivedContent="FINGERPRINT"/>.
extension will receive a ClientHello, ServerHello or EncryptedExtensions that </t>
does not include this extension. An endpoint MAY choose to continue a session <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
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 indent="0" pn="section-4.3-10">In TLS 1.3, an <tt>external_session_id
<t>In TLS 1.3, an <spanx style="verb">external_session_id</spanx> extension sent </tt> extension sent by a server <bcp14>MUST</bcp14> be sent in
by a server MUST be sent in
the EncryptedExtensions message.</t> the EncryptedExtensions message.</t>
<t indent="0" pn="section-4.3-11">This defense is not effective if an at
<t>This defense is not effective if an attacker can rewrite <spanx style="verb"> tacker can rewrite <tt>tls-id</tt> values in
tls-id</spanx> values in signaling. Only the mechanism in <tt>external_id_hash</tt> is able to defend ag
signaling. Only the mechanism in <spanx style="verb">external_id_hash</spanx> i ainst
s able to defend against
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="include" removeInRFC="false" p
<section anchor="concat" title="Session Concatenation"> n="section-5">
<name slugifiedName="name-session-concatenation">Session Concatenation</na
<t>Use of session identifiers does not prevent an attacker from establishing two me>
concurrent sessions with different peers and forwarding signaling from those <t indent="0" pn="section-5-1">Use of session identifiers does not prevent
peers to each other. Concatenating two signaling sessions in this way creates an attacker from
two signaling sessions, with two session identifiers, but only the TLS establishing two concurrent sessions with different peers and
connections from a single session are established as a result. In doing so, the forwarding signaling from those peers to each other. Concatenating
attacker creates a situation where both peers believe that they are talking to two signaling sessions in this way creates two signaling sessions,
the attacker when they are talking to each other.</t> with two session identifiers, but only the TLS connections from a
single session are established as a result. In doing so, the
<t>In the absence of any higher-level concept of peer identity, the use of sessi attacker creates a situation where both peers believe that they are
on talking to the attacker when they are talking to each other.</t>
identifiers does not prevent session concatenation if the attacker is able to <t indent="0" pn="section-5-2">In the absence of any higher-level concept
copy the session identifier from one signaling session to another. This kind of of peer identity, an
attack is prevented by systems that enable peer authentication such as WebRTC attacker who is able to copy the session identifier from
identity <xref target="WEBRTC-SEC"/> or SIP identity <xref target="SIP-ID"/>. H one signaling session to another can cause the peers to establish a
owever, session direct TLS connection even while they think that they are connecting
concatenation remains possible at higher layers: an attacker can establish two to the attacker. This differs from the attack described in the
independent sessions and simply forward any data it receives from one into the previous section in that there is only one TLS connection rather than
other.</t> two. This kind of attack is prevented by systems that enable peer
authentication, such as WebRTC identity <xref target="RFC8827" format="default"
<t>Use of the <spanx style="verb">external_session_id</spanx> does not guarantee sectionFormat="of" derivedContent="WEBRTC-SEC"/> or SIP identity
that the identity of the <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="SIP-I
D"/>; however, these systems do not prevent establishing
two back-to-back connections as described in the previous paragraph.</t>
<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 an attacker gains by concatenating sessions is limited unless data is advantage that an attacker gains by concatenating sessions is limited unless dat
exchanged on the assumption that signaling and TLS peers are the same. If a a is
exchanged based on the assumption that signaling and TLS peers are the same. If
a
secondary protocol uses the signaling channel with the assumption that the 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
A signaling system that can defend against session concatenation, while out of .
scope for this document, requires that the signaling layer is authenticated and While out of scope for this document, a signaling system that can defend against
bound to any TLS connections.</t> session concatenation
requires that the signaling layer is authenticated and bound to any TLS connecti
<t>It is important to note that multiple connections can be created within the s ons.</t>
ame <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 indent="0" pn="section-5-5">Critically, information about the identity
<t>Critically, information about the identity of TLS peers provides no assurance of TLS peers provides no assurances
s about the identity of signaling peers and does not transfer between TLS
about the identity of signaling peers and do 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 MUST NOT be used in a secondary protocol outside of that 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 MUST NOT 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="include" remo
<section anchor="security-considerations" title="Security Considerations"> veInRFC="false" pn="section-6">
<name slugifiedName="name-security-considerations">Security Considerations
<t>The mitigations in this document, when combined with identity assertions, ens </name>
ure <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 the s in this document prevent the
session splicing attack described in <xref target="fp"/>. Defense against sessi session splicing attack described in <xref target="fp" format="default" sectionF
on ormat="of" derivedContent="Section 4"/>. Defense against session
concatenation (<xref target="concat"/>) additionally requires protocol peers are concatenation (<xref target="concat" format="default" sectionFormat="of" derived
not able to Content="Section 5"/>) additionally requires that 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" title="IANA Considerations"> RFC="false" pn="section-7">
<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
registry established in <xref target="TLS13"/>:</t> he "TLS ExtensionType Values"
registry established in <xref target="RFC8446" format="default" sectionFormat="o
<t><list style="symbols"> f" derivedContent="TLS13"/>:</t>
<t>The <spanx style="verb">external_id_hash</spanx> extension defined in <xref <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-2
target="external_id_hash"/> has been ">
assigned a code point of TBD; it is recommended and is marked as “CH, EE” <li pn="section-7-2.1">The <tt>external_id_hash</tt> extension defined i
in TLS 1.3.</t> n <xref target="external_id_hash" format="default" sectionFormat="of" derivedCon
<t>The <spanx style="verb">external_session_id</spanx> extension defined in <x tent="Section 3.2"/> has been
ref target="external_session_id"/> has assigned a code point of 55; it is recommended and is marked as "CH, EE"
been assigned a code point of TBD; it is recommended and is marked as in TLS 1.3.</li>
“CH, EE” in TLS 1.3.</t> <li pn="section-7-2.2">The <tt>external_session_id</tt> extension define
</list></t> d in <xref target="external_session_id" format="default" sectionFormat="of" deri
vedContent="Section 4.3"/> has
</section> been assigned a code point of 56; it is recommended and is marked as
"CH, EE" in TLS 1.3.</li>
</ul>
</section>
</middle> </middle>
<back> <back>
<displayreference target="RFC0020" to="ASCII"/>
<references title='Normative References'> <displayreference target="RFC3550" to="RTP"/>
<displayreference target="RFC3629" to="UTF8"/>
<reference anchor="TLS13" target='https://www.rfc-editor.org/info/rfc8446'> <displayreference target="RFC3711" to="SRTP"/>
<front> <displayreference target="RFC4566" to="SDP"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <displayreference target="RFC4648" to="BASE64"/>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /> <displayreference target="RFC5761" to="RTCP-MUX"/>
</author> <displayreference target="RFC5763" to="DTLS-SRTP"/>
<date year='2018' month='August' /> <displayreference target="RFC6189" to="ZRTP"/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security <displayreference target="RFC6234" to="SHA"/>
(TLS) protocol. TLS allows client/server applications to communicate over the <displayreference target="RFC6347" to="DTLS"/>
Internet in a way that is designed to prevent eavesdropping, tampering, and mess <displayreference target="RFC7696" to="AGILITY"/>
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs <displayreference target="RFC8122" to="FINGERPRINT"/>
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 <displayreference target="RFC8224" to="SIP-ID"/>
implementations.</t></abstract> <displayreference target="RFC8225" to="PASSPORT"/>
</front> <displayreference target="RFC8259" to="JSON"/>
<seriesInfo name='RFC' value='8446'/> <displayreference target="RFC8445" to="ICE"/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/> <displayreference target="RFC8446" to="TLS13"/>
</reference> <displayreference target="RFC8827" to="WEBRTC-SEC"/>
<displayreference target="RFC8842" to="DTLS-SDP"/>
<reference anchor="SDP" target='https://www.rfc-editor.org/info/rfc4566'> <references pn="section-8">
<front> <name slugifiedName="name-references">References</name>
<title>SDP: Session Description Protocol</title> <references pn="section-8.1">
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></ <name slugifiedName="name-normative-references">Normative References</na
author> me>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /> <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc2
</author> 0" quoteTitle="true" derivedAnchor="ASCII">
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></ <front>
author> <title>ASCII format for network interchange</title>
<date year='2006' month='July' /> <author initials="V.G." surname="Cerf" fullname="V.G. Cerf">
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is i <organization showOnFrontPage="true"/>
ntended for describing multimedia sessions for the purposes of session announcem </author>
ent, session invitation, and other forms of multimedia session initiation. [STA <date year="1969" month="October"/>
NDARDS-TRACK]</t></abstract> </front>
</front> <seriesInfo name="STD" value="80"/>
<seriesInfo name='RFC' value='4566'/> <seriesInfo name="RFC" value="20"/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/> <seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference> </reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
<reference anchor="FINGERPRINT" target='https://www.rfc-editor.org/info/rfc8122 648" quoteTitle="true" derivedAnchor="BASE64">
'> <front>
<front> <title>The Base16, Base32, and Base64 Data Encodings</title>
<title>Connection-Oriented Media Transport over the Transport Layer Security (TL <author initials="S." surname="Josefsson" fullname="S. Josefsson">
S) Protocol in the Session Description Protocol (SDP)</title> <organization showOnFrontPage="true"/>
<author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></au </author>
thor> <date year="2006" month="October"/>
<author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization /> <abstract>
</author> <t indent="0">This document describes the commonly used base 64, b
<date year='2017' month='March' /> ase 32, and base 16 encoding schemes. It also discusses the use of line-feeds i
<abstract><t>This document specifies how to establish secure connection-oriented n encoded data, use of padding in encoded data, use of non-alphabet characters i
media transport sessions over the Transport Layer Security (TLS) protocol using n encoded data, use of different encoding alphabets, and canonical encodings. [
the Session Description Protocol (SDP). It defines the SDP protocol identifier STANDARDS-TRACK]</t>
, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' </abstract>
attribute that identifies the certificate that will be presented for the TLS ses </front>
sion. This mechanism allows media transport over TLS connections to be establis <seriesInfo name="RFC" value="4648"/>
hed securely, so long as the integrity of session descriptions is assured.</t><t <seriesInfo name="DOI" value="10.17487/RFC4648"/>
>This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprin </reference>
ts.</t></abstract> <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
</front> 347" quoteTitle="true" derivedAnchor="DTLS">
<seriesInfo name='RFC' value='8122'/> <front>
<seriesInfo name='DOI' value='10.17487/RFC8122'/> <title>Datagram Transport Layer Security Version 1.2</title>
</reference> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
<reference anchor="DTLS" target='https://www.rfc-editor.org/info/rfc6347'> </author>
<front> <author initials="N." surname="Modadugu" fullname="N. Modadugu">
<title>Datagram Transport Layer Security Version 1.2</title> <organization showOnFrontPage="true"/>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /> </author>
</author> <date year="2012" month="January"/>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /> <abstract>
</author> <t indent="0">This document specifies version 1.2 of the Datagram
<date year='2012' month='January' /> Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer ions privacy for datagram protocols. The protocol allows client/server applicat
Security (DTLS) protocol. The DTLS protocol provides communications privacy fo ions to communicate in a way that is designed to prevent eavesdropping, tamperin
r datagram protocols. The protocol allows client/server applications to communi g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
cate in a way that is designed to prevent eavesdropping, tampering, or message f ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
orgery. The DTLS protocol is based on the Transport Layer Security (TLS) protoc cs of the underlying transport are preserved by the DTLS protocol. This documen
ol and provides equivalent security guarantees. Datagram semantics of the under t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
lying transport are preserved by the DTLS protocol. This document updates DTLS </abstract>
1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract> </front>
</front> <seriesInfo name="RFC" value="6347"/>
<seriesInfo name='RFC' value='6347'/> <seriesInfo name="DOI" value="10.17487/RFC6347"/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/> </reference>
</reference> <reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8
842" quoteTitle="true" derivedAnchor="DTLS-SDP">
<reference anchor="SRTP" target='https://www.rfc-editor.org/info/rfc3711'> <front>
<front> <title>Session Description Protocol (SDP) Offer/Answer Consideration
<title>The Secure Real-time Transport Protocol (SRTP)</title> s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS
<author initials='M.' surname='Baugher' fullname='M. Baugher'><organization /></ )</title>
author> <author initials="C." surname="Holmberg" fullname="Christer Holmberg
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></au ">
thor> <organization showOnFrontPage="true"/>
<author initials='M.' surname='Naslund' fullname='M. Naslund'><organization /></ </author>
author> <author initials="R." surname="Shpount" fullname="Roman Shpount">
<author initials='E.' surname='Carrara' fullname='E. Carrara'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<author initials='K.' surname='Norrman' fullname='K. Norrman'><organization /></ <date month="January" year="2021"/>
author> </front>
<date year='2004' month='March' /> <seriesInfo name="RFC" value="8842"/>
<abstract><t>This document describes the Secure Real-time Transport Protocol (SR <seriesInfo name="DOI" value="10.17487/RFC8842"/>
TP), a profile of the Real-time Transport Protocol (RTP), which can provide conf </reference>
identiality, message authentication, and replay protection to the RTP traffic an <reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5
d to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP 763" quoteTitle="true" derivedAnchor="DTLS-SRTP">
). [STANDARDS-TRACK]</t></abstract> <front>
</front> <title>Framework for Establishing a Secure Real-time Transport Proto
<seriesInfo name='RFC' value='3711'/> col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
<seriesInfo name='DOI' value='10.17487/RFC3711'/> e>
</reference> <author initials="J." surname="Fischl" fullname="J. Fischl">
<organization showOnFrontPage="true"/>
<reference anchor="DTLS-SRTP" target='https://www.rfc-editor.org/info/rfc5763'> </author>
<front> <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) S <organization showOnFrontPage="true"/>
ecurity Context Using Datagram Transport Layer Security (DTLS)</title> </author>
<author initials='J.' surname='Fischl' fullname='J. Fischl'><organization /></au <author initials="E." surname="Rescorla" fullname="E. Rescorla">
thor> <organization showOnFrontPage="true"/>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio </author>
n /></author> <date year="2010" month="May"/>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /> <abstract>
</author> <t indent="0">This document specifies how to use the Session Initi
<date year='2010' month='May' /> ation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) s
<abstract><t>This document specifies how to use the Session Initiation Protocol ecurity context using the Datagram Transport Layer Security (DTLS) protocol. It
(SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context describes a mechanism of transporting a fingerprint attribute in the Session De
using the Datagram Transport Layer Security (DTLS) protocol. It describes a me scription Protocol (SDP) that identifies the key that will be presented during t
chanism of transporting a fingerprint attribute in the Session Description Proto he DTLS handshake. The key exchange travels along the media path as opposed to
col (SDP) that identifies the key that will be presented during the DTLS handsha the signaling path. The SIP Identity mechanism can be used to protect the integ
ke. The key exchange travels along the media path as opposed to the signaling p rity of the fingerprint attribute from modification by intermediate proxies. [S
ath. The SIP Identity mechanism can be used to protect the integrity of the fin TANDARDS-TRACK]</t>
gerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK] </abstract>
</t></abstract> </front>
</front> <seriesInfo name="RFC" value="5763"/>
<seriesInfo name='RFC' value='5763'/> <seriesInfo name="DOI" value="10.17487/RFC5763"/>
<seriesInfo name='DOI' value='10.17487/RFC5763'/> </reference>
</reference> <reference anchor="RFC8122" target="https://www.rfc-editor.org/info/rfc8
122" quoteTitle="true" derivedAnchor="FINGERPRINT">
<reference anchor="WEBRTC-SEC"> <front>
<front> <title>Connection-Oriented Media Transport over the Transport Layer
<title>WebRTC Security Architecture</title> Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
<date month='July' day='22' year='2019' /> </author>
<date year="2017" month="March"/>
<abstract><t>This document defines the security architecture for WebRTC, a proto <abstract>
col suite intended for use with real-time applications that can be deployed in b <t indent="0">This document specifies how to establish secure conn
rowsers - "real time communication on the Web".</t></abstract> ection-oriented media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines the SDP prot
</front> ocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP
'fingerprint' attribute that identifies the certificate that will be presented
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-20' /> for the TLS session. This mechanism allows media transport over TLS connections
<format type='TXT' to be established securely, so long as the integrity of session descriptions is
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-a assured.</t>
rch-20.txt' /> <t indent="0">This document obsoletes RFC 4572 by clarifying the u
</reference> sage of multiple fingerprints.</t>
</abstract>
<reference anchor="SIP-ID" target='https://www.rfc-editor.org/info/rfc8224'> </front>
<front> <seriesInfo name="RFC" value="8122"/>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP <seriesInfo name="DOI" value="10.17487/RFC8122"/>
)</title> </reference>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
</author> 259" quoteTitle="true" derivedAnchor="JSON">
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /> <front>
</author> <title>The JavaScript Object Notation (JSON) Data Interchange Format
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /> </title>
</author> <author initials="T." surname="Bray" fullname="T. Bray" role="editor
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></auth ">
or> <organization showOnFrontPage="true"/>
<date year='2018' month='February' /> </author>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol <date year="2017" month="December"/>
(SIP) are inadequate for cryptographically assuring the identity of the end use <abstract>
rs that originate SIP requests, especially in an interdomain context. This docu <t indent="0">JavaScript Object Notation (JSON) is a lightweight,
ment defines a mechanism for securely identifying originators of SIP requests. text-based, language-independent data interchange format. It was derived from t
It does so by defining a SIP header field for conveying a signature used for val he ECMAScript Programming Language Standard. JSON defines a small set of format
idating the identity and for conveying a reference to the credentials of the sig ting rules for the portable representation of structured data.</t>
ner.</t><t>This document obsoletes RFC 4474.</t></abstract> <t indent="0">This document removes inconsistencies with other spe
</front> cifications of JSON, repairs specification errors, and offers experience-based i
<seriesInfo name='RFC' value='8224'/> nteroperability guidance.</t>
<seriesInfo name='DOI' value='10.17487/RFC8224'/> </abstract>
</reference> </front>
<seriesInfo name="STD" value="90"/>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <seriesInfo name="RFC" value="8259"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC8259"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> </reference>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <reference anchor="RFC8225" target="https://www.rfc-editor.org/info/rfc8
author> 225" quoteTitle="true" derivedAnchor="PASSPORT">
<date year='1997' month='March' /> <front>
<abstract><t>In many standards track documents several words are used to signify <title>PASSporT: Personal Assertion Token</title>
the requirements in the specification. These words are often capitalized. This <author initials="C." surname="Wendt" fullname="C. Wendt">
document defines these words as they should be interpreted in IETF documents. <organization showOnFrontPage="true"/>
This document specifies an Internet Best Current Practices for the Internet Comm </author>
unity, and requests discussion and suggestions for improvements.</t></abstract> <author initials="J." surname="Peterson" fullname="J. Peterson">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='BCP' value='14'/> </author>
<seriesInfo name='RFC' value='2119'/> <date year="2018" month="February"/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/> <abstract>
</reference> <t indent="0">This document defines a method for creating and vali
dating a token that cryptographically verifies an originating identity or, more
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> generally, a URI or telephone number representing the originator of personal com
<front> munications. The Personal Assertion Token, PASSporT, is cryptographically signe
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> d to protect the integrity of the identity of the originator and to verify the a
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth ssertion of the identity information at the destination. The cryptographic sign
or> ature is defined with the intention that it can confidently verify the originati
<date year='2017' month='May' /> ng persona even when the signature is sent to the destination party over an inse
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s cure channel. PASSporT is particularly useful for many personal-communications
pecifications. This document aims to reduce the ambiguity by clarifying that on applications over IP networks and other multi-hop interconnection scenarios wher
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs e the originating and destination parties may not have a direct trusted relation
tract> ship.</t>
</front> </abstract>
<seriesInfo name='BCP' value='14'/> </front>
<seriesInfo name='RFC' value='8174'/> <seriesInfo name="RFC" value="8225"/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/> <seriesInfo name="DOI" value="10.17487/RFC8225"/>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<reference anchor="PASSPoRT" target='https://www.rfc-editor.org/info/rfc8225'> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>PASSporT: Personal Assertion Token</title> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></auth le>
or> <author initials="S." surname="Bradner" fullname="S. Bradner">
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /> <organization showOnFrontPage="true"/>
</author> </author>
<date year='2018' month='February' /> <date year="1997" month="March"/>
<abstract><t>This document defines a method for creating and validating a token <abstract>
that cryptographically verifies an originating identity or, more generally, a UR <t indent="0">In many standards track documents several words are
I or telephone number representing the originator of personal communications. T used to signify the requirements in the specification. These words are often ca
he Personal Assertion Token, PASSporT, is cryptographically signed to protect th pitalized. This document defines these words as they should be interpreted in IE
e integrity of the identity of the originator and to verify the assertion of the TF documents. This document specifies an Internet Best Current Practices for th
identity information at the destination. The cryptographic signature is define e Internet Community, and requests discussion and suggestions for improvements.<
d with the intention that it can confidently verify the originating persona even /t>
when the signature is sent to the destination party over an insecure channel. </abstract>
PASSporT is particularly useful for many personal-communications applications ov </front>
er IP networks and other multi-hop interconnection scenarios where the originati <seriesInfo name="BCP" value="14"/>
ng and destination parties may not have a direct trusted relationship.</t></abst <seriesInfo name="RFC" value="2119"/>
ract> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</front> </reference>
<seriesInfo name='RFC' value='8225'/> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<seriesInfo name='DOI' value='10.17487/RFC8225'/> 174" quoteTitle="true" derivedAnchor="RFC8174">
</reference> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<reference anchor="JSON" target='https://www.rfc-editor.org/info/rfc8259'> tle>
<front> <author initials="B." surname="Leiba" fullname="B. Leiba">
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title> <organization showOnFrontPage="true"/>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organizat </author>
ion /></author> <date year="2017" month="May"/>
<date year='2017' month='December' /> <abstract>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan <t indent="0">RFC 2119 specifies common key words that may be used
guage-independent data interchange format. It was derived from the ECMAScript P in protocol specifications. This document aims to reduce the ambiguity by cla
rogramming Language Standard. JSON defines a small set of formatting rules for rifying that only UPPERCASE usage of the key words have the defined special mea
the portable representation of structured data.</t><t>This document removes inco nings.</t>
nsistencies with other specifications of JSON, repairs specification errors, and </abstract>
offers experience-based interoperability guidance.</t></abstract> </front>
</front> <seriesInfo name="BCP" value="14"/>
<seriesInfo name='STD' value='90'/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name='RFC' value='8259'/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/> </reference>
</reference> <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
566" quoteTitle="true" derivedAnchor="SDP">
<reference anchor="UTF8" target='https://www.rfc-editor.org/info/rfc3629'> <front>
<front> <title>SDP: Session Description Protocol</title>
<title>UTF-8, a transformation format of ISO 10646</title> <author initials="M." surname="Handley" fullname="M. Handley">
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<date year='2003' month='November' /> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal <organization showOnFrontPage="true"/>
Character Set (UCS) which encompasses most of the world's writing systems. The </author>
originally proposed encodings of the UCS, however, were not compatible with many <author initials="C." surname="Perkins" fullname="C. Perkins">
current applications and protocols, and this has led to the development of UTF- <organization showOnFrontPage="true"/>
8, the object of this memo. UTF-8 has the characteristic of preserving the full </author>
US-ASCII range, providing compatibility with file systems, parsers and other so <date year="2006" month="July"/>
ftware that rely on US-ASCII values but are transparent to other values. This m <abstract>
emo obsoletes and replaces RFC 2279.</t></abstract> <t indent="0">This memo defines the Session Description Protocol (
</front> SDP). SDP is intended for describing multimedia sessions for the purposes of se
<seriesInfo name='STD' value='63'/> ssion announcement, session invitation, and other forms of multimedia session in
<seriesInfo name='RFC' value='3629'/> itiation. [STANDARDS-TRACK]</t>
<seriesInfo name='DOI' value='10.17487/RFC3629'/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="4566"/>
<reference anchor="SHA" target='https://www.rfc-editor.org/info/rfc6234'> <seriesInfo name="DOI" value="10.17487/RFC4566"/>
<front> </reference>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz 234" quoteTitle="true" derivedAnchor="SHA">
ation /></author> <front>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></au <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</
thor> title>
<date year='2011' month='May' /> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
<abstract><t>Federal Information Processing Standard, FIPS</t></abstract> rd">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='RFC' value='6234'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC6234'/> <author initials="T." surname="Hansen" fullname="T. Hansen">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="BASE64" target='https://www.rfc-editor.org/info/rfc4648'> <date year="2011" month="May"/>
<front> <abstract>
<title>The Base16, Base32, and Base64 Data Encodings</title> <t indent="0">Federal Information Processing Standard, FIPS</t>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization </abstract>
/></author> </front>
<date year='2006' month='October' /> <seriesInfo name="RFC" value="6234"/>
<abstract><t>This document describes the commonly used base 64, base 32, and bas <seriesInfo name="DOI" value="10.17487/RFC6234"/>
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data, </reference>
use of padding in encoded data, use of non-alphabet characters in encoded data, <reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK 224" quoteTitle="true" derivedAnchor="SIP-ID">
]</t></abstract> <front>
</front> <title>Authenticated Identity Management in the Session Initiation P
<seriesInfo name='RFC' value='4648'/> rotocol (SIP)</title>
<seriesInfo name='DOI' value='10.17487/RFC4648'/> <author initials="J." surname="Peterson" fullname="J. Peterson">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="DTLS-SDP"> <author initials="C." surname="Jennings" fullname="C. Jennings">
<front> <organization showOnFrontPage="true"/>
<title>Session Description Protocol (SDP) Offer/Answer Considerations for Datagr </author>
am Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'> </author>
<organization /> <author initials="C." surname="Wendt" fullname="C. Wendt">
</author> <organization showOnFrontPage="true"/>
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'> <date year="2018" month="February"/>
<organization /> <abstract>
</author> <t indent="0">The baseline security mechanisms in the Session Init
iation Protocol (SIP) are inadequate for cryptographically assuring the identity
<date month='October' day='29' year='2017' /> of the end users that originate SIP requests, especially in an interdomain cont
ext. This document defines a mechanism for securely identifying originators of
<abstract><t>This document defines the Session Description Protocol (SDP) offer/ SIP requests. It does so by defining a SIP header field for conveying a signatu
answer procedures for negotiating and establishing a Datagram Transport Layer S re used for validating the identity and for conveying a reference to the credent
ecurity (DTLS) association. The document also defines the criteria for when a n ials of the signer.</t>
ew DTLS association must be established. The document updates RFC 5763 and RFC <t indent="0">This document obsoletes RFC 4474.</t>
7345, by replacing common SDP offer/answer procedures with a reference to this s </abstract>
pecification. This document defines a new SDP media-level attribute, 'tls-id'. </front>
This document also defines how the 'tls-id' attribute can be used for negotiati <seriesInfo name="RFC" value="8224"/>
ng and establishing a Transport Layer Security (TLS) connection, in conjunction <seriesInfo name="DOI" value="10.17487/RFC8224"/>
with the procedures in RFC 4145 and RFC 8122.</t></abstract> </reference>
<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3
</front> 711" quoteTitle="true" derivedAnchor="SRTP">
<front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-dtls-sdp-32' /> <title>The Secure Real-time Transport Protocol (SRTP)</title>
<format type='TXT' <author initials="M." surname="Baugher" fullname="M. Baugher">
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-dtls-sdp-3 <organization showOnFrontPage="true"/>
2.txt' /> </author>
</reference> <author initials="D." surname="McGrew" fullname="D. McGrew">
<organization showOnFrontPage="true"/>
<reference anchor="ASCII" target='https://www.rfc-editor.org/info/rfc20'> </author>
<front> <author initials="M." surname="Naslund" fullname="M. Naslund">
<title>ASCII format for network interchange</title> <organization showOnFrontPage="true"/>
<author initials='V.G.' surname='Cerf' fullname='V.G. Cerf'><organization /></au </author>
thor> <author initials="E." surname="Carrara" fullname="E. Carrara">
<date year='1969' month='October' /> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='STD' value='80'/> <author initials="K." surname="Norrman" fullname="K. Norrman">
<seriesInfo name='RFC' value='20'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC0020'/> </author>
</reference> <date year="2004" month="March"/>
<abstract>
</references> <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
<references title='Informative References'> an provide confidentiality, message authentication, and replay protection to the
RTP traffic and to the control traffic for RTP, the Real-time Transport Control
<reference anchor="UKS" > Protocol (RTCP). [STANDARDS-TRACK]</t>
<front> </abstract>
<title>Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol</t </front>
itle> <seriesInfo name="RFC" value="3711"/>
<author initials="S." surname="Blake-Wilson"> <seriesInfo name="DOI" value="10.17487/RFC3711"/>
<organization></organization> </reference>
</author> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
<author initials="A." surname="Menezes"> 446" quoteTitle="true" derivedAnchor="TLS13">
<organization></organization> <front>
</author> <title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
<date year="1999"/> e>
</front> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<seriesInfo name="Lecture Notes in Computer Science 1560, Springer, pp. 154–17 <organization showOnFrontPage="true"/>
0" value=""/> </author>
</reference> <date year="2018" month="August"/>
<reference anchor="SIGMA" > <abstract>
<front> <t indent="0">This document specifies version 1.3 of the Transport
<title>SIGMA: The ‘SIGn-and-MAc’approach to authenticated Diffie-Hellman and Layer Security (TLS) protocol. TLS allows client/server applications to commun
its use in the IKE protocols</title> icate over the Internet in a way that is designed to prevent eavesdropping, tamp
<author initials="H." surname="Krawczyk"> ering, and message forgery.</t>
<organization></organization> <t indent="0">This document updates RFCs 5705 and 6066, and obsole
</author> tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
<date year="2003"/> r TLS 1.2 implementations.</t>
</front> </abstract>
<seriesInfo name="Annual International Cryptology Conference, Springer, pp. 40 </front>
0-425" value=""/> <seriesInfo name="RFC" value="8446"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC8446"/>
<reference anchor="WEBRTC" > </reference>
<front> <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3
<title>WebRTC 1.0: Real-time Communication Between Browsers</title> 629" quoteTitle="true" derivedAnchor="UTF8">
<author initials="A." surname="Bergkvist"> <front>
<organization></organization> <title>UTF-8, a transformation format of ISO 10646</title>
</author> <author initials="F." surname="Yergeau" fullname="F. Yergeau">
<author initials="D." surname="Burnett"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2003" month="November"/>
<author initials="A." surname="Narayanan"> <abstract>
<organization></organization> <t indent="0">ISO/IEC 10646-1 defines a large character set called
</author> the Universal Character Set (UCS) which encompasses most of the world's writing
<author initials="C." surname="Jennings"> systems. The originally proposed encodings of the UCS, however, were not compa
<organization></organization> tible with many current applications and protocols, and this has led to the deve
</author> lopment of UTF-8, the object of this memo. UTF-8 has the characteristic of pres
<author initials="B." surname="Aboba"> erving the full US-ASCII range, providing compatibility with file systems, parse
<organization></organization> rs and other software that rely on US-ASCII values but are transparent to other
</author> values. This memo obsoletes and replaces RFC 2279.</t>
<author initials="T." surname="Brandstetter"> </abstract>
<organization></organization> </front>
</author> <seriesInfo name="STD" value="63"/>
<author initials="J." surname="Bruaroey"> <seriesInfo name="RFC" value="3629"/>
<organization></organization> <seriesInfo name="DOI" value="10.17487/RFC3629"/>
</author> </reference>
<date year="2018" month="November" day="08"/> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
</front> 827" quoteTitle="true" derivedAnchor="WEBRTC-SEC">
<seriesInfo name="W3C Editor's Draft" value=""/> <front>
</reference> <title>WebRTC Security Architecture</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<reference anchor="RFC3725" target='https://www.rfc-editor.org/info/rfc3725'> <organization showOnFrontPage="true"/>
<front> </author>
<title>Best Current Practices for Third Party Call Control (3pcc) in the Session <date month="January" year="2021"/>
Initiation Protocol (SIP)</title> </front>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization <seriesInfo name="RFC" value="8827"/>
/></author> <seriesInfo name="DOI" value="10.17487/RFC8827"/>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /> </reference>
</author> </references>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat <references pn="section-8.2">
ion /></author> <name slugifiedName="name-informative-references">Informative References
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'><organization </name>
/></author> <reference anchor="RFC7696" target="https://www.rfc-editor.org/info/rfc7
<date year='2004' month='April' /> 696" quoteTitle="true" derivedAnchor="AGILITY">
<abstract><t>Third party call control refers to the ability of one entity to cre <front>
ate a call in which communication is actually between other parties. Third part <title>Guidelines for Cryptographic Algorithm Agility and Selecting
y call control is possible using the mechanisms specified within the Session Ini Mandatory-to-Implement Algorithms</title>
tiation Protocol (SIP). However, there are several possible approaches, each wi <author initials="R." surname="Housley" fullname="R. Housley">
th different benefits and drawbacks. This document discusses best current pract <organization showOnFrontPage="true"/>
ices for the usage of SIP for third party call control. This document specifies </author>
an Internet Best Current Practices for the Internet Community, and requests dis <date year="2015" month="November"/>
cussion and suggestions for improvements.</t></abstract> <abstract>
</front> <t indent="0">Many IETF protocols use cryptographic algorithms to
<seriesInfo name='BCP' value='85'/> provide confidentiality, integrity, authentication, or digital signature. Commu
<seriesInfo name='RFC' value='3725'/> nicating peers must support a common set of cryptographic algorithms for these m
<seriesInfo name='DOI' value='10.17487/RFC3725'/> echanisms to work properly. This memo provides guidelines to ensure that protoc
</reference> ols have the ability to migrate from one mandatory-to-implement algorithm suite
to another over time.</t>
<reference anchor="ZRTP" target='https://www.rfc-editor.org/info/rfc6189'> </abstract>
<front> </front>
<title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title> <seriesInfo name="BCP" value="201"/>
<author initials='P.' surname='Zimmermann' fullname='P. Zimmermann'><organizatio <seriesInfo name="RFC" value="7696"/>
n /></author> <seriesInfo name="DOI" value="10.17487/RFC7696"/>
<author initials='A.' surname='Johnston' fullname='A. Johnston' role='editor'><o </reference>
rganization /></author> <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
<author initials='J.' surname='Callas' fullname='J. Callas'><organization /></au 445" quoteTitle="true" derivedAnchor="ICE">
thor> <front>
<date year='2011' month='April' /> <title>Interactive Connectivity Establishment (ICE): A Protocol for
<abstract><t>This document defines ZRTP, a protocol for media path Diffie-Hellma Network Address Translator (NAT) Traversal</title>
n exchange to agree on a session key and parameters for establishing unicast Sec <author initials="A." surname="Keranen" fullname="A. Keranen">
ure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applic <organization showOnFrontPage="true"/>
ations. The ZRTP protocol is media path keying because it is multiplexed on the </author>
same port as RTP and does not require support in the signaling protocol. ZRTP <author initials="C." surname="Holmberg" fullname="C. Holmberg">
does not assume a Public Key Infrastructure (PKI) or require the complexity of c <organization showOnFrontPage="true"/>
ertificates in end devices. For the media session, ZRTP provides confidentialit </author>
y, protection against man-in-the-middle (MiTM) attacks, and, in cases where the <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
signaling protocol provides end-to-end integrity protection, authentication. ZR <organization showOnFrontPage="true"/>
TP can utilize a Session Description Protocol (SDP) attribute to provide discove </author>
ry and authentication through the signaling channel. To provide best effort SRT <date year="2018" month="July"/>
P, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures me <abstract>
dia sessions that include a voice media stream and can also secure media session <t indent="0">This document describes a protocol for Network Addre
s that do not include voice by using an optional digital signature. This docume ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
nt is not an Internet Standards Track specification; it is published for inform led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
ational purposes.</t></abstract> Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
</front> elay NAT (TURN).</t>
<seriesInfo name='RFC' value='6189'/> <t indent="0">This document obsoletes RFC 5245.</t>
<seriesInfo name='DOI' value='10.17487/RFC6189'/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="8445"/>
<reference anchor="AGILITY" target='https://www.rfc-editor.org/info/rfc7696'> <seriesInfo name="DOI" value="10.17487/RFC8445"/>
<front> </reference>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to <reference anchor="RFC3725" target="https://www.rfc-editor.org/info/rfc3
-Implement Algorithms</title> 725" quoteTitle="true" derivedAnchor="RFC3725">
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></ <front>
author> <title>Best Current Practices for Third Party Call Control (3pcc) in
<date year='2015' month='November' /> the Session Initiation Protocol (SIP)</title>
<abstract><t>Many IETF protocols use cryptographic algorithms to provide confide <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
ntiality, integrity, authentication, or digital signature. Communicating peers <organization showOnFrontPage="true"/>
must support a common set of cryptographic algorithms for these mechanisms to wo </author>
rk properly. This memo provides guidelines to ensure that protocols have the ab <author initials="J." surname="Peterson" fullname="J. Peterson">
ility to migrate from one mandatory-to-implement algorithm suite to another over <organization showOnFrontPage="true"/>
time.</t></abstract> </author>
</front> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<seriesInfo name='BCP' value='201'/> ">
<seriesInfo name='RFC' value='7696'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC7696'/> </author>
</reference> <author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
<reference anchor="ICE" target='https://www.rfc-editor.org/info/rfc8445'> </author>
<front> <date year="2004" month="April"/>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Addr <abstract>
ess Translator (NAT) Traversal</title> <t indent="0">Third party call control refers to the ability of on
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></ e entity to create a call in which communication is actually between other parti
author> es. Third party call control is possible using the mechanisms specified within
<author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization /> the Session Initiation Protocol (SIP). However, there are several possible appr
</author> oaches, each with different benefits and drawbacks. This document discusses bes
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization t current practices for the usage of SIP for third party call control. This doc
/></author> ument specifies an Internet Best Current Practices for the Internet Community, a
<date year='2018' month='July' /> nd requests discussion and suggestions for improvements.</t>
<abstract><t>This document describes a protocol for Network Address Translator ( </abstract>
NAT) traversal for UDP-based communication. This protocol is called Interactive </front>
Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utili <seriesInfo name="BCP" value="85"/>
ties for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN) <seriesInfo name="RFC" value="3725"/>
.</t><t>This document obsoletes RFC 5245.</t></abstract> <seriesInfo name="DOI" value="10.17487/RFC3725"/>
</front> </reference>
<seriesInfo name='RFC' value='8445'/> <reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5
<seriesInfo name='DOI' value='10.17487/RFC8445'/> 761" quoteTitle="true" derivedAnchor="RTCP-MUX">
</reference> <front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</t
<reference anchor="RTP" target='https://www.rfc-editor.org/info/rfc3550'> itle>
<front> <author initials="C." surname="Perkins" fullname="C. Perkins">
<title>RTP: A Transport Protocol for Real-Time Applications</title> <organization showOnFrontPage="true"/>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat </author>
ion /></author> <author initials="M." surname="Westerlund" fullname="M. Westerlund">
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></au <organization showOnFrontPage="true"/>
thor> </author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization <date year="2010" month="April"/>
/></author> <abstract>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /> <t indent="0">This memo discusses issues that arise when multiplex
</author> ing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP por
<date year='2003' month='July' /> t. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is
<abstract><t>This memorandum describes RTP, the real-time transport protocol. R not appropriate, and it explains how the Session Description Protocol (SDP) can
TP provides end-to-end network transport functions suitable for applications tra be used to signal multiplexed sessions. [STANDARDS-TRACK]</t>
nsmitting real-time data, such as audio, video or simulation data, over multicas </abstract>
t or unicast network services. RTP does not address resource reservation and do </front>
es not guarantee quality-of- service for real-time services. The data transport <seriesInfo name="RFC" value="5761"/>
is augmented by a control protocol (RTCP) to allow monitoring of the data deliv <seriesInfo name="DOI" value="10.17487/RFC5761"/>
ery in a manner scalable to large multicast networks, and to provide minimal con </reference>
trol and identification functionality. RTP and RTCP are designed to be independ <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
ent of the underlying transport and network layers. The protocol supports the u 550" quoteTitle="true" derivedAnchor="RTP">
se of RTP-level translators and mixers. Most of the text in this memorandum is i <front>
dentical to RFC 1889 which it obsoletes. There are no changes in the packet for <title>RTP: A Transport Protocol for Real-Time Applications</title>
mats on the wire, only changes to the rules and algorithms governing how the pro <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
tocol is used. The biggest change is an enhancement to the scalable timer algori ">
thm for calculating when to send RTCP packets in order to minimize transmission <organization showOnFrontPage="true"/>
in excess of the intended rate when many participants join a session simultaneou </author>
sly. [STANDARDS-TRACK]</t></abstract> <author initials="S." surname="Casner" fullname="S. Casner">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='STD' value='64'/> </author>
<seriesInfo name='RFC' value='3550'/> <author initials="R." surname="Frederick" fullname="R. Frederick">
<seriesInfo name='DOI' value='10.17487/RFC3550'/> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<reference anchor="RTCP-MUX" target='https://www.rfc-editor.org/info/rfc5761'> <organization showOnFrontPage="true"/>
<front> </author>
<title>Multiplexing RTP Data and Control Packets on a Single Port</title> <date year="2003" month="July"/>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></ <abstract>
author> <t indent="0">This memorandum describes RTP, the real-time transpo
<author initials='M.' surname='Westerlund' fullname='M. Westerlund'><organizatio rt protocol. RTP provides end-to-end network transport functions suitable for a
n /></author> pplications transmitting real-time data, such as audio, video or simulation data
<date year='2010' month='April' /> , over multicast or unicast network services. RTP does not address resource res
<abstract><t>This memo discusses issues that arise when multiplexing RTP data pa ervation and does not guarantee quality-of- service for real-time services. The
ckets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates R data transport is augmented by a control protocol (RTCP) to allow monitoring of
FC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriat the data delivery in a manner scalable to large multicast networks, and to prov
e, and it explains how the Session Description Protocol (SDP) can be used to sig ide minimal control and identification functionality. RTP and RTCP are designed
nal multiplexed sessions. [STANDARDS-TRACK]</t></abstract> to be independent of the underlying transport and network layers. The protocol
</front> supports the use of RTP-level translators and mixers. Most of the text in this
<seriesInfo name='RFC' value='5761'/> memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
<seriesInfo name='DOI' value='10.17487/RFC5761'/> the packet formats on the wire, only changes to the rules and algorithms govern
</reference> 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>
<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">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="August"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_24"/>
<refcontent>Advances in Cryptology -- CRYPTO 2003</refcontent>
<refcontent>Lecture Notes in Computer Science</refcontent>
<refcontent>Vol. 2729</refcontent>
</reference>
<reference anchor="UKS" quoteTitle="true" target="https://doi.org/10.100
7/3-540-49162-7_12" derivedAnchor="UKS">
<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/webrtc/" quoteT
itle="true" derivedAnchor="WEBRTC">
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Boström" fullname="Henrik Boström">
<organization showOnFrontPage="true"/>
</author>
<author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaro
ey">
<organization showOnFrontPage="true"/>
</author>
<date/>
</front>
<refcontent>W3C Proposed Recommendation</refcontent>
</reference>
<reference anchor="RFC6189" target="https://www.rfc-editor.org/info/rfc6
189" quoteTitle="true" derivedAnchor="ZRTP">
<front>
<title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
<author initials="P." surname="Zimmermann" fullname="P. Zimmermann">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Johnston" fullname="A. Johnston" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Callas" fullname="J. Callas">
<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="include" removeInRF
<section anchor="acknowledgements" title="Acknowledgements"> 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 discussions wit <t indent="0" pn="section-appendix.a-1">This problem would not have been d
h iscovered if it weren't for
Sam Scott, Hugo Krawczyk, and Richard Barnes. A solution similar to the one discussions with <contact fullname="Sam Scott"/>, <contact fullname="Hugo
presented here was first proposed by Karthik Bhargavan who provided valuable Krawczyk"/>, and <contact fullname="Richard Barnes"/>. A
input on this document. Thyla van der Merwe assisted with a formal model of the solution similar to the one presented here was first proposed by
solution. Adam Roach and Paul E. Jones provided significant review and input.</ <contact fullname="Karthik Bhargavan"/>, who provided valuable input on
t> this document. <contact fullname="Thyla van der Merwe"/> assisted with
a formal model of the solution. <contact fullname="Adam Roach"/> and
</section> <contact fullname="Paul E. Jones"/> provided significant review and
input.</t>
</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>
<!-- ##markdown-source:
H4sIAL0GTl0AA6192XLcSLbYe34FrvQg0lNVFqml1epR96UoasRuLbRIuT12
OJpgIUniEgXURaJIVfNqYv7BL/bvzZf4rLkAKEruMUMRIquAxMmTZ98wnU5N
V3aVfZ7d+1Rf1c1Nnf1i19nxZd7abK/r8vmVy5o6WzkL/59nJ2+Ps5uyu8y6
S5sdW+dK+PKVdfO2XHb4+1HbdM28qbKt41dH2/dMfnbW2mtYHv7MPv1yfM8U
zbzOF/DEos3Pu2lpu/PpYrFy5XzqiuV0deWmD78z87yzF027fp65rjDlsn2e
de3KdbsPH37/cNeslgVc4J5nz3Z2d41xXV4Xv+VVU8O6a+vMsnye/Q8AZJK5
pu1ae+7gt/UCf/mfxuSr7rJpn5tsajL4KWtY6N0sO7lsFq6p6TMG8V3edmWd
fNG0F/B583tZVTl9YBd5WT3PFt2/Vs2Nrbu2Wa5nte2S1Q9m2UfAUtPKTbz8
QVvO0883rW6v2n9tz7vFbN4sjKmbdpF35bV9bkxZn4e/MkTxc7px5Fing2Ol
U+xyPLlp10zlVzi7k+Ntf5T3aD2PM/qZ8raOZ9nLKr+y01/LShHkv9ybZe9s
bX+H48BP8cCeZzvff/89/elsW1qH0D/P3tp5twLI3jdwpnBztt8slqvOttnx
vLT13GY7T54+nGTHy7asL2w7yZbLGXz2+B9//1873z00sODx4V/e7aU754/g
8Gz2j7//b/irngKVTN/tzf/x9/+TL5dtk8+BkBvaGhxciTRXZK/K8/PSTt/Y
qlrkdQa3ZGXnkAMQMsTY4S8H2VKQ4+7AzptZ9kub38x/X19FGAAKfjTAwF5d
r/IqO6xh0zUdAvy1366XXVM1F2tASH1uW0RFHwuPHz6cPt59gjj49eDlx5P9
FAm/2jP4LNuZPXwOlJZX065cWMTvYlXjhvG4X9ruxlr4v21uAKi7tgRn+tK2
F1fXpevSb17BN6sW6L4b3PE+b/N1Xuc9+tifZT/buoa9uPSLl7Ns76w5y9NP
T+ABLZyG6+AZtk2//Bm/XOVtY9cJqneeTXd2pg+fDRD+66P97KAou6Z94LJX
KImMMdPpNMvPXNfmc/jz5LJ0GUir1QKIIytIyJ0Bfa6Eo66AoxxxVJ5yFJIK
yMpXeZdftPnCnADYbglyKHubr5Go7XzVlt06A84VQTpH8qfzOcHzCXcoE5qt
VyB7p8cfT462Z9lxuSirvPUPRiAUwKIPht7nBbcpCyR3AOCsrAvEP15bIHkD
uURgJGTisi0mpm3iiePDI7/OLEMuczaFB/lovqo6ZLFFs6q7SXa26hCAdTbP
Ebo8uy7nQJB4xZk1i9JVNi/gCBq+LvOAwj7ybB7AqS+ypbUtPPhd2ZUXTMed
nV/W5b+vLAFgCnte1rCt7jLvsnKxrCwepOwFFvz4ep/UB0ELrNWs2vwCr28A
l8uqWc+EJBZlUVTWmPvIn21TrOa4BhKIR/LGI94C7G9nt7f/Av/vPHoBz3z2
+PHTL18GWtRs1qJ4O/yPNz9+8hRvRsKU3ZW1ga9fH77/y8HHo4+H70/oGbCt
L18AO69XLTyjJTDpiUqUGyFmQqNn4i+42tNHj7+Dh+Kp96m1G6dWgBsJFSHD
X3CRR9/t7KSQ5y6iTXncVC9/8t3TR7ADYw6JmAF8t7Tz8lyJcYLsl8FWLJ0q
rru0LapCWBmMCSAQtFWAwXDZCW3eRIIesXxm8bKuhDvOgGzx4HF/TsyaIjqQ
LViIjqK7bJvVBbORnP3cgpFAgNnsnCQzCujOAfpTOYsU67L5pcVnIVHm2WXu
LicApYlunKByuQbSL1ThoO0EKh7udPR3/ESm7sDB+D3s2MjO4QkgMi9BRwMu
RRl4rtpylo6ToPsO9wLHwFpkenyw/+Jw+mpG9lnbzW/s2dQJjUzzdn755cu2
EUEQVry9/Qn+nh6+Iirc3X0MR37WAN3JlmDLC+DSvC7dgkFHEQT8Whv7mXRf
FRaT89iE3+y8bRaw4Mh5zcwbsMWuUUd2KMVFziGe6gbQBWr2gjaCahz2j9TI
1A0WYgPEfb2qatvmZ5UlA6EOIhOElK7G0g5UEOB6qBS2wBTbDtfc4NpENvwR
sBxvHT4q28Gmo42S8AOwkY+9vN0zbjWfw87PV5U+BIWn81hrLVMd3C0YcgIE
0yHCOAezAgnHjItc/HuJJvC8XOZI0ZuVYk7shmdY02HQ2c5zZDJPmiC/YcsM
FfEjM/ZQG8EWluA14BPo+Hh/8PS9zCWaj9i+gc3hQXmJ+hW+zMhPmMFWiJNV
ZxHvwHoOzAs6XcBPVV7Zag1fnducHwJX2c9g/OAVrCUQEYCSlTWC+TpvwZBC
3IJ9QWivLZ5U3grH3d5WsIvOAQcJfXqE5mBGm4DVhVduToyFGBuofzw3xRqh
v2hrieTrgrUbGDi2vkBRyCesJsbZWtFOcjFgMiLujIjbjR1nxiTqlwN4U63r
uaqsYF8WBaTXwakOY0XBTh4I5zVtyPgNwR5ai9aAFZUkcDI9BZQM6DV3Dn5x
TJ2uvABxI2LBi4TMiwQAz0uR3Jm+nEzBtZ+XVV6iXgKnYZ2QBj0MIUQxXjQo
gcwF2KrAUdZGDw6MGoGGYsk1dISpTGJkC/HOzACg5vwcuRyPDCgRTnRF0iuQ
S45Mu4S9wpcgdRc2J7PItBYMHHw0bKlxqOlRAgq7McWAjUxeGUA8wBtJ39vb
8EyARYQ/8FYD5gJ4AtXalU4ljAVI5yTlesCCadPaSmw75q1g5PqdExvgnTdN
C+Lv3rtPxyf3Jvx/9v4D/f7x4L98Ovx48Ap/P36z9/at/0WvOH7z4dNb+N7I
b+HO/Q/v3h28f8U3w6dZ76N3e3+F//Cc7n04Ojn88H7v7T3lQZPwIFm5hDGQ
RLZjEyjsCO55uX+U7TxG6gLG2N3Z+R6Qx3882/kOdKkBAV7zw5oaBBP/SRY1
OLQW5CIsklcVSN5l2YEwQcoFlkXmRdGPFu39bFNIILu9v7pyX8jmAsm9yc8B
iEC1ffkyQWUOVDovm5WL9QQBEeTAHBhjQUIdz7YF6zCn81LLBa4GXVXhicsF
FTM9UYvQ+Rw8NXIzAKl5W2I46kYFmFcgwN7NvCSZQQKJnyNKH+ABCxGQBqqu
LpSg4ALUKyDV62LZlKRxRHPl839flayzN+mSoWrGO01eXOP1Tqyz+IZcFT5i
FnYOMgG1eZ15qwAfzc7RvFmiVDCDRRCVAwcqeEeiChWwVZ3fkPygSycGJTwA
QcqvBAPMViV8JHKqpCNJPS2vWBVGNCUHyEeNO3DQHK5mXQdSq3SXfKyX5QWA
Na3Q7TBB0sHZg2IC3wpDdav5JaOq4bDLuJGJYq7N2Ko1iemK1MnKsqqaG7Qv
A4KRDUtWHHoOkfHl7UkjSFxnienF8sYv1px1KPbxATEZ4vGD1EKdHX8D2BUS
d+QMGzUB826D4QeWinq6yXNLoiPYlagDoQeDVhg8ohZlxSInPgCxQ28aJR0l
/PjULT/OKHUhfOCqUCAsBhAotFQF7cXDvGlBO3fIaT3SMptJi3HMz/shuwzW
e/oV0IJf3vwxyt27Q7IVjWVhASYORi5U3ynWL/NrUspkebNnsDZoRPMJo/Oi
4dgGDUVUthhSOJMIG2/CxZYFnXleVisy0sxi1WEgsOepokywNZ11qvdBdChm
FsBWYNSgSRQBoUbpTdugSlcCBTLnLcIKvxJFxICLPaRaimw9+PtzN8EYTWvh
c+etxLzTb+H/VVWQG6LUHK/K7jYsEK09ZtOL10AhI3LN0X1wTYWWeBMc4tOI
EE/xXtCiq84OLSEkAvRugDRAB9DzLwS4yPQizz8IIzi42lZqQAZvAwUJRiKI
OQGMKYPnw8HCy7CYj0ZlTGxgQoJEaospakrUE6imRSFuPTra38eYy08UKdl9
AmC3SN0YU4Qjwq/JxGxKMiitCYabBhHTWFnYCkoPkQMYksMoMik5xuTCFmVu
8JoJy0pFDn0R3+xsxZ6ycHv6BLT5ztYW/k0fLedzgD94MaRAQbpbQAaYjd7w
i72bYAYRNcKmjFu7zi4i+xmxQBbM/ewtOVBIDmK6vCYHrSQr4va++FdpiE5T
V2SG26VFySv0dLcRjlyGjgP8GumrcA8/jbeZL717w8ZBJLJhSeR5OLObfI28
e1gbNptWQP7PjdmZDSwBMvMWDZzc2rvjHoFDd0Gpb00R0CxDLl8Cfsl3RUpZ
UvwSLp1QDqpaR2pQXAa0LsEXuIHfAdu7s+x9o4LjpgSiDYEHuNurligQI7YX
0c6qrkhURiDhIgRrE4zGzrLRmCxBm2HiooOMHU7v7aEmY9MhJyW2yK/YZCMu
bVcLvNTHCERuGrDsOssHR45ejHb0TBDrqlodADO/JN2HWIpMwThqx7o+u4Zz
KEYDdKg0lp0uiquJXpd8nAnRp1ZE3b+BXiZMwR6dBWThej6YAw8lcwWuqPzH
MxAi50vwFKLQjO4Nl0TiD+QChrBtBZEREgHfxzHzKTzwPWqRQcCmb7AlsWk2
ythUw3iwWG4TVKZowcZCCWNWSO22moChUuKaxSKIPOdZHFmL9wTSiJSj0CdS
ntfOG2S6JkB7u9doDdoDCzwGH/TJUwMSD5MCCYUkLvRQKdLZgHPc4s6AjYRx
AwwLjANdUOjj9rYsEjHpH8EGf4hVkK0XUCMikHKF+Zxhpo1j5n4/uM+39yMn
vHeiKBN73vZWnoSQNNyx82S2wxGPn/67xOaf7jwDxxTjO3CLD8Skt0mU5KdE
FW+LkXJmPXMVFoMGGGHdaJSV533BYEsyghLTTLTghYXd1JY0WrZVzuyMTSwx
km6IPmO2vcldZMZGx7yNX5nYdBZrcJk7MZsEitIlcchIt4Ad20MzmsA+Kkb2
z2EvM0Xns0A+zFkkMn8XOQCSsyoTBkQdI04KwFbYz/BI3jg804k1VpRu3lwT
nHkvwuuAAQtvP+iNwQimlIMhtYYuPGIgJPyOiePrfoiPHwp3l3MWw/B8EFwk
LdgIpgWBbtHMJTi3WGjIIUhQn89r2yedwPhh6yO+hZWAD6hvc7oI7TwMETT1
ZJD2E1e6dbI7sS4lORNQQ9swHTHdXaEQFnmSEAI1Sqtc5gXHvHNT25tqPSUP
4QIsfDgOCzuz6s0tAVCKDhUsfNh2g5vkOkEnELVF2Y8Zp3Z6XTKdMZIBGXZ2
McNAFNpvrUaCSACKiA0L3tuOfA/j5Aw51C5xkrxC64TUAaADYc7BOkHj5weO
yPRxSjwNhlEFH1VMVfJMDq6gsDohy/eILN99tHz3xfK9vR9bjWRuf7uJjII4
srPZtY1sX2aGwMJ4OS2qOhkk6AItCmH+SBeFRIs/fTOUTC4DPK69A4PJAQ5m
otmAuCLDfUliGo4Kq5HEHDX0DR+vhO7YzPYSKHYS6WKm3YYDGhg4RyxkF6uy
yMGqRsGyqnN6vC04RsgRGNYmCDWFgTBOQ24p2kqF5Y0LNBJ9I9PTBD++4ITH
isy8uU+gD29j5tX8BH3bD3F6wMnJJF7tQvpmY5wHA/Dw3aF+570jSXShV+7T
fOpu4x0teh2uY7OWo20Y2YiA5lAK23waB0KUKde5dJ1oD5hDEpttwvarRwg6
y7xkmp/Y6Laql6qiAKSjz4f5IFeCmzjaFSugJEQVOVlprig6kjRbRDZ+SL8R
8AaAp62BLmaiIskS2OW6tDfeLSnr66a6DuqiRMoXLQP28YqWIxe+q9y0LCI0
oOn5Gi5lgm8wpn8VojgYwm1QsIadTMivY5hqqxZZIHXUD8H8ck3kIaF7FWhc
T5voRHP0Ns1qotkG0Jl8GGIbd4qIEQdcgnCSeGY7xgD9ALhEnT5YQZajhH8Y
eWDrXzdlkXxDqyQUNTGKVBYBp0oxCZIxbBQBlEgW3DWYo53xYqvPtl4Xw8O/
Dnt3uQIzqnardlPchQuHAgGMpiiICDz7v1TWuL0PVjQT/DD+KlUR54F/tjZX
O6B5KtYGiZqjvePjo+bjiU9fJ7JpK3Fl4A+9XAofntByADdlGzQKd2cawUdi
RxICEt4NoWSjso7Jj4Sg1jppSUUU1760PrkyHmgGmmaziA0vjpMmIJB7ehZK
t5xFnymp4KJwbC8GMRKQjYzsaZTxUWgnPrNDK1ByCOVoXl2hTvfgR9D2guNk
wXLhxzrSD2MheiMBzGuKfNx1QIOHYujyGgxNCUiwc+DyRRz6iysgfJSe3EQJ
BavbaAL2ZNuyXz0uv7kUOdFVFstZKTw846opDIeDeTtJ75cyKZf6AlFZS4Op
XeQZXND4zZ6wAAYFo7HmxG6hrfng4Hk+74LHwaWkqliNINn2QOgV6aDCLVvG
G5wOB8BkQeEB0ckqV3QBTbFogs8NEoM9+gehg8yN3N/Xs5K6lnqZPlyCS8K1
odAPEUNsuoVPJcPtFEeDZ8jOMeltrzGPemaZYHj70daUHqN90cpqwoeKE+MD
GxKgcly9pwHrCdwANEV2KCUDQZNh3WYpdRZqCEhk4vaWqqqpMo8C90sMPTXV
KiTp0RIRMsFqmtUFWJpiYIe7mWGjkLUJaSg2DKsVRhQ4RJNr3GSQF2nAgN16
tweOQeH1i5lT3fRFmy8vy3lUAJdlB/4hlDyTswkiK3hwzhfhmVSQ5l1cigc3
sDZkdUwx3YwKDvF4Xpc1Rw4EfOMLIfIMgM7EL2d6hkPxoE68pcKY8JrTJxJr
yfWFiitCdnx03k/jQ9FTgpP7mEvkggIHhGour4UbuhGOnEowjt2VM7SofrcU
wZnSfRXYOthCwE5Ha6flAnY7ba0rsTODcoeXSrMRm+sxG7Kd0+30/YbbWy0Q
/K0sfsMFiYx6J4qmlSGze3C20drIRZy1TSAb7BulLHDj3JbXDEScEjjccBOd
Q2QMKiAF0YQpkzQNRx0cc3gpZYhJgYLGdSUTReImLcka+KRJRdwg8xW8Y2+H
TaIwPcYAAU12gH6MKpMQRDnPhN60FEBtjEoJ0mysXXyEdhJlmKkmZ+U4MnTq
D1T2CAd7asIpSa3cyFVoWyHJaNREUHXap5BTszVGNtvBD8DkAVgXzruMXodT
asKiBq0fdBTkrTqKhqRRQolvHHzOSRSiOTq1/McXLV7O5AMpxCFsKhlMeSE0
IjmB7SPLXnnKkwzWBqa6bSxfqVGgrfje7UxSti7K/IPv9B6Ts0RzR3nn1hPR
jlG6wWi6gU88GEHyua5BUp8eEevYZinnYwbVKQLnD8GSTEK8I6vCKROUsMm/
/e1vJpNrhj+KguEP3Q93bp0vX7zfHrlgij8jn9MdR9vURvIfY9/f/QXf92da
/FgPbYefNv3xa/dlstUX73VrL46+5Xkbv+4BsusB+fr+FBDCJIPx1edt/FG8
vOj/UOU6HdLkaHvw7dfgvPN5WyRyXygm/2WMCvhHr6QtbxPN3T7P7vc4lzut
XtxTCbDnU20DZ/XelyQyI4akBOiUaLmgKHFWVLOgAYd6Oy5ZMqP2bMQ1IK7o
rLKto21Nqumz2IynUA4/FpQninIs6KvWUm4HtnzlErVNmjbhS+bErYi0OVdi
OOyNgXkGQi0IDZlicHG1RN2IrUEaixJ5OSHjggI0/dCeoSc+cJFHBxIk9ti2
gL8JeMAPK+IEJ4ICLSlU2bMVMUWp4o62oK4cm2qwXGUvQPsssFgKbWEiWV2m
V/RWlL4girVMT+7G2hQrHzjlh+F78LBqf1wIgVudgcPTrdCw0babKbgLNi09
AtjJq/TJYgzV5HNMnrJNVLpJyFyU3nMIlerluX9uqXUSpgb4MSK3BANy42YA
G6G+aJLpwY8XhTk0oUbLtmjZqJFDNEI9spIsEvnC4XgBFtflnWajscAVdG2E
UnKYOGVMNS9Mivy08Zoqr4mM5hHiq7XBBGt0JbTGKOCv4/onnxxh4zS2Usga
PvC20O39gRnDsmRo8/Ts6HneYtfjJlO3FwhhZ0QqYXHf6nmEBdE34ruY96NK
hpfU6YOxWBPciuix/XJL//BZtBl6ym+Y7jz1ucmRXY5Z8+b0QK5T2fuGruW6
0klk0QLpNDfSJ0aW1BrW+BwXLmig8JEECql/78uX52p8yKLZrTSiNsscAz4i
pwjIPz+czR7t/vgDXvElGwPtB1rMcAXeeAkpovsM2czjnBI2XLEl0tK7gIx0
Z/Ls+M3edPfJ0+TQA7opwGgXy27NAXnfQIbnCRsgM82tltTUxxIpIgE4LezU
BlQ8x3A4W/3desklT8M9TFCYKEBgA6MKQE84VMTnBehCtDazDGUCZs6YBFUG
r6g/XDyCn/b+cvj28OSvGGr97un3T6mPhjOOCe3DaiK0k1ZQmmUQ5/oIR+er
WpoXzGFP8bpQtuA7887WnN2J6nMHReSaSDdcdGVHlTq5RFHyQY7lLopHdxm5
br9CVx8b1RsUNVOulJjTp6HnIuXeKRdptCBS9UZzUFPExBYHcaLDU0iP9bPf
bduAysEOooTcQVPaiis6uWyQS4fIe6Zw9J1cnGBMkvOocpg+N3nolHBUCcS4
LBckxjvU0VhYq2kc46MrWqBWVqDDARr0dBYWxw3kFVCsRpNDk8vIuZmoVLgC
yUGcKBYdxlx+4MMgsDzR1M1gHSBcEyM0IIQ2QyRHZouGWUNangILIwUkN+DS
d2ShlZw3Eq++rH2NQUITvvXNpDlA3JzKgJ6gQblMXIr9v5RNGj3xQaM5qdYI
c3TlV0nj3d5fpXrOcJQoyr61USiLTjvJzfmmyzRORkfbUY5jHQdoQwexJmvv
AouSprWNIxGanIjW9OFiin/2SpO51HI9po7DgXEu5uvMQ9XJaJcSITUBLw9R
Ojza5YgbgUaNu0RgHGBGmPk0qPHLS7EmkkyAXjCwstPCYtT1N9u2TXsqHEOR
DjyZndmjyVfPk8iZtBhVyrWe1OkL8RxGhJKGUdlsuo+FJFg523GzWs9+ipJ+
Ks9RMvXj+0HRfiU1WIaIMNfP/3z84T0Wm+P/nPR7gu1azdm/Wc19IM/UiK1C
izXx4gyLA0TI+L/hWqPXslny6eT19BnCAb88ow76p7vfUyVEbMesfcXdM63T
I4gwQn/CdddYKP6tBC2aivt04GsNqbMxT9mheWc7qTtTnY650Dd7VBq4++ix
hPfDaqyDgADlXmppAlhi5XGaeSmsXqrUZWDlv27DDYSXWI5UTTCS6vYmEYee
c2efUnvdy73jg6ePaaLC08fPsH8TcU/7Y+AY+9GnITLYP8Ov4NT4ADAiVUQM
yUKGhviJ826hQkIfmO7L+H1N4tPJBqfDFCTHw4UAUhWX3OFC9KBHJwG/5Jou
nV2BcsBsC0I/CZazOQ3xEGWlKW3hlO0BVtF03mPng7MoFtj74UxUfNrjPrA0
T09PzYDHX+gWt86ePma5tLUJnO1tWiNYrieBIEaRHROR41NiA5nLMOb5sqOU
E1iZPgtMqnSJ2oBSBOERU71/RPBwTEQIFVbD/hk6yxZd/JLiu8ARnXXLHO0R
OmIsQN0kynyukg3gBv3qqvzdFj9Qb6jQSE4JJ4xPfLM81RoH9ViYcICu5p1P
TPiyiagmQtq5HcZ5ys6Le/t5mdec/tGk/qqihpZFgrzAhvGQi6QcDOdzPFg/
2DaXgDyMohDp6YP84WHgiisz8aSWK1JxQkNjQsuo0OoLK2ZSX13iawzgd9X9
fcdZ+j08J0VMlJ1iJN8WU0+8RYlZ0yELHXrqFMbxXBPVo/y/sMv4g5VZNlfi
vI6jjbf3z5dfoooRFGVhtEuckdKMdmLMN1pUFgrH2G+KY2jemvUfKvIwgZNk
AvEBG7o0tO29bT7z+KU0ocyxH7ikwj6H3PXmRkjyC/2vBQpcjPdS+kh7sIeT
Q7QW8gCbbkutj7uz5V98VqpwBGNg2VDHdyjgkHrbDm30qJKeS4DiUnnl0VZC
bDjrg1KrOuyjV5wT8nTYfK2BRkVzv14pjdn5/P1YN7U8XUqgaXqDdDhH5Tay
bdlmgciijJiJ+oXIIqYApk/cSdCK627AG5mQSw4AeiNCao58mXi/Woh6vdsW
S2J9wClUNY0EHLmKRfpNcwFuUKJTanM71cLodT7bRSXOUowaf3RH+2wvxhng
5JBrr9kVmXCkU0fKgkbKkqLMoNFmlv8/VUlGqpJ6qdLzZZQqPZEhYVk042Qi
qUiJYUf1nVrv5vdM5++pDo4nrxaNwzCInZdO+twClQDiP9RiZWEnQWiqcp7I
wuqedCaSkk/ylYhPLb9rqBhSO+8vgRRdF9f1ncTzf2AV8LfUPua0aso4HDPt
NcUl/cjOUHBwc/kpCjTu5SQPXjuSe43XDKlJIU1qxnyL4wCa0b1KzpcLSrgO
ugn6ME408FwIQsTdy/WaBSNEFFGVxOGwLiBuD+wVNeggnl6NnAZENHFPqXcp
26XQEHehYWVaaW/Ivi7aZgkcDLd3oZpA+73BRyEx2H8MJlamlExBwUPHlFZv
xxUDAAnwKapRXzQQ9xrlFJG50WF3cimOMzI0mkH729AO6bTFW0cCFXbBSML0
POVlMOoTuuwiHU6xgxtp+4575pIjlWZl5uYbm1/VmGDRDiopPvvDmfw/msf/
J7L4nHP+EywbZTn5+Xfk8MNd0X274b7Rnx/jeoHRn95SR7TUn8JdPRDp+z/d
BeEfw8Z/ROn6HU3Ob73mkvDtwXc/pvl+/GZXc/r+rj8Pvkuf9Q6ZRBfsPSv6
rvcs+kYX7D0r/u5ubGz8fIANv68ft16BYBgtMvijz/KFCAOBsKEW4Xhua/BQ
G3E4YtP9nhYpYdWaXDYRmzGXOSFRw7Eqxr7RhQaj5GuP46laLL5IU0gbI3yD
LWsPpg+2J5wzpz5ZUlB0XdGszvQ6s/XgxYNtkYhJ2VE/wx6XFGH8qOGqBVA7
lO0hefHAmU3l3VtgJzVe4z9AlnmwTXHtoa73WDCbs/kBCeeaH4stDFankj9V
LQnb/IA6MBlLFqnQsdqrnFEYRbzLpGV1ln1w5H6eVWs1/eJrvaLyvYOwCd4O
TqfRT6XJw/UPTNWd5idQcSslhHItGQ5r9GoeVsv4fkDi4YH3CwWVWtZM6tbZ
uGgb9h839GjdxgP/2Q5RjN8Qam5KuGP+wHmQyaXmvDxVjugO2Rz0JS1M6MaX
WqBt0XKlZN4NoY3J0A/FHdm3oX3vPkjyrVGpwGYEKD36Is4RDOwib8kIHYGR
Ejq+7kAWpcwyOSW+jNykmM6+AdMnI1B5QzObZjFck01FI5iXdKbHF9QzbdWK
YzuQnVq+Z+AfYX6SLGFbYFSLwjnUeaTXjN33tQoUrXtE41irUL51hUgioZHO
13E/y1hjjPLLzytAPc6eFIuZpbnUjXqfKZSxmH+ujCVLyljMHyljkVmafIXv
b+t3BA3pRKlKqxzMZkdGORovrRvCIlM0+gk0W4XH+dKJyAgv4v50ANYsWJXk
loRmvJqHHUY7lSZ8DgViM9x1cH/I5tdMZn4Gf2oHkFwAmAE8r7BWjNsGNUec
Y2c6hg98VUFiOTMT8FJBjQRxReETbPXxYpbm9pjoW0mrcq8zOACrpSqSEGkK
MztyCqXu7f9CTjF7YWao90YPg7fAspuUQ6ISIl0QwMN4LJhEy3TAZlRuJiPb
kuVoVoxzUiRtZC5rdFYk4HDWAfrfsIEF7iz6Kq8AacVaO+Kj4bn4HBNpxZhW
uBl1zNP0bZ+O6ybhj3UjswoiB563z0MuQDNjztR7QSmKJ1misgIPVQ3OGajX
vSk/ZsDanp1zd6Wmh8ZHtS2W6ZRQ/wGtvJsS+8PYneKlAvX4IQ7CvLQOl1RW
8cBkzOSecZGABGPTqVkcHJHRWevFwnbtWnFAEuLcbRj5TlHh/izn4JES//rQ
sgRXJXK3xVW7HP/T+CE1Q2HRVi+sRHWorsSYbl5bKn6d6HreWd+S89n+Wj1k
gMJx6q2MkoexBTpNh06bO6aaScJh6gu1PGsNDMyZZmcO9w+wWAr+k7HzT+I8
zDi1RULQ88Q1DcTAjuhgLwbLiaEQrTvR0Sxn3mjk7gS8mQbG0FypUgbbSnGB
xk+DGPRjcjhk+ImbKfV9Mz7rc6yNZ7f3cfdT3wp8V0caCkyHvCQlY0xw5yUP
OkuD2kyAWXaA8jZEF+l27f+iypc8WzGM0WrSkYYcYeLGIQSQB1PMLxtvvYT7
whD3uCEs9CRh7Dn0gfXahNBaCR1jmEfxW+zWo0sbnvyrNtSNpBWoJTY0dOIt
/Xa2KFEfa7B4zL7FJaVsT3r/0GY8DuI3KpXpTaghZMRj733fOTNDgNtIlE9F
OIXQce5ZGIfOBxDJb2JMF7gvlvsmZmWtQEeZ4TMkKuI8oYV5FHjPkBguSpq6
2iR14i7Ko4/PQwjvRXh1FMbxy+uSCrzcFctQcMHpQhyRK+oublY9U7jo6pXD
1k/alcx98+zpQsIRZZaRikKiDNKfXprRQVDFH5LZaENXr/KqkICj0tTgNQVU
bhrOMhpfEvv7OQ8cTuoySD/Beq1/MYWPCp9w0oMroQdFFiNo50ZGqaD0+ToT
ZlyT3MWQuPd0eiCNbm6s4DvganPNd9T61i/7jlE9Xvk9TpCM1tpE1d4439Hx
ZCtJk+u8xEmENC6ylPLuGH2hOiXQD1L1sLBci8oK9otqe9FgSMUXYyfH5osS
Sd1zutuFiSqDukR45A+SRABT47IpqODIv11C+d8/VMarclY6WY2zf1LGLhhU
zyJg8ttr18e5IpSv10ZrxEXTHRZ/qHT926vVA0R/3n04m+0+edKvVveQSKn6
a8YwE8RpvCOWPf36obQAK2Y7P6iEiCRivWQM3bfJP7PVxQkWWVnrkPZevn8t
ZR143Nuig0dlgEmqftKKvL3j/cNDhIh+QaPq4cPdh9QLzxYXVjug5Ph4sn9E
k6rk1TdPnjyU3lmqbZbSgc9SDhPXRyivmGTkYy/Ix6KM5gEkT5SsLs+rJBv/
hFt7TFQ1fGZrtH2c5ttcSMf490hRTYifGetnP+U8C9HIC3t+6r3ax8tLek0E
w84myScnsP5ngtMjAE0sQtP+0fTdp/8m7/3Btc7lvUVUa+USG252lwRMlI2f
IkDt5XG1PKJsKna56RVA2qgKNblpqsZtXD6/hWyuUVFyJXGSCB2SdFTDoezM
Hm2jMhirafUL4EVYKJI2S0dvCxpwXKhbL+se1/kZLNq+nvLhiMZjbgizW+K2
92DoPgitcvHrduLqG6RCnYsBUoenVuhEPjQnmY207NGosgzAMyhp0WLpB6Sn
0oKupQFJfK3lVhXh23TduHQ1vmpkRep/MGkyPhS2f5X4NKBGQbSCbeEqKg5X
TMOu2KiV04786KiInbsVqPzanA6aFkIN9rdXs29kGSloN/0U+jcWtG8s/hnO
AIo6BnwYLe42iNiSDM8Ql4h4ctJrZRnlMPIQ/DOC5RLr+l77DnYcgHMmqQAf
iU7fDcARi14Dlp+JwLFJfOWEb3mPxvHxa2DCiA5u+UxecXZXUf34+X2trp5Y
4+66era4eAKEEjCPNCQZkg60Rk5vLbabRBKFqBtlb+LzftBJeOHtX+VolwB1
Z+ho2HMMa+UXaB11JnmFg76jw0+2CHFXb63zJDENGuw3NfqjMj6aZuPC32BO
f2JL0t/uDTsXCNNPwYlgIBs3LUa8oQjTfNVSW1l46xblNX27mbx+K2Sdkqkc
ajs3jofYut5opyzeic6G7sfTw9usbvK1BuDM+KXJ0IcBDjiN4AcZprHS8Aq2
Mp5BPeatRe8bAKouGoKAU81RQZRGCmHBbpVHLTxnvrN0fMxYVHFmkqjdN03L
0jkdSctXeFEJdVfjwdplp2HJaFoZ+VcJEZk7iUixNE8osh9uDIxg6D0wcWoh
cuPoAFBoD3Mq9HoKJRpi7Ct87QnOegtFPQwTS/Nk4L68boKjW+nUJU0cyItX
opmUSdU+yuNN8zzj0L8iLcUHZk/QK4pGt8uBZPTmGPd8IIvCLHrkRJyIjMVR
CSvS67RQ6vr4JJ00emyojL2K92jVAJsvYfwUjfIclcf+vMM7voajl8UFYux2
PmBAO/ONLxjUyN3Yjf2XL0hhYYFTw2hMVoQZEp80CC+RG3E9gszB1ylAjA3U
wFotKGEtmk2zDLG69DVlYRBn3oYYEU9KyiWhhBFCdTe4NCPdjcyxiUode4/s
knmemx+Lv8gt/nk4Z2m0Onsv5h5igqBhUi00zrwUCMV3s6xolKIDhtVS4iiA
MelN/Eh37o8+fRs17ND4eVBIqj1XEIUXV/Mt0HTKuRADiwz4IaFOPXEf634R
reakMN43ECW9gZSS9PMYkAJPjX55K2liyIbScmGdtcydozE8W/RCsyWPvY1Y
Ewlxm3FruEJb1qIopPYM8Bj8MGQDEc/xnxhPWvWI8s4Ef7vpT7LtrapzEKO1
VJr24s8y0nzw/kzLQz1ImkRWPSORnxviZXQ1Jq7r/g7goPfBqkFHgrJTUR5/
PHkW+MI75jWlPlYtzot2G975mUoWJ3luEmhUBYPgani8bw1ERJQkJOJXItHL
tcOc95Sco3dg6Ov74heIavF8IkVgExjbYHxzVaovcJJ3p/lrk/c/9uSoXnOZ
R+JXMpDHOq1mkvl34Dq0ntksjjboFUevLivajtHt8BH3Yzs2dIqs77Kk/HRj
wvaAZcX4lddQ70sAiLvU5NWh0et3+lOgpWKF37iigeCRTrOJZAz99JBW3AZg
Z5RH4PVxnXT83qjNpOrf8KdUmrTdKmb6en/zWzaM+VUctVHYu69gIR6D7eMe
bomvPKz9639HxuTBNl6JD9XTGz0jZ4telIl+CE4L9pO/q3VQFZ4ug47jihOx
DfHNDBwx2PS6W3yLXOffYFfqiOXDvfd7I3QRb7+1FyVow5anxvUHBjCN3/N+
5MkatN5/JffvnuFb26SGR+K5ITb9n77eP5uEgoej/ELhUCZpWWQSngvKrjyS
18tXP0igNX5biWQAF3l7xZx1b//NJDs4uAdrld7zng3BHPe+xyGNhxZSu0bm
p7n8U8DCOgpuCiy9sR5fZ45nvDfH5r3KFhcUZdAD1mz4jb6sg5UgAabvC/Ed
WDeoFx+wJsQvV5FXa47zRXY8bzoQGG9WF032S5vfzH9fX3Hhw8cS7DnQ4y/z
tpap4z5hqu9MkABTg+9s8QO6SI7cUP9d67ow9x2s2F/Ayrgsr7KXsPJFDgYv
Vft6GYHhB+QNw+2dTY+jScCsK3xPE55Ym72z7Q1ZmaWLXhtK8rzi1+14Oavz
U2EbBWz7Y5PT2zOwgnFVZQez7GfsWQmg4AETQxIn+UYRAmxm/i8eEtWQe4cA
AA==
</rfc> </rfc>
 End of changes. 110 change blocks. 
1424 lines changed or deleted 1538 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/