rfc9257.original.xml   rfc9257.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.14 --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ]>
-ietf-tls-external-psk-guidance-06" category="info" obsoletes="" updates="" subm
issionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
version="3"> -ietf-tls-external-psk-guidance-06" number="9257" obsoletes="" updates="" submis
<!-- xml2rfc v2v3 conversion 2.42.0 --> sionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="Guidance for External PSK Usage in TLS">Guidance for External <title abbrev="Guidance for External PSK Usage in TLS">Guidance for Externa
PSK Usage in TLS</title> l Pre-Shared Key (PSK) Usage in TLS</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-external-psk-guidanc <seriesInfo name="RFC" value="9257"/>
e-06"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Hoyland" fullname="Jonathan Hoyland"> <author initials="J." surname="Hoyland" fullname="Jonathan Hoyland">
<organization>Cloudflare Ltd.</organization> <organization>Cloudflare Ltd.</organization>
<address> <address>
<email>jonathan.hoyland@gmail.com</email> <email>jonathan.hoyland@gmail.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Sethi" fullname="Mohit Sethi"> <author initials="M." surname="Sethi" fullname="Mohit Sethi">
<organization>Ericsson</organization> <organization>Aalto University</organization>
<address> <address>
<email>mohit@piuha.net</email> <email>mohit@iki.fi</email>
</address> </address>
</author> </author>
<author initials="C.A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2022" month="February" day="04"/> <date year="2022" month="July"/>
<area>security</area> <area>security</area>
<workgroup>tls</workgroup> <workgroup>tls</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document provides usage guidance for external Pre-Shared Keys (PSK s) <t>This document provides usage guidance for external Pre-Shared Keys (PSK s)
in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
It lists TLS security properties provided by PSKs under certain It lists TLS security properties provided by PSKs under certain
assumptions, and then demonstrates how violations of these assumptions lead assumptions, then it demonstrates how violations of these assumptions lead
to attacks. Advice for applications to help meet these assumptions is to attacks. Advice for applications to help meet these assumptions is
provided. This document also discusses PSK use cases and provisioning processes. provided. This document also discusses PSK use cases and provisioning processes.
Finally, it lists the privacy and security properties that are not Finally, it lists the privacy and security properties that are not
provided by TLS 1.3 when external PSKs are used.</t> provided by TLS 1.3 when external PSKs are used.</t>
</abstract> </abstract>
<note removeInRFC="true"> </front>
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/tlswg/external-psk-design-team"/>.</t>
</note>
</front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document provides guidance on the use of external Pre-Shared Keys (PSKs) <t>This document provides guidance on the use of external Pre-Shared Keys (PSKs)
in Transport Layer Security (TLS) 1.3 <xref target="RFC8446" format="default"/>. This guidance also in Transport Layer Security (TLS) 1.3 <xref target="RFC8446" format="default"/>. This guidance also
applies to Datagram TLS (DTLS) 1.3 <xref target="I-D.ietf-tls-dtls13" format="de fault"/> and applies to Datagram TLS (DTLS) 1.3 <xref target="RFC9147" format="default"/> and
Compact TLS 1.3 <xref target="I-D.ietf-tls-ctls" format="default"/>. For readabi lity, this document uses Compact TLS 1.3 <xref target="I-D.ietf-tls-ctls" format="default"/>. For readabi lity, this document uses
the term TLS to refer to all such versions.</t> the term "TLS" to refer to all such versions.</t>
<t>External PSKs are symmetric <t>External PSKs are symmetric
secret keys provided to the TLS protocol implementation as external inputs. secret keys provided to the TLS protocol implementation as external inputs.
External PSKs are provisioned out-of-band.</t> External PSKs are provisioned out of band.</t>
<t>This document lists <t>This document lists
TLS security properties provided by PSKs under certain assumptions and TLS security properties provided by PSKs under certain assumptions and
demonstrates how violations of these assumptions lead to attacks. This demonstrates how violations of these assumptions lead to attacks. This
document discusses PSK use cases, provisioning processes, and TLS stack document discusses PSK use cases, provisioning processes, and TLS stack
implementation support in the context of these assumptions. This document implementation support in the context of these assumptions.
This document
also provides advice for applications in various use cases to help meet also provides advice for applications in various use cases to help meet
these assumptions.</t> these assumptions.</t>
<t>There are many resources that provide guidance for password generation and <t>There are many resources that provide guidance for password generation and
verification aimed towards improving security. However, there is no such verification aimed towards improving security. However, there is no such
equivalent for external Pre-Shared Keys (PSKs) in TLS. This document aims equivalent for external PSKs in TLS. This document aims
to reduce that gap.</t> to reduce that gap.</t>
</section> </section>
<section anchor="conventions-and-definitions" numbered="true" toc="default"> <section anchor="conventions-and-definitions" numbered="true" toc="default">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", 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
document are to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
" format="default"/> <xref target="RFC8174" format="default"/> RECOMMENDED</bcp14>", "<bcp14>NOT 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
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default"> <section anchor="notation" numbered="true" toc="default">
<name>Notation</name> <name>Notation</name>
<t>For purposes of this document, a "logical node" is a computing presence that <t>For purposes of this document, a "logical node" is a computing presence that
other parties can interact with via the TLS protocol. A logical node could other parties can interact with via the TLS protocol. A logical node could
potentially be realized with multiple physical instances operating under common potentially be realized with multiple physical instances operating under common
administrative control, e.g., a server farm. An "endpoint" is a client or server administrative control, e.g., a server farm. An "endpoint" is a client or server
participating in a connection.</t> participating in a connection.</t>
</section> </section>
<section anchor="sec-properties" numbered="true" toc="default"> <section anchor="sec-properties" numbered="true" toc="default">
<name>PSK Security Properties</name> <name>PSK Security Properties</name>
<t>The use of a previously established PSK allows TLS nodes to authenticat e <t>The use of a previously established PSK allows TLS nodes to authenticat e
the endpoint identities. It also offers other benefits, including the endpoint identities. It also offers other benefits, including
resistance to attacks in presence of quantum computers; resistance to attacks in the presence of quantum computers;
see <xref target="entropy" format="default"/> for related discussion. However, t hese keys do not provide see <xref target="entropy" format="default"/> for related discussion. However, t hese keys do not provide
privacy protection of endpoint identities, nor do they provide non-repudiation privacy protection of endpoint identities, nor do they provide non-repudiation
(one endpoint in a connection can deny the conversation); see <xref target="endp oint-privacy" format="default"/> (one endpoint in a connection can deny the conversation); see <xref target="endp oint-privacy" format="default"/>
for related discussion.</t> for related discussion.</t>
<t>PSK authentication security implicitly assumes one fundamental property : each <t>PSK authentication security implicitly assumes one fundamental property : each
PSK is known to exactly one client and one server, and that these never switch PSK is known to exactly one client and one server and they never switch
roles. If this assumption is violated, then the security properties of TLS are roles. If this assumption is violated, then the security properties of TLS are
severely weakened as discussed below.</t> severely weakened as discussed below.</t>
<section anchor="shared-psks" numbered="true" toc="default"> <section anchor="shared-psks" numbered="true" toc="default">
<name>Shared PSKs</name> <name>Shared PSKs</name>
<t>As discussed in <xref target="use-cases" format="default"/>, to demon strate their attack, <xref target="AASS19" format="default"/> describes <t>As discussed in <xref target="use-cases" format="default"/>, to demon strate their attack, <xref target="AASS19" format="default"/> describes
scenarios where multiple clients or multiple servers share a PSK. If scenarios where multiple clients or multiple servers share a PSK. If
this is done naively by having all members share a common key, then this is done naively by having all members share a common key, then
TLS authenticates only group membership, and the security of the TLS authenticates only group membership, and the security of the
overall system is inherently rather brittle. There are a number of overall system is inherently rather brittle. There are a number of
obvious weaknesses here:</t> obvious weaknesses here:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Any group member can impersonate any other group member.</li> <li>Any group member can impersonate any other group member.</li>
<li>If PSK is combined with a fresh ephemeral key exchange, then compr
omise of a group member that knows <li>If a PSK is combined with the result of a fresh ephemeral key exch
the resulting shared secret will enable the attacker to passively read (and acti ange, then compromise of a group member that knows
vely modify) traffic.</li> the resulting shared secret will enable the attacker to passively read traffic (
<li>If PSK is not combined with fresh ephemeral key exchange, then com and actively modify it).</li>
promise of any group member allows the <li>If a PSK is not combined with the result of a fresh ephemeral key
attacker to passively read (and actively modify) all traffic, including reading exchange, then compromise of any group member allows the
past traffic.</li> attacker to passively read all traffic (and actively modify it), including past
traffic.</li>
</ol> </ol>
<t>Additionally, a malicious non-member can reroute handshakes between h onest group members <t>Additionally, a malicious non-member can reroute handshakes between h onest group members
to connect them in unintended ways, as described below. Note that a partial miti to connect them in unintended ways, as described below. Note that a partial miti
gation gation for
against this class of attack is available: each group member includes the SNI ex this class of attack is available: each group member includes the Server Name In
tension <xref target="RFC6066" format="default"/> dication (SNI) extension <xref target="RFC6066" format="default"/>
and terminates the connection on mismatch between the presented SNI value and th e and terminates the connection on mismatch between the presented SNI value and th e
receiving member's known identity. See <xref target="Selfie" format="default"/> receiving member's known identity. See <xref target="Selfie" format="defa
for details.</t> ult"/> for details.</t>
<t>To illustrate the rerouting attack, consider three peers, <tt>A</tt>, <tt>B</tt>, and <tt>C</tt>, <t>To illustrate the rerouting attack, consider three peers, <tt>A</tt>, <tt>B</tt>, and <tt>C</tt>,
who all know the PSK. The attack proceeds as follows:</t> who all know the PSK. The attack proceeds as follows:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
<tt>A</tt> sends a <tt>ClientHello</tt> to <tt>B</tt>.</li> <tt>A</tt> sends a <tt>ClientHello</tt> to <tt>B</tt>.</li>
<li>The attacker intercepts the message and redirects it to <tt>C</tt> .</li> <li>The attacker intercepts the message and redirects it to <tt>C</tt> .</li>
<li> <li>
<tt>C</tt> responds with a second flight (<tt>ServerHello</tt>, ...) to <tt>A</tt>.</li> <tt>C</tt> responds with a second flight (<tt>ServerHello</tt>, ...) to <tt>A</tt>.</li>
<li> <li>
<tt>A</tt> sends a <tt>Finished</tt> message to <tt>B</tt>. <tt>A</tt> sends a <tt>Finished</tt> message to <tt>B</tt>.
<tt>A</tt> has completed the handshake, ostensibly with <tt>B</tt>.</li> <tt>A</tt> has completed the handshake, ostensibly with <tt>B</tt>.</li>
<li>The attacker redirects the <tt>Finished</tt> message to <tt>C</tt> . <li>The attacker redirects the <tt>Finished</tt> message to <tt>C</tt> .
<tt>C</tt> has completed the handshake with <tt>A</tt>.</li> <tt>C</tt> has completed the handshake with <tt>A</tt>.</li>
</ol> </ol>
<t>In this attack, peer authentication is not provided. Also, if <tt>C</ tt> supports a <t>In this attack, peer authentication is not provided. Also, if <tt>C</ tt> supports a
weaker set of cipher suites than <tt>B</tt>, cryptographic algorithm downgrade a ttacks weaker set of ciphersuites than <tt>B</tt>, cryptographic algorithm downgrade at tacks
might be possible. This rerouting is a type of identity misbinding attack might be possible. This rerouting is a type of identity misbinding attack
<xref target="Krawczyk" format="default"/><xref target="Sethi" format="default"/ <xref target="Krawczyk" format="default"/> <xref target="Sethi" format="default"
>. Selfie attack <xref target="Selfie" format="default"/> is a special case of t />. Selfie attack <xref target="Selfie" format="default"/> is a special case of
he rerouting the rerouting
attack against a group member that can act both as TLS server and client. In the attack against a group member that can act as both a TLS server and a client. In
the
Selfie attack, a malicious non-member reroutes a connection from the client to Selfie attack, a malicious non-member reroutes a connection from the client to
the server on the same endpoint.</t> the server on the same endpoint.</t>
<t>Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively <t>Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively
affect deployments. For example, revocation of individual group members is not affect deployments. For example, revocation of individual group members is not
possible without establishing a new PSK for all of the non-revoked members.</t> possible without establishing a new PSK for all of the members that have not bee n revoked.</t>
</section> </section>
<section anchor="entropy" numbered="true" toc="default"> <section anchor="entropy" numbered="true" toc="default">
<name>PSK Entropy</name> <name>PSK Entropy</name>
<t>Entropy properties of external PSKs may also affect TLS security prop erties. For example, <t>Entropy properties of external PSKs may also affect TLS security prop erties. For example,
if a high entropy PSK is used, then PSK-only key establishment modes provide exp if a high-entropy PSK is used, then PSK-only key establishment modes provide exp
ected ected
security properties for TLS, including establishing the same security properties for TLS, including establishment of the same
session keys between peers, secrecy of session keys, peer authentication, and do wngrade session keys between peers, secrecy of session keys, peer authentication, and do wngrade
protection. See <xref section="E.1" sectionFormat="comma" target="RFC8446" forma t="default"/> for an explanation of these properties. protection. See <xref section="E.1" sectionFormat="of" target="RFC8446" format=" default"/> for an explanation of these properties.
However, these modes lack forward security. Forward security may be achieved by using a However, these modes lack forward security. Forward security may be achieved by using a
PSK-DH mode, or, alternatively, by using PSKs with short lifetimes.</t> PSK-DH mode or by using PSKs with short lifetimes.</t>
<t>In contrast, if a low entropy PSK is used, then PSK-only key establis <t>In contrast, if a low-entropy PSK is used, then PSK-only key establis
hment modes hment modes
are subject to passive exhaustive search attacks which will reveal the are subject to passive exhaustive search attacks, which will reveal the
traffic keys. PSK-DH modes are subject to active attacks in which the attacker traffic keys. PSK-DH modes are subject to active attacks in which the attacker
impersonates one side. The exhaustive search phase of these attacks can be mount ed impersonates one side. The exhaustive search phase of these attacks can be mount ed
offline if the attacker captures a single handshake using the PSK, but those offline if the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that connection beca use attacks will not lead to compromise of the traffic keys for that connection beca use
those also depend on the Diffie-Hellman (DH) exchange. Low entropy keys are only those also depend on the Diffie-Hellman (DH) exchange. Low-entropy keys are only
secure against active attack if a password-authenticated key exchange (PAKE) is secure against active attack if a Password-Authenticated Key Exchange (PAKE) is
used used
with TLS. The Crypto Forum Research Group (CFRG) is currently working on specify with TLS. At the time of writing, the Crypto Forum Research Group (CFRG) is work
ing ing on specifying
recommended PAKEs (see <xref target="I-D.irtf-cfrg-cpace" format="default"/> and recommended PAKEs (see <xref target="I-D.irtf-cfrg-cpace" format="default"/> and
<xref target="I-D.irtf-cfrg-opaque" format="default"/>, for <xref target="I-D.irtf-cfrg-opaque" format="default"/> for
the symmetric and asymmetric cases, respectively).</t> the symmetric and asymmetric cases, respectively).</t>
</section> </section>
</section> </section>
<section anchor="external-psks-in-practice" numbered="true" toc="default"> <section anchor="external-psks-in-practice" numbered="true" toc="default">
<name>External PSKs in Practice</name> <name>External PSKs in Practice</name>
<t>PSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral <t>PSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral
part of the TLS version 1.3 specification <xref target="RFC8446" format="default part of the TLS 1.3 specification <xref target="RFC8446" format="default"/>. TLS
"/>. TLS 1.3 also uses PSKs for session resumption. 1.3 also uses PSKs for session resumption.
It distinguishes these resumption PSKs from external PSKs which have been provis It distinguishes these resumption PSKs from external PSKs that have been provisi
ioned out-of-band. oned out of band.
This section describes known use cases and provisioning processes for external P SKs with TLS.</t> This section describes known use cases and provisioning processes for external P SKs with TLS.</t>
<section anchor="use-cases" numbered="true" toc="default"> <section anchor="use-cases" numbered="true" toc="default">
<name>Use Cases</name> <name>Use Cases</name>
<t>This section lists some example use-cases where pair-wise external PS <t>This section lists some example use cases where pairwise external PSK
Ks, i.e., external s (i.e., external
PSKs that are shared between only one server and one client, have been used for PSKs that are shared between only one server and one client) have been used for
authentication authentication
in TLS. There was no attempt to prioritize the examples in any particular order .</t> in TLS. There was no attempt to prioritize the examples in any particular order .</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Device-to-device communication with out-of-band synchronized keys.
PSKs provisioned out-of-band <li>Device-to-device communication with out-of-band synchronized keys.
PSKs provisioned out of band
for communicating with known identities, wherein the identity to use is discover ed via a different for communicating with known identities, wherein the identity to use is discover ed via a different
online protocol.</li> online protocol.</li>
<li>Intra-data-center communication. Machine-to-machine communication within a single data center <li>Intra-data-center communication. Machine-to-machine communication within a single data center
or point-of-presence (PoP) may use externally provisioned PSKs, primarily for th or Point of Presence (PoP) may use externally provisioned PSKs; this is primaril
e purposes of supporting TLS y for the purpose of supporting TLS
connections with early data; see <xref target="security-con" format="default"/> connections with early data. See <xref target="security-con" format="default"/>
for considerations when using early data for considerations when using early data
with external PSKs.</li> with external PSKs.</li>
<li>Certificateless server-to-server communication. Machine-to-machine communication <li>Certificateless server-to-server communication. Machine-to-machine communication
may use externally provisioned PSKs, primarily for the purposes of establishing TLS may use externally provisioned PSKs; this is primarily for the purposes of estab lishing TLS
connections without requiring the overhead of provisioning and managing PKI cert ificates.</li> connections without requiring the overhead of provisioning and managing PKI cert ificates.</li>
<li>Internet of Things (IoT) and devices with limited computational ca pabilities. <li>Internet of Things (IoT) and devices with limited computational ca pabilities.
<xref target="RFC7925" format="default"/> defines TLS and DTLS profiles for reso urce-constrained devices and suggests <xref target="RFC7925" format="default"/> defines TLS and DTLS profiles for reso urce-constrained devices and suggests
the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Ligh the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Ligh
tweight Machine tweight Machine-to-Machine (LwM2M) Technical Specification <xref target="LwM2M"
to Machine Technical Specification <xref target="LwM2M" format="default"/> state format="default"/> states that LwM2M servers <bcp14>MUST</bcp14> support the
s that LwM2M servers MUST support the
PSK mode of DTLS.</li> PSK mode of DTLS.</li>
<li>Securing RADIUS <xref target="RFC2865" format="default"/> with TLS . PSK ciphersuites are optional for this use case, as specified <li>Securing RADIUS <xref target="RFC2865" format="default"/> with TLS . PSK ciphersuites are optional for this use case, as specified
in <xref target="RFC6614" format="default"/>.</li> in <xref target="RFC6614" format="default"/>.</li>
<li>3GPP server to user equipment authentication. The Generic Authenti
cation Architecture (GAA) defined by <li>3GPP server-to-user equipment authentication. The Generic Authenti
3GGP mentions that TLS-PSK ciphersuites can be used between server and user equi cation Architecture (GAA) defined by
pment for authentication <xref target="GAA" format="default"/>.</li> 3GPP mentions that TLS PSK ciphersuites can be used between server and
<li>Smart Cards. The electronic German ID (eID) card supports authenti user equipment for authentication <xref target="GAA" format="default"/>.</li>
cation of a card holder to
online services with TLS-PSK <xref target="SmartCard" format="default"/>.</li> <li>Smart Cards. The German electronic Identity (eID) card supports au
thentication of a card holder to
online services with TLS PSK <xref target="SmartCard" format="default"/>.</li>
<li>Quantum resistance. Some deployments may use PSKs (or combine them with certificate-based <li>Quantum resistance. Some deployments may use PSKs (or combine them with certificate-based
authentication as described in <xref target="RFC8773" format="default"/>) becaus e of the protection they provide against authentication as described in <xref target="RFC8773" format="default"/>) becaus e of the protection they provide against
quantum computers.</li> quantum computers.</li>
</ul> </ul>
<t>There are also use cases where PSKs are shared between more than two entities. Some examples below <t>There are also use cases where PSKs are shared between more than two entities. Some examples below
(as noted by Akhmetzyanova et al. <xref target="AASS19" format="default"/>):</t> (as noted by Akhmetzyanova, et al. <xref target="AASS19" format="default"/>):</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Group chats. In this use-case, group participants may be provision ed an external PSK out-of-band for establishing <li>Group chats. In this use case, group participants may be provision ed an external PSK out of band for establishing
authenticated connections with other members of the group.</li> authenticated connections with other members of the group.</li>
<li>Internet of Things (IoT) and devices with limited computational ca <li>IoT and devices with limited computational capabilities. Many PSK
pabilities. Many PSK provisioning examples are provisioning examples are
possible in this use-case. For example, in a given setting, IoT devices may all possible in this use case. For example, in a given setting, IoT devices may all
share the same PSK and use it to share the same PSK and use it to
communicate with a central server (one key for n devices), have their own key fo r communicating with a central server (n communicate with a central server (one key for n devices), have their own key fo r communicating with a central server (n
keys for n devices), or have pairwise keys for communicating with each other (n^ 2 keys for n devices).</li> keys for n devices), or have pairwise keys for communicating with each other (n< sup>2</sup> keys for n devices).</li>
</ul> </ul>
</section> </section>
<section anchor="provisioning-examples" numbered="true" toc="default"> <section anchor="provisioning-examples" numbered="true" toc="default">
<name>Provisioning Examples</name> <name>Provisioning Examples</name>
<t>The exact provisioning process depends on the system requirements and threat <t>The exact provisioning process depends on the system requirements and threat
model. Whenever possible, avoid sharing a PSK between nodes; however, sharing model. Whenever possible, avoid sharing a PSK between nodes; however, sharing
a PSK among several nodes is sometimes unavoidable. When PSK sharing happens, a PSK among several nodes is sometimes unavoidable. When PSK sharing happens,
other accommodations SHOULD be used as discussed in <xref target="recommendation s" format="default"/>.</t> other accommodations <bcp14>SHOULD</bcp14> be used as discussed in <xref target= "recommendations" format="default"/>.</t>
<t>Examples of PSK provisioning processes are included below.</t> <t>Examples of PSK provisioning processes are included below.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Many industrial protocols assume that PSKs are distributed and ass igned manually via one of the following <li>Many industrial protocols assume that PSKs are distributed and ass igned manually via one of the following
approaches: typing the PSK into the devices, or using a Trust On First Use (TOFU approaches: (1) typing the PSK into the devices or (2) using a trust-on-first-us
) approach with a device e (TOFU) approach with a device
completely unprotected before the first login did take place. Many devices have completely unprotected before the first login took place. Many devices have a ve
very limited UI. For example, ry limited UI. For example,
they may only have a numeric keypad or even fewer buttons. When the TOFU approac h is not suitable, they may only have a numeric keypad or even fewer buttons. When the TOFU approac h is not suitable,
entering the key would require typing it on a constrained UI.</li> entering the key would require typing it on a constrained UI.</li>
<li>Some devices provision PSKs via an out-of-band, cloud-based syncin g protocol.</li> <li>Some devices provision PSKs via an out-of-band, cloud-based syncin g protocol.</li>
<li>Some secrets may be baked into hardware or software device compone nts. Moreover, when this is done <li>Some secrets may be baked into hardware or software device compone nts. Moreover, when this is done
at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of
scanning or import.</li> scanning or import.</li>
</ul> </ul>
</section> </section>
<section anchor="provisioning-constraints" numbered="true" toc="default"> <section anchor="provisioning-constraints" numbered="true" toc="default">
<name>Provisioning Constraints</name> <name>Provisioning Constraints</name>
<t>PSK provisioning systems are often constrained in application-specifi c ways. For example, although one goal of <t>PSK provisioning systems are often constrained in application-specifi c ways. For example, although one goal of
provisioning is to ensure that each pair of nodes has a unique key pair, some sy stems do not want to distribute provisioning is to ensure that each pair of nodes has a unique key pair, some sy stems do not want to distribute
pair-wise shared keys to achieve this. As another example, some systems require the provisioning process to embed pairwise shared keys to achieve this. As another example, some systems require t he provisioning process to embed
application-specific information in either PSKs or their identities. Identities may sometimes need to be routable, application-specific information in either PSKs or their identities. Identities may sometimes need to be routable,
as is currently under discussion for EAP-TLS-PSK <xref target="I-D.mattsson-emu- eap-tls-psk" format="default"/>.</t> as is currently under discussion for <xref target="I-D.mattsson-emu-eap-tls-psk" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="recommendations" numbered="true" toc="default"> <section anchor="recommendations" numbered="true" toc="default">
<name>Recommendations for External PSK Usage</name> <name>Recommendations for External PSK Usage</name>
<t>Recommended requirements for applications using external PSKs are as fo llows:</t> <t>Recommended requirements for applications using external PSKs are as fo llows:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Each PSK SHOULD be derived from at least 128 bits of entropy, MUST b <li>Each PSK <bcp14>SHOULD</bcp14> be derived from at least 128 bits of
e at least entropy, <bcp14>MUST</bcp14> be at least
128 bits long, and SHOULD be combined with an ephemeral key exchange, e.g., by u 128 bits long, and <bcp14>SHOULD</bcp14> be combined with an ephemeral key excha
sing the nge, e.g., by using the
"psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3, for forward secrecy. As "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3 for forward secrecy. As
discussed in <xref target="sec-properties" format="default"/>, low entropy PSKs, discussed in <xref target="sec-properties" format="default"/>, low-entropy PSKs
i.e., those derived from less (i.e., those derived from less
than 128 bits of entropy, are subject to attack and SHOULD be avoided. If only than 128 bits of entropy) are subject to attack and <bcp14>SHOULD</bcp14> be avo
low-entropy keys are available, then key establishment mechanisms such as Passwo ided. If only
rd low-entropy keys are available, then key establishment mechanisms such as PAKE t
Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary a hat mitigate the risk of offline dictionary attacks
ttacks <bcp14>SHOULD</bcp14> be employed. Note that no such mechanisms have yet been st
SHOULD be employed. Note that no such mechanisms have yet been standardised, and andardized, and further
further
that these mechanisms will not necessarily follow the same architecture as the that these mechanisms will not necessarily follow the same architecture as the
process for incorporating external PSKs described in <xref target="I-D.ietf-tls- process for incorporating external PSKs described in <xref target="RFC9258" form
external-psk-importer" format="default"/>.</li> at="default"/>.</li>
<li>Unless other accommodations are made to mitigate the risks of PSKs k <li>Unless other accommodations are made to mitigate the risks of PSKs k
nown to a group, each PSK MUST be restricted in nown to a group, each PSK <bcp14>MUST</bcp14> be restricted in
its use to at most two logical nodes: one logical node in a TLS client its use to at most two logical nodes: one logical node in a TLS client
role and one logical node in a TLS server role. (The two logical nodes role and one logical node in a TLS server role. (The two logical nodes
MAY be the same, in different roles.) Two acceptable accommodations <bcp14>MAY</bcp14> be the same, in different roles.) Two acceptable accommodatio
are described in <xref target="I-D.ietf-tls-external-psk-importer" format="defau ns
lt"/>: (1) exchanging are described in <xref target="RFC9258" format="default"/>: (1) exchanging
client and server identifiers over the TLS connection after the client and server identifiers over the TLS connection after the
handshake, and (2) incorporating identifiers for both the client and the handshake and (2) incorporating identifiers for both the client and the
server into the context string for an external PSK importer.</li> server into the context string for an external PSK importer.</li>
<li>Nodes SHOULD use external PSK importers <xref target="I-D.ietf-tls-e xternal-psk-importer" format="default"/> <li>Nodes <bcp14>SHOULD</bcp14> use external PSK importers <xref target= "RFC9258" format="default"/>
when configuring PSKs for a client-server pair when applicable. Importers make p rovisioning when configuring PSKs for a client-server pair when applicable. Importers make p rovisioning
external PSKs easier and less error prone by deriving a unique, imported PSK fro external PSKs easier and less error-prone by deriving a unique, imported PSK fro
m the m the
external PSK for each key derivation function a node supports. See the Security external PSK for each key derivation function a node supports. See the Security
Considerations Considerations of
in <xref target="I-D.ietf-tls-external-psk-importer" format="default"/> for more <xref target="RFC9258" format="default"/> for more information.</li>
information.</li> <li>Where possible, the main PSK (that which is fed into the importer) <
<li>Where possible the main PSK (that which is fed into the importer) SH bcp14>SHOULD</bcp14> be
OULD be
deleted after the imported keys have been generated. This prevents an attacker deleted after the imported keys have been generated. This prevents an attacker
from bootstrapping a compromise of one node into the ability to attack connectio ns from bootstrapping a compromise of one node into the ability to attack connectio ns
between any node; otherwise the attacker can recover the main key and then between any node; otherwise, the attacker can recover the main key and then
re-run the importer itself.</li> re-run the importer itself.</li>
</ol> </ol>
<section anchor="stack-interfaces" numbered="true" toc="default"> <section anchor="stack-interfaces" numbered="true" toc="default">
<name>Stack Interfaces</name> <name>Stack Interfaces</name>
<t>Most major TLS implementations support external PSKs. Stacks supporti ng external PSKs <t>Most major TLS implementations support external PSKs. Stacks supporti ng external PSKs
provide interfaces that applications may use when configuring PSKs for individua l provide interfaces that applications may use when configuring PSKs for individua l
connections. Details about some existing stacks at the time of writing are below .</t> connections. Details about some existing stacks at the time of writing are below .</t>
<ul spacing="normal"> <ul spacing="normal">
<li>OpenSSL and BoringSSL: Applications can specify support for extern al PSKs via <li>OpenSSL and BoringSSL: Applications can specify support for extern al PSKs via
distinct ciphersuites in TLS 1.2 and below. They also then configure callbacks t hat are invoked for distinct ciphersuites in TLS 1.2 and below. Also, they can then configure callba cks that are invoked for
PSK selection during the handshake. These callbacks must provide a PSK identity and key. The PSK selection during the handshake. These callbacks must provide a PSK identity and key. The
exact format of the callback depends on the negotiated TLS protocol version, wit h new callback exact format of the callback depends on the negotiated TLS protocol version, wit h new callback
functions added specifically to OpenSSL for TLS 1.3 <xref target="RFC8446" forma functions added specifically to OpenSSL for TLS 1.3 <xref target="RFC8446" forma
t="default"/> PSK support. The PSK length t="default"/> PSK support. The PSK length is validated to be between 1-256 bytes
is validated to be between [1, 256] bytes. The PSK identity may be up to 128 byt (inclusive). The PSK identity may be up to 128 bytes long.</li>
es long.</li>
<li>mbedTLS: Client applications configure PSKs before creating a conn ection by providing the PSK <li>mbedTLS: Client applications configure PSKs before creating a conn ection by providing the PSK
identity and value inline. Servers must implement callbacks similar to that of O penSSL. Both PSK identity and value inline. Servers must implement callbacks similar to that of O penSSL. Both PSK
identity and key lengths may be between [1, 16] bytes long.</li> identity and key lengths may be between 1-16 bytes long (inclusive).</li>
<li>gnuTLS: Applications configure PSK values, either as raw byte stri <li>gnuTLS: Applications configure PSK values as either raw byte strin
ngs or gs or
hexadecimal strings. The PSK identity and key size are not validated.</li> hexadecimal strings. The PSK identity and key size are not validated.</li>
<li>wolfSSL: Applications configure PSKs with callbacks similar to Ope nSSL.</li> <li>wolfSSL: Applications configure PSKs with callbacks similar to Ope nSSL.</li>
</ul> </ul>
<section anchor="psk-identity-encoding-and-comparison" numbered="true" t oc="default"> <section anchor="psk-identity-encoding-and-comparison" numbered="true" t oc="default">
<name>PSK Identity Encoding and Comparison</name> <name>PSK Identity Encoding and Comparison</name>
<t>Section 5.1 of <xref target="RFC4279" format="default"/> mandates t hat the PSK identity should be first converted to a character string and then <t><xref target="RFC4279" sectionFormat="of" section="5.1"/> mandates that the PSK identity should be first converted to a character string and then
encoded to octets using UTF-8. This was done to avoid interoperability problems (especially when the identity is encoded to octets using UTF-8. This was done to avoid interoperability problems (especially when the identity is
configured by human users). On the other hand, <xref target="RFC7925" format="d efault"/> advises implementations against assuming any structured configured by human users). On the other hand, <xref target="RFC7925" format="d efault"/> advises implementations against assuming any structured
format for PSK identities and recommends byte-by-byte comparison for any operati on. When PSK identities are configured format for PSK identities and recommends byte-by-byte comparison for any operati on. When PSK identities are configured
manually it is important to be aware that due to encoding issues visually identi manually, it is important to be aware that visually identical strings may, in fa
cal strings may, in fact, differ.</t> ct, differ due to encoding issues.</t>
<t>TLS version 1.3 <xref target="RFC8446" format="default"/> follows t <t>TLS 1.3 <xref target="RFC8446" format="default"/> follows the same
he same practice of specifying practice of specifying
the PSK identity as a sequence of opaque bytes (shown as opaque identity&lt;1..2 ^16-1&gt; the PSK identity as a sequence of opaque bytes (shown as opaque identity&lt;1..2 ^16-1&gt;
in the specification) that thus is compared on a byte-by-byte basis. in the specification) that thus is compared on a byte-by-byte basis.
<xref target="RFC8446" format="default"/> also requires that the PSK identities are at <xref target="RFC8446" format="default"/> also requires that the PSK identities are at
least 1 byte and at the most 65535 bytes in length. Although <xref target="RFC84 46" format="default"/> does not least 1 byte and at the most 65535 bytes in length. Although <xref target="RFC84 46" format="default"/> does not
place strict requirements on the format of PSK identities, we do however note th at place strict requirements on the format of PSK identities, note that
the format of PSK identities can vary depending on the deployment:</t> the format of PSK identities can vary depending on the deployment:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The PSK identity MAY be a user configured string when used in pr <li>The PSK identity <bcp14>MAY</bcp14> be a user-configured string
otocols like when used in protocols like
Extensible Authentication Protocol (EAP) <xref target="RFC3748" format="default" Extensible Authentication Protocol (EAP) <xref target="RFC3748" format="default"
/>. gnuTLS for example treats />. For example, gnuTLS treats
PSK identities as usernames.</li> PSK identities as usernames.</li>
<li>PSK identities MAY have a domain name suffix for roaming and fed eration. In <li>PSK identities <bcp14>MAY</bcp14> have a domain name suffix for roaming and federation. In
applications and settings where the domain name suffix is privacy sensitive, thi s applications and settings where the domain name suffix is privacy sensitive, thi s
practice is NOT RECOMMENDED.</li> practice is <bcp14>NOT RECOMMENDED</bcp14>.</li>
<li>Deployments should take care that the length of the PSK identity is sufficient <li>Deployments should take care that the length of the PSK identity is sufficient
to avoid collisions.</li> to avoid collisions.</li>
</ul> </ul>
</section> </section>
<section anchor="psk-identity-collisions" numbered="true" toc="default"> <section anchor="psk-identity-collisions" numbered="true" toc="default">
<name>PSK Identity Collisions</name> <name>PSK Identity Collisions</name>
<t>It is possible, though unlikely, that an external PSK identity may clash with a <t>It is possible, though unlikely, that an external PSK identity may clash with a
resumption PSK identity. The TLS stack implementation and sequencing of PSK call backs resumption PSK identity. The TLS stack implementation and sequencing of PSK call backs
influences the application's behavior when identity collisions occur. When a ser ver influences the application's behavior when identity collisions occur. When a ser ver
receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks
execute the application's registered callback function before checking the stack 's execute the application's registered callback function before checking the stack 's
internal session resumption cache. This means that if a PSK identity collision o ccurs, internal session resumption cache. This means that if a PSK identity collision o ccurs,
the application's external PSK usage will typically take precedence over the int ernal the application's external PSK usage will typically take precedence over the int ernal
session resumption path.</t> session resumption path.</t>
<t>Since resumption PSK identities are assigned by the TLS stack imple <t>Because resumption PSK identities are assigned by the TLS stack imp
mentation, lementation,
it is RECOMMENDED that these identifiers be assigned in a manner that lets it is <bcp14>RECOMMENDED</bcp14> that these identifiers be assigned in a manner
that lets
resumption PSKs be distinguished from external PSKs to avoid concerns with resumption PSKs be distinguished from external PSKs to avoid concerns with
collisions altogether.</t> collisions altogether.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="endpoint-privacy" numbered="true" toc="default"> <section anchor="endpoint-privacy" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>PSK privacy properties are orthogonal to security properties described in <xref target="sec-properties" format="default"/>. <t>PSK privacy properties are orthogonal to security properties described in <xref target="sec-properties" format="default"/>.
TLS does little to keep PSK identity information private. For example, TLS does little to keep PSK identity information private. For example,
an adversary learns information about the external PSK or its identifier by virt ue of the identifier an adversary learns information about the external PSK or its identifier by virt ue of the identifier
skipping to change at line 367 skipping to change at line 370
<t>In addition to linkability in the network, external PSKs are intrinsica lly linkable <t>In addition to linkability in the network, external PSKs are intrinsica lly linkable
by PSK receivers. Specifically, servers can link successive connections that use the by PSK receivers. Specifically, servers can link successive connections that use the
same external PSK together. Preventing this type of linkability is out of scope. </t> same external PSK together. Preventing this type of linkability is out of scope. </t>
</section> </section>
<section anchor="security-con" numbered="true" toc="default"> <section anchor="security-con" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Security considerations are provided throughout this document. It bear s <t>Security considerations are provided throughout this document. It bear s
repeating that there are concerns related to the use of external PSKs regarding repeating that there are concerns related to the use of external PSKs regarding
proper identification of TLS 1.3 endpoints and additional risks when external proper identification of TLS 1.3 endpoints and additional risks when external
PSKs are known to a group.</t> PSKs are known to a group.</t>
<t>It is NOT RECOMMENDED to share the same PSK between more than one clien t and server. <t>It is <bcp14>NOT RECOMMENDED</bcp14> to share the same PSK between more than one client and server.
However, as discussed in <xref target="use-cases" format="default"/>, there are application scenarios that may However, as discussed in <xref target="use-cases" format="default"/>, there are application scenarios that may
rely on sharing the same PSK among multiple nodes. <xref target="I-D.ietf-tls-ex rely on sharing the same PSK among multiple nodes. <xref target="RFC9258" format
ternal-psk-importer" format="default"/> ="default"/>
helps in mitigating rerouting and Selfie style reflection attacks when the PSK helps in mitigating rerouting and Selfie-style reflection attacks when the PSK
is shared among multiple nodes. This is achieved by correctly using the node is shared among multiple nodes. This is achieved by correctly using the node
identifiers in the ImportedIdentity.context construct specified in identifiers in the ImportedIdentity.context construct specified in
<xref target="I-D.ietf-tls-external-psk-importer" format="default"/>. One soluti <xref target="RFC9258" format="default"/>. One solution would be for each endpoi
on would be for each endpoint nt
to select one globally unique identifier and use it in all PSK handshakes. The to select one globally unique identifier to use in all PSK handshakes. The
unique identifier can, for example, be one of its MAC addresses, a 32-byte unique identifier can, for example, be one of its Media Access Control (MAC) add
resses, a 32-byte
random number, or its Universally Unique IDentifier (UUID) <xref target="RFC4122 " format="default"/>. random number, or its Universally Unique IDentifier (UUID) <xref target="RFC4122 " format="default"/>.
Note that such persistent, global identifiers have privacy implications; Note that such persistent, global identifiers have privacy implications;
see <xref target="endpoint-privacy" format="default"/>.</t> see <xref target="endpoint-privacy" format="default"/>.</t>
<t>Each endpoint SHOULD know the identifier of the other endpoint with whi <t>Each endpoint <bcp14>SHOULD</bcp14> know the identifier of the other en
ch it wants dpoint with which it wants
to connect and SHOULD compare it with the other endpoint's identifier used in to connect and <bcp14>SHOULD</bcp14> compare it with the other endpoint's identi
ImportedIdentity.context. It is however important to remember that endpoints fier used in
ImportedIdentity.context. However, it is important to remember that endpoints
sharing the same group PSK can always impersonate each other.</t> sharing the same group PSK can always impersonate each other.</t>
<t>Considerations for external PSK usage extend beyond proper identificati on. <t>Considerations for external PSK usage extend beyond proper identificati on.
When early data is used with an external PSK, the random value in the ClientHell o When early data is used with an external PSK, the random value in the ClientHell o
is the only source of entropy that contributes to key diversity between sessions . is the only source of entropy that contributes to key diversity between sessions .
As a result, when an external PSK is used more than one time, the random number As a result, when an external PSK is used more than one time, the random number
source on the client has a significant role in the protection of the early data. </t> source on the client has a significant role in the protection of the early data. </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no IANA requests.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-tls-ctls" to="CTLS"/>
<displayreference target="I-D.irtf-cfrg-cpace" to="CPACE"/>
<displayreference target="I-D.irtf-cfrg-opaque" to="OPAQUE"/>
<displayreference target="I-D.mattsson-emu-eap-tls-psk" to="EAP-TLS-PSK"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<seriesInfo name="RFC" value="8446"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-tls-external-psk-importer" target="https://w
ww.ietf.org/archive/id/draft-ietf-tls-external-psk-importer-06.txt">
<front>
<title>Importing External PSKs for TLS</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-external-psk
-importer-06"/>
<author fullname="David Benjamin">
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="3" month="December" year="2020"/>
<abstract>
<t> This document describes an interface for importing external
Pre-
Shared Keys (PSKs) into TLS 1.3.
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</reference> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
xml"/>
<reference anchor="RFC9258" target="https://www.rfc-editor.org/info/rfc9258">
<front>
<title>Importing External Pre-Shared Keys (PSKs) for TLS 1.3</title>
<author initials='D' surname='Benjamin' fullname='David Benjamin'>
<organization/>
</author>
<author initials='C. A.' surname='Wood' fullname='Christopher Wood'>
<organization/>
</author>
<date month='July' year='2022'/>
</front>
<seriesInfo name="RFC" value="9258"/>
<seriesInfo name="DOI" value="10.17487/RFC9258"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8773" target="https://www.rfc-editor.org/info/rfc8
773">
<front>
<title>TLS 1.3 Extension for Certificate-Based Authentication with a
n External Pre-Shared Key</title>
<seriesInfo name="DOI" value="10.17487/RFC8773"/>
<seriesInfo name="RFC" value="8773"/>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<date month="March" year="2020"/>
<abstract>
<t>This document specifies a TLS 1.3 extension that allows a serve
r to authenticate with a combination of a certificate and an external pre-shared
key (PSK).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7925" target="https://www.rfc-editor.org/info/rfc7
925">
<front>
<title>Transport Layer Security (TLS) / Datagram Transport Layer Sec
urity (DTLS) Profiles for the Internet of Things</title>
<seriesInfo name="DOI" value="10.17487/RFC7925"/>
<seriesInfo name="RFC" value="7925"/>
<author fullname="H. Tschofenig" initials="H." role="editor" surname
="Tschofenig">
<organization/>
</author>
<author fullname="T. Fossati" initials="T." surname="Fossati">
<organization/>
</author>
<date month="July" year="2016"/>
<abstract>
<t>A common design pattern in Internet of Things (IoT) deployments
is the use of a constrained device that collects data via sensors or controls a
ctuators for use in home automation, industrial control systems, smart cities, a
nd other IoT deployments.</t>
<t>This document defines a Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS) 1.2 profile that offers communications secu
rity for this data exchange thereby preventing eavesdropping, tampering, and mes
sage forgery. The lack of communication security is a common vulnerability in I
oT products that can easily be solved by using these well-researched and widely
deployed Internet security protocols.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6
066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
<seriesInfo name="RFC" value="6066"/>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd">
<organization/>
</author>
<date month="January" year="2011"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS
) Protocol Version 1.2". The extensions specified are server_name, max_fragment
_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_req
uest. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6614" target="https://www.rfc-editor.org/info/rfc6
614">
<front>
<title>Transport Layer Security (TLS) Encryption for RADIUS</title>
<seriesInfo name="DOI" value="10.17487/RFC6614"/>
<seriesInfo name="RFC" value="6614"/>
<author fullname="S. Winter" initials="S." surname="Winter">
<organization/>
</author>
<author fullname="M. McCauley" initials="M." surname="McCauley">
<organization/>
</author>
<author fullname="S. Venaas" initials="S." surname="Venaas">
<organization/>
</author>
<author fullname="K. Wierenga" initials="K." surname="Wierenga">
<organization/>
</author>
<date month="May" year="2012"/>
<abstract>
<t>This document specifies a transport profile for RADIUS using Tr
ansport Layer Security (TLS) over TCP as the transport protocol. This enables dy
namic trust relationships between RADIUS servers. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4122" target="https://www.rfc-editor.org/info/rfc4
122">
<front>
<title>A Universally Unique IDentifier (UUID) URN Namespace</title>
<seriesInfo name="DOI" value="10.17487/RFC4122"/>
<seriesInfo name="RFC" value="4122"/>
<author fullname="P. Leach" initials="P." surname="Leach">
<organization/>
</author>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization/>
</author>
<author fullname="R. Salz" initials="R." surname="Salz">
<organization/>
</author>
<date month="July" year="2005"/>
<abstract>
<t>This specification defines a Uniform Resource Name namespace fo
r UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique ID
entifier). A UUID is 128 bits long, and can guarantee uniqueness across space a
nd time. UUIDs were originally used in the Apollo Network Computing System and
later in the Open Software Foundation\'s (OSF) Distributed Computing Environment
(DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the DCE specification with t
he kind permission of the OSF (now known as The Open Group). Information from e
arlier versions of the DCE specification have been incorporated into this docume
nt. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2
865">
<front>
<title>Remote Authentication Dial In User Service (RADIUS)</title>
<seriesInfo name="DOI" value="10.17487/RFC2865"/>
<seriesInfo name="RFC" value="2865"/>
<author fullname="C. Rigney" initials="C." surname="Rigney">
<organization/>
</author>
<author fullname="S. Willens" initials="S." surname="Willens">
<organization/>
</author>
<author fullname="A. Rubens" initials="A." surname="Rubens">
<organization/>
</author>
<author fullname="W. Simpson" initials="W." surname="Simpson">
<organization/>
</author>
<date month="June" year="2000"/>
<abstract>
<t>This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access Server wh
ich desires to authenticate its links and a shared Authentication Server. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-tls-dtls13" target="https://www.ietf.org/arc
hive/id/draft-ietf-tls-dtls13-43.txt">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>
<author fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
</author>
<author fullname="Nagendra Modadugu">
<organization>Google, Inc.</organization>
</author>
<date day="30" month="April" year="2021"/>
<abstract>
<t> This document specifies Version 1.3 of the Datagram Transpor
t Layer
Security (DTLS) protocol. DTLS 1.3 allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is intentionally based on the Transport Layer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8773.
Security (TLS) 1.3 protocol and provides equivalent security xml"/>
guarantees with the exception of order protection/non-replayability. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7925.
Datagram semantics of the underlying transport are preserved by the xml"/>
DTLS protocol. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6614.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4122.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.
xml"/>
This document obsoletes RFC 6347. <!-- [I-D.ietf-tls-dtls13] [RFCYYY2] is now RFC 9147 -->
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9147.xml"
/>
</t> <!-- [I-D.ietf-tls-ctls] I-D Exists status as of 7/22/22-->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tl
</front> s-ctls.xml"/>
</reference>
<reference anchor="I-D.ietf-tls-ctls" target="https://www.ietf.org/archi
ve/id/draft-ietf-tls-ctls-04.txt">
<front>
<title>Compact TLS 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-ctls-04"/>
<author fullname="Eric Rescorla">
<organization>Mozilla</organization>
</author>
<author fullname="Richard Barnes">
<organization>Cisco</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
</author>
<date day="25" month="October" year="2021"/>
<abstract>
<t> This document specifies a "compact" version of TLS 1.3. It
is
isomorphic to TLS 1.3 but saves space by trimming obsolete material,
tighter encoding, a template-based specialization technique, and
alternative cryptographic techniques. cTLS is not directly
interoperable with TLS 1.3, but it should eventually be possible for
a cTLS/TLS 1.3 server to exist and successfully interoperate.
</t> <!-- [I-D.irtf-cfrg-cpace] I-D Exists status as of 7/22/22 -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
</front> rtf-cfrg-cpace.xml"/>
</reference>
<reference anchor="I-D.irtf-cfrg-cpace" target="https://www.ietf.org/arc
hive/id/draft-irtf-cfrg-cpace-05.txt">
<front>
<title>CPace, a balanced composable PAKE</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-cpace-05"/>
<author fullname="Michel Abdalla">
<organization>DFINITY - Zurich</organization>
</author>
<author fullname="Bjoern Haase">
<organization>Endress + Hauser Liquid Analysis - Gerlingen</organi
zation>
</author>
<author fullname="Julia Hesse">
<organization>IBM Research Europe - Zurich</organization>
</author>
<date day="14" month="January" year="2022"/>
<abstract>
<t> This document describes CPace which is a protocol for two pa
rties
that share a low-entropy secret (password) to derive a strong shared
key without disclosing the secret to offline dictionary attacks.
This method was tailored for constrained devices, is compatible with
any group of both prime- and non-prime order, and comes with a
security proof providing composability guarantees.
</t> <!-- [I-D.irtf-cfrg-opaque] I-D Exists status as of 7/22/22 -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-i
</front> rtf-cfrg-opaque.xml"/>
</reference>
<reference anchor="I-D.irtf-cfrg-opaque" target="https://www.ietf.org/ar
chive/id/draft-irtf-cfrg-opaque-07.txt">
<front>
<title>The OPAQUE Asymmetric PAKE Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-opaque-07"/
>
<author fullname="Daniel Bourdrez">
</author>
<author fullname="Hugo Krawczyk">
<organization>Algorand Foundation</organization>
</author>
<author fullname="Kevin Lewi">
<organization>Novi Research</organization>
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="25" month="October" year="2021"/>
<abstract>
<t> This document describes the OPAQUE protocol, a secure asymme
tric
password-authenticated key exchange (aPAKE) that supports mutual
authentication in a client-server setting without reliance on PKI and
with security against pre-computation attacks upon server compromise.
In addition, the protocol provides forward secrecy and the ability to
hide the password from the server, even during password registration.
This document specifies the core OPAQUE protocol and one
instantiation based on 3DH.
</t> <!-- [draft-mattsson-emu-eap-tls-psk] This reference has expired -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.mattsso
</front> n-emu-eap-tls-psk.xml"/>
</reference>
<reference anchor="I-D.mattsson-emu-eap-tls-psk" target="https://www.iet
f.org/archive/id/draft-mattsson-emu-eap-tls-psk-00.txt">
<front>
<title>EAP-TLS with PSK Authentication (EAP-TLS-PSK)</title>
<seriesInfo name="Internet-Draft" value="draft-mattsson-emu-eap-tls-
psk-00"/>
<author fullname="John Preuß Mattsson">
<organization>Ericsson</organization>
</author>
<author fullname="Mohit Sethi">
<organization>Ericsson</organization>
</author>
<author fullname="Tuomas Aura">
<organization>Aalto University</organization>
</author>
<author fullname="Owen Friel">
<organization>Cisco</organization>
</author>
<date day="9" month="March" year="2020"/>
<abstract>
<t> While TLS 1.3 supports authentication with Pre-Shared Key (P
SK), EAP-
TLS with TLS 1.3 explicitly forbids PSK authentication except when
used for resumption. This document specifies a separate EAP method
(EAP-TLS-PSK) for use cases that require authentication based on
external PSKs.
</t> <reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf">
</abstract> <front>
</front> <title>Selfie: reflections on TLS 1.3 with PSK</title>
</reference> <author initials="N" surname="Drucker" fullname="Nir Drucker">
<reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf" <organization />
> </author>
<front> <author initials="S" surname="Gueron" fullname="Shay Gueron">
<title>Selfie: reflections on TLS 1.3 with PSK</title> <organization />
<author initials="N." surname="Drucker" fullname="Nir Drucker"> </author>
<organization/> <date month="May" year="2021"/>
</author> </front>
<author initials="S." surname="Gueron" fullname="Shay Gueron"> <seriesInfo name="DOI" value="10.1007/s00145-021-09387-y"/>
<organization/> </reference>
</author>
<date year="2019"/> <reference anchor="AASS19" target="https://eprint.iacr.org/2019/421.pdf">
</front> <front>
</reference> <title>Continuing to reflect on TLS 1.3 with external PSK</title>
<reference anchor="AASS19" target="https://eprint.iacr.org/2019/421.pdf" <author initials="L" surname="Akhmetzyanova" fullname="Liliya Akhmetzy
> anov">
<front> <organization />
<title>Continuing to reflect on TLS 1.3 with external PSK</title> </author>
<author initials="L." surname="Akhmetzyanova" fullname="Liliya Akhme <author initials="E" surname="Alekseev" fullname="Evgeny Alekseev">
tzyanova"> <organization />
<organization/> </author>
</author> <author initials="E" surname="Smyshlyaeva" fullname="Ekaterina Smyshly
<author initials="E." surname="Alekseev" fullname="Evgeny Alekseev"> aeva">
<organization/> <organization />
</author> </author>
<author initials="E." surname="Smyshlyaeva" fullname="Ekaterina Smys <author initials="A" surname="Sokolov" fullname="Alexandr Sokolov">
hlyaeva"> <organization />
<organization/> </author>
</author> <date month="April" year="2019"/>
<author initials="A." surname="Sokolov" fullname="Alexandr Sokolov"> </front>
<organization/>
</author>
<date year="2019"/>
</front>
</reference> </reference>
<reference anchor="LwM2M" target="http://www.openmobilealliance.org/rele ase/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf"> <reference anchor="LwM2M" target="http://www.openmobilealliance.org/rele ase/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf">
<front> <front>
<title>Lightweight Machine to Machine Technical Specification</title <title>Lightweight Machine to Machine Technical Specification</title>
> <author>
<author> <organization>Open Mobile Alliance</organization>
<organization/> </author>
</author> <date month="February" year="2017"/>
<date>n.d.</date> </front>
</front> <refcontent>version 1.0</refcontent>
</reference> </reference>
<reference anchor="GAA" target="https://www.etsi.org/deliver/etsi_tr/133 900_133999/133919/12.00.00_60/tr_133919v120000p.pdf"> <reference anchor="GAA" target="https://www.etsi.org/deliver/etsi_tr/133 900_133999/133919/12.00.00_60/tr_133919v120000p.pdf">
<front> <front>
<title>TR33.919 version 12.0.0 Release 12</title> <title>Digital cellular telecommunications system (Phase 2+); Univer sal Mobile Telecommunications System (UMTS); LTE; 3G Security; Generic Authentic ation Architecture (GAA); System description</title>
<author> <author>
<organization/> <organization showOnFrontPage="true">ETSI</organization>
</author> </author>
<date>n.d.</date> <date month="October" year="2014"/>
</front> </front>
</reference> <seriesInfo name="ETSI TR" value="133 919"/>
<refcontent>version 12.0.0</refcontent>
</reference>
<reference anchor="SmartCard" target="https://www.bsi.bund.de/SharedDocs /Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/TR-03112-api_teil7 .pdf?__blob=publicationFile&amp;v=1"> <reference anchor="SmartCard" target="https://www.bsi.bund.de/SharedDocs /Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/TR-03112-api_teil7 .pdf?__blob=publicationFile&amp;v=1">
<front> <front>
<title>Technical Guideline TR-03112-7 eCard-API-Framework - Protocol <title>Technical Guideline TR-03112-7 eCard-API-Framework - Protocols<
s</title> /title>
<author> <author initials="" surname="" fullname="">
<organization/> <organization>Bundesamt für Sicherheit in der Informationstechnik</o
</author> rganization>
<date year="2015"/> </author>
</front> <date month="April" year="2015"/>
</front>
<refcontent>version 1.1.5</refcontent>
</reference> </reference>
<reference anchor="Krawczyk" target="https://link.springer.com/content/p df/10.1007/978-3-540-45146-4_24.pdf"> <reference anchor="Krawczyk" target="https://link.springer.com/content/p df/10.1007/978-3-540-45146-4_24.pdf">
<front> <front>
<title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-He <title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hell
llman and Its Use in the IKE Protocols</title> man and Its Use in the IKE Protocols</title>
<seriesInfo name="Annual International Cryptology Conference. Spring <author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk">
er, Berlin, Heidelberg" value=""/> <organization />
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> </author>
<organization/> <date year="2003"/>
</author> </front>
<date year="2003"/> <seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_24"/>
</front>
</reference> </reference>
<reference anchor="Sethi" target="https://arxiv.org/pdf/1902.07550"> <reference anchor="Sethi" target="https://arxiv.org/pdf/1902.07550">
<front> <front>
<title>Misbinding Attacks on Secure Device Pairing and Bootstrapping <title>Misbinding Attacks on Secure Device Pairing and Bootstrapping</
</title> title>
<seriesInfo name="Proceedings of the 2019 ACM Asia Conference on Com <author initials="M" surname="Sethi" fullname="Mohit Sethi">
puter and Communications Security" value=""/> <organization />
<author initials="M." surname="Sethi" fullname="Mohit Sethi"> </author>
<organization/> <author initials="A" surname="Peltonen" fullname="Aleksi Peltonen">
</author> <organization />
<author initials="A." surname="Peltonen" fullname="Aleksi Peltonen"> </author>
<organization/> <author initials="T" surname="Aura" fullname="Tuomas Aura">
</author> <organization />
<author initials="T." surname="Aura" fullname="Tuomas Aura"> </author>
<organization/> <date month="May" year="2019"/>
</author> </front>
<date year="2019"/> <seriesInfo name="DOI" value="10.1145/3321705.3329813"/>
</front>
</reference>
<reference anchor="RFC4279" target="https://www.rfc-editor.org/info/rfc4
279">
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS
)</title>
<seriesInfo name="DOI" value="10.17487/RFC4279"/>
<seriesInfo name="RFC" value="4279"/>
<author fullname="P. Eronen" initials="P." role="editor" surname="Er
onen">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." role="editor" surname
="Tschofenig">
<organization/>
</author>
<date month="December" year="2005"/>
<abstract>
<t>This document specifies three sets of new ciphersuites for the
Transport Layer Security (TLS) protocol to support authentication based on pre-s
hared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance
among the communicating parties. The first set of ciphersuites uses only symmet
ric key operations for authentication. The second set uses a Diffie-Hellman exch
ange authenticated with a pre-shared key, and the third set combines public key
authentication of the server with pre-shared key authentication of the client.
[STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3
748">
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
<seriesInfo name="RFC" value="3748"/>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization/>
</author>
<author fullname="L. Blunk" initials="L." surname="Blunk">
<organization/>
</author>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
<organization/>
</author>
<author fullname="J. Carlson" initials="J." surname="Carlson">
<organization/>
</author>
<author fullname="H. Levkowetz" initials="H." role="editor" surname=
"Levkowetz">
<organization/>
</author>
<date month="June" year="2004"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP), an authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point Proto
col (PPP) or IEEE 802, without requiring IP. EAP provides its own support for d
uplicate elimination and retransmission, but is reliant on lower layer ordering
guarantees. Fragmentation is not supported within EAP itself; however, individu
al EAP methods may support this. This document obsoletes RFC 2284. A summary o
f the changes between this document and RFC 2284 is available in Appendix A. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
</reference> </reference>
</references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4279.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.
xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="true" toc="default">
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>This document is the output of the TLS External PSK Design Team, compri sed of the following members: <t>This document is the output of the TLS External PSK Design Team, compri sed of the following members:
Benjamin Beurdouche, Benjamin Beurdouche,
<contact fullname="Björn Haase"/>, <contact fullname="Björn Haase"/>,
Christopher Wood, <contact fullname="Christopher Wood"/>,
Colm MacCarthaigh, <contact fullname="Colm MacCarthaigh"/>,
Eric Rescorla, <contact fullname="Eric Rescorla"/>,
Jonathan Hoyland, <contact fullname="Jonathan Hoyland"/>,
Martin Thomson, <contact fullname="Martin Thomson"/>,
Mohamad Badra, <contact fullname="Mohamad Badra"/>,
Mohit Sethi, <contact fullname="Mohit Sethi"/>,
Oleg Pekar, <contact fullname="Oleg Pekar"/>,
Owen Friel, and <contact fullname="Owen Friel"/>, and
Russ Housley.</t> <contact fullname="Russ Housley"/>.</t>
<t>This document was improved by a high quality reviews by Ben Kaduk and J <t>This document was improved by high-quality reviews by <contact fullname
ohn Mattsson.</t> ="Ben Kaduk"/> and <contact fullname="John Preuß Mattsson"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIABhm/WEAA6196XIbR5bu/3yKDDlimowAwE0rPXOnIZKS2BYtjkhNx8Qs
cgJIAGUWquBaSMMKRfQ73D93ft6XuC8wb9JPMuc752RVVgHssfu2w5aAQlUu
Z/3OkuXhcGiqpEr9qX1bJzOXTb2d54W9+LnyReZSe33znf1UuoW3SWZv398Y
N5kU/v5X3z7Lp5lb0fCzws2rYeKr+bBKy6HXJ4br8m640LGGh8/N1FV+kReb
UxphnhuTrItTWxV1WR0fHr46PDau8O7Uln5aF0m1MQ95cbco8npNd6WlufMb
ujI7tZcZJvDV8BwTG1NWLpt9dmme0WI2vjTr5NT+a5VPB7bMi6rw85I+bVb4
8O/GuLpa5sWpsXZI/1laTHlqP47su7wuU7/ha7Kxj3VZdi7nxcJlyS+uSvLs
1P5zskhSexOWixv8yiXpqV3KM7+/xx20n9E0X3Xn+wPm26S08Gi+P+SZq5Yu
6/zUnfMszevZPCVK2ffVbBRP+qM+PVrK079f4Pr21FcjWnO1TKKJr/JlUkVX
u3NeFMm0LPMsnmyFJ36/TuqlGxErujOcjcYj+8c8j/d2tiySssrXS1/Y+NfH
thdPNnUPv196t06yxSSpSp7QZHmxoqfuPTj58c3Z8dHRK/348ujF0/Dx6dPn
+Hg5PB/tltBktSYh8SQQBmLZHfTlixcn+vHFq+Nn+vH54fPn4ePzozDV06Pj
47CWl8+fbc06oz+OTrYuT+mP5mJBF6fzYjGcrt3Ub1/O1+6nurlOS63AmKFf
1UOiD49He8LvNz6dJ3wn/aN24IletKQJqZ+C5KXNWZvt0ejEPiTVEnr+RJ5q
FUX/GbYfG15/P7LnRT2980X3R+H690mx/fOuYW5GZHZ8oULWG+Vm6Tadn2dk
SU7t8eHRK92fKxa+Ir2rqnV5enDg10WSVaPETYsRCdgB7jw4efpitJ7N6Ynx
+OZGhCWizVmeVUlWk4zZKg8U2qKOj8zhbyHT+5Ed3y1Xvvpl47L83u3a5vsk
TTbusft2jXpBo6b+rvT+fteAF/cLn2123PLIWDerTblMN87vXt/FHZGdCOt2
37hrUNL0m/wuT/Od66OF/UyGquje81cx9+nxkTL3/cPV8ZVwI7D2fbJYVg8e
f9orN10mmQePw8dbP11myZSYerP202ROH6Eawt54dpr84eFhlK99tsonSepd
mibwbryOwtOF0h9Es9FKDv756PPhkNb44vD48OVwfPDhajy8vRl27xr27tK9
vB2Puzu5/XhyMnp19Mre+6KkNdqj49Hh6NB+lLnp6/aqS122r8qEFzrzKVm4
4gAXPlfFwdHJyavDw8/469Ur/kYExcA08uHn54cHVfFZrt4fkac+PFzr8m5W
rqjOHPnk7iIbegJJ0GSg8cfh4cnR0fHwhfV4Yji+vhy+KUgM4OXtn//0v+11
kZPPztPy8S1MaAeTOpuNZv6AjELhZ+f5tDw4zx+yNHcz+nRx8Prm8uC6nqTJ
HXPRZweynnK69B+T6bKi9SS4+pEXdNCsjPzL58onKVuJf/z8eZLmk39YYySR
hzfE8L+7/4cj0xHSZ/T1u8I9TH/Z3PWt7eXbq/GpvV162t//oW/ZkKR9eDWe
/vlP/2nH63WRkwRCEsdkQjyZHyCkmT1P5mSlh+98mq4IDNAz9rIqCXwx9KI7
7eV3F31y/Toz9G7ULHaXQr6rF3nvhrDRwxP5XpIF8CU8JelvltXEZcFjTCP6
dlZs1hVp82JjyaTOfeGhIKRapLULXwzsa18QCwb2nYdwTHyx2K3ndNPdqNTH
AGMOpmSiiUwHxJ+Do8PR0eHhi4NXL14OT4bPnh4Onz47evp8+PTz8dMgnsAz
PZ5cJeUkyWaw8uOqctM7doCM4bw99/cJwd5rl2BSJvzrPK/KqnBrgI/fQukO
yuqRuQ+3/pL5vPZpBSl+xH7elcmOW3aNdUu+oi52GvbbOl+5Mvq5b4JjppPc
Tb0HBYl0cxZH3GjHZ1d2XCYu4jpIe5av1jXJB1OTvqzqTPWp7ELnLf674ufk
ng0W85sChNHhi2fPDo0ZDofWTcCWKQHB22VSWgpG6hXJhiWluie5Km3Nscoi
jmVa5134odgP+53flHaPvHm5bxDYFC4rAQjte7ehVYcl2j2CAfuMA4hSMz8n
ozaDOhLaswCZI3NZ2ZQgbsmAIQQxWM/aFxWRLyxtZicbwAdaYjajKab0s0sy
48qyXq2ZMgOmFmwCTbWiC7TVikZY5g/2PslTpZ+Qn8xC9KglRzAzZFOciDdx
fcZSDQKQGKcN9emepU/XduV9tWOchOIoXfDIdmns0jK3M7KoFB/RqhAZ1vT0
1OEbVs4Pwj9BjdYQGNw4Mm8IPKTpZmCTQCuID6n4vZtu+MlddKOghuYk/czy
ysREbJAZCBUjs5JvpzVRhMTSskpms9Qb8w2MVZHPaga/j8pOIzW52Fvsjoj9
t5GfL180Lvn6VQnbTAfCGmaSZ/6cu8otyEnyTvfOoyF2RBZfv4KCBgpHetEQ
p3cvwg1M/IbEgcLtmSMcQ+sb0D5jUtCOS4Ot045legHFtCXIVprasibfpTCE
WGsutuhPITcBWQoeDXG1ICG7A60aBtI4mABjr9WXWQrGUo8FsIxC1RqaJxnZ
EZpoe55G2mjQvK6G+Xw4IUqM+uxliTN/nXZ2VANk/qv00sZ6icWZZnGPqNPg
EV0SC8F7wXCmR7iyXrMQKl5gx/lztXNhPeU2rNyNJrhHjAcNfO+KJK/LSPVj
i2K2JwI/yDEwzwjYbEieyrwupkHFddKuzV7TCEj7WAplfKFiQfQnyWuQunXJ
igXqgZBlCSHCSESuwGckWx78PdBHxUugDWc5i7DxP9VkflLw4Ff4CE1+bVnE
ZFUa1hAyLV62s3DrESwO+cN7gDuVHEIZ5DwS/s4UgVpYbLEkePLp5vbJQP62
33/gzx8v/unT5ceLc3y+eTd+/775EO64effh03v63ein9smzD1dXF9+fy8N0
1fYuXY3/5YmI0pMP17eXH74fv38iQhPLJhhGm5sAfxJ11qTLRBX2g+W0SCbi
CV+fXf9dNinX3x49FRuHjAwZJbF3Ry+efv1qYKllvjxLN1a+Eks2kC7vCowD
4zIlMF6RJA4wS0nqlVnwjen5fS5Cbgxs2Lou1jmEj2U74gk9ap8QDOVAJMtn
/gm47kgXAEhEmUhCM2WXySEZJG5iDaYEvHmzMKUc+d8TtOnbK3KuNp6CBq/T
mVnngKkJXB2IRmY2TX4hIvE4qzqtElJWu15uSn6S4FkFeac9rFnEaW1qfAgv
0UbdbEUSw8aGAjfW5iJPB9aPFiNsk+AZybadu2JFK8rsE5/N1jktP2yZ/Amx
kagldxre5TRZy1ygOQbNJCXERIYRanzXdWslv3xDOjVszeZXEWF1kA40vYdV
oJ172hUFT+WSdo7hiBz5g6Aj0IrNhYsCH3Y3YeWWDAFdxxQjin4EcuRz8j9E
JebUhOzBPKlIRJJsmtYApIYYmggtI0uL/TWspkX+VLusqlcqCDTgt+SfPImp
B1nXGxLZOTvHlKMxNcwgTMeKlF782SwHLgnGywQwAxERejJy2N7WgB4r8DSL
f7B9WZ4NC7+m7YiM75FXi57ucoqldIYUjxp5uGN+bv9bG/Ykjw51XaSDj2zO
GGZSyxD2I0EE4F9IYiriK5t0CCutbE5y6tjtpMGXbk6tp7CWRyPpu8ugvMQN
/zOpEj2Ox1QgxQ54lcoAel1AoxlobUvSGhqOBJ5FQbW89SuYRHyvnw0EM4Ma
u1w8MQLSh+xyibE9TJB3dz5Tc6Y+mDCAJ1mFInxj1QfA+hszjm8ibnz5QpI/
ZO/39esA24xwAdaRFCqGA7pX8o4kX8Fulqac+gx+tIQthF8M1kFIVEJpm2tC
JxhEWGSHNYEihinCpo+ImTmyETA8G7t07AVhUFd+NYkfFcsCCRaaMSyKtbEU
C831l/D0Mlk3kUlLYAEVJqelMS7clJVfYTlJhi1lYDqRg3WWHqA4HN4zAAFn
sxqD0zAmn7DtYJ5kDHPY6p8acwS71l2NmOgV8bZE4YNGohvENMS3jfAsSY2K
I+17wqEb22Jn52QYltavlwSeaPnsi/3P06XLFl6lCXaiyFdJMHGdRbC4QsYF
LdNoYBagh4iNIt+HhChDnJ6kLBUqEwKmgXCEZcDjdg8EJlWRS6t8lsw3+5YE
ak5wp7cbGJ7ujn77fvpkVTMNlv7mVYL/utLILPMT7HBdWbU7MePZLJGkEUJC
R5gQJgYCACsYcbnwtEDiMO1iRnS9I7mY+OrB02aWJPI0aEdMAcTUSGIbKyhq
ncGbZ8D3D24juKJFL6LuQBaK3ZwAASLgipa4EFvsFg6uWgzQNCWCMAGZSOxo
712SgsViAbtkFWp4iXhvvr9koJlxDpcBEmpKZJxZuyjkSjLWQbXrwd7Tv8S3
lSOD2FBAImi4Nxh0jExotvZBT8knTn3CdkBW8rtgk9UVbZCogquQ4pB6v5mn
qCdlzJ5bEt66NWnKDrYsatpoiWUyY3UoaKy1Jy4M7A/jH+iP1z+Izfjh7IcB
4T8JHrECHotN2G2jERLg+BkMPK2DRVHUnwYjZcrwCw3FxhEJ0vwHCCdNwppx
G6sWw7epX2uWgVwWZ4SwFtLMhOhCvyQVP38mz9PfUOF1jnnUQpAG01c7T7l8
sPfDDRthmXtgR6PRPo8w1hHiZb4BaiP480MzeVgrbls6Nkdk2ME4LLGR74HN
S5aOCTwU1rFzh+028PQj02Fr2NdfmE6nwBbMZaYOVlkLXvZRgVqeNj00JnRG
Cj9nAmrsSUMYdq5AnRx6EuCEdS7rRESbNJulY8oZ40Xh1stkSuKxyMlNLFfk
zh4yujoLOy7NinlAkJogP4jjNQ5rJZLxbrVZs20LEg6lCVlfGcp8+RLS3F+/
QvRpz8iKiA4EYYx0gsctUR5yKUe7IffZTK3W0gYrsctRwJghoJjkEK2QKWTw
DrEUn08GnrXadBbzqIFU41h2keGcLLxYD4FaVW7EafNkmtYqCbo14JJ436bn
aJlqnDVNQxtuvfKAvRtTU5D9tCB+KKpfuQ0ht4UT12DI2MMOz/w6zTdAiqXk
nggOQhYHtP77XOUKLCMukVChrNCx6SpzJjCeRZb23UYZspzMP/CSOGFBhka5
JLD6Pr8j0dcRBd3h3gvB/RTbhAjAmHCtix67OUbslOMS3eMjmaXufk0CDLEk
QbY6W3DmSFeqi6YrQ4Zf7L7DDjkWXzGRQ7jgfyaRJH02u+AuaEBrij1xh1pB
BOhhDgEkngl+RY04A5gpo7z4tp2GQQx9o7amjYGCj9HM5wCxJbP8YnSkHsch
hbtOXdbIgohdREjTi7+EFim0jkZA8ifK+LzpXWF2kelA0ZcG4TxfXbLUIFYZ
nr/j8cj0IhJJtaQFGR60tzLf2VqWS+TX0mTuq2SFtcFycmROIIdtobPkvf4/
mGw4h1pPfmQc0yAwotLSkTvGx9K7gqBACHQfyH4uBWuSsHuSU5gRBVzMtpGN
tqpZ2nYGwXNx3CwjxojVRJBbYkB4fnFM2ytbL1tTWbYjww5OwL8aoMVQXM9F
4mTeBcdTt67qgk0bqJ/GLkv4oRCCOFQDl+VlAK2lkAFuKiReu7iXc9sRZVgG
xUi3VnTip7QhZCby0mvZw689h608Qq9Uu3f+br+B2yP7PuI/zwF6g+Wirr71
FTHhRXZC3nPoOrXhGM/bvevxdxf7QawMy6UmJ73WYaEG9cp+9MqQt2xU987e
fHzLD9IyNERDHR4kRdTPbRAbyaggUhTgjNlKuyeJhR3tSlKA2PpNepYQHhOJ
xQuFwgDf79qvmvIGBPMaW+xzOqqb9CfBvEZiLpl6yVoIslBg8YDQcp4URFfZ
SEJrV1uIR48PD5+N2uoBkKgm+8hqpZwbCwKCJ5pOi9FJGE/dVbeQo+UWFpJa
8/giVcFuIjiUnAUXC2dJCdxQA7OVqiDtLfo43HjX64hKUmjvSTxhpx+rfjAy
KlWSm4yDgv9fU6/r5cMb0wcRY+eJjoQzDGK6k0lpr8yBLsTt2SZNonmOtUuK
4QN0sTMBGc6RHw2ai4ZnbQqAGlQHF8XWs00gNfkkwTyDiEjQD/EyHYdlQjZf
ExIPjusCpIeeuMBGt0iARpNfJPTR7bAIInKWRGqdOsJUxQzZBjPUNoJhlQ9n
0lAwjcveQsOIU6QO2XRZEPF/EQUvVTof4Swn8KIhiWU8ZCeq4wQjk1pLQA0W
rlg8OV2UlFNkbWh4JLcdXZhz5b4yRFkY5CbPjW2hcuqGM1e54RTBZtHd1yj0
U2HjK22t2t45pzDVmmMsK2MZpPI5UUm7bLK1e9f59T477jqSlHTTIY3IDTFq
RZiUfhND7juVAY1JQCu0LrcmXkWajCM9ifWExGmADUO6VxFKiHK1BMZVZ3FD
7eNmq0uwZOKdAcKw5fAkPqVKLEilsvsbaWn+BkTpgMFdZAG+LlAfK4Kvhbgs
4U/p8Y7RgByTB3QLRknfXXLdVDdcBvHhrm3Owi65fWTvMr/dF8zIiqLMSJNV
Al8nCfrQV0RgQGrVjATZ9qIll7Op6MaQaIoLbFqimSepGrFQaAQzkcjgfFmY
k1WwXiw8qsNRtX/LsajerdHzV4XHxdl+IFBgr7gnkIJhaQq0O9oOzf/cdkiy
xy2MtDHiTxWKo3ytyQBzfTAUeQHysFhgOiz8XAz0UAs4xJCP4/PLTzdalXv5
HERrwcLWPhmlrJXsIjhJW+aVklxwrCYJ+avnR0/JD2Lak7fX18Eki7UhN0JS
tJZiYscCC/neorZL/n/czTOMCbEkiCCAlfbejsf7TefNZGNO3r69tqtQWWUi
0X6GW9tRsFmXkeeIHEZvedtOgvZHU+veuOXRooNROe/RJgzjPaVdFACBl+d2
z1+e79PECD+abEh3UE4l8x3LPOXUWR6sLhbXakPY05cvTbulruWftJDVVr3Q
bUtONwq2G+PJHmVPJHjCDbDIjPIMkaqSgwGS7K21X+kV4PPixcnXr/sBIwfI
FNW9OoUthbpmq/rWaQsI6MnGWKFtKOm6/1VeeEkjVQ+5bcuFNxHwKCW3a/bY
s1cS9nU6rK1HdXEUlWf2T0FdQcqEtJGxCFmxAGMGmp1oCqmB1JNuO4rr9iV1
3D6jq8gEmy7S3/JRUtsI+RAlNy/jb29fyUhlErN2rHxDVJTQmlRM0iNOL8HD
Hn9BYB5qV8EHDywtrFmTpFFSLU01eSlOLIl+SpbWtA7Qh+QswAPKHKrPXC1F
iATaZmGGfUWCUo4DSAq37EBR22NmpokP4yHpK48KJMtAtrlrx6hcDxAG7mX/
cWx3jKj5qJjcF0puqbFzAXUnVNegtGzyelKCE9ftxQ5IOaDwrjLwEyTwfyRh
4wprYCRZ9vs8mfWSe0HbOLv3LVqdJAWjdxlNAa5y7rfhIqBmAhOJATg/YuuM
B3ectP2j5j+aqZZo/8jKgXZhuCnXJ2ehT1S6WoIRd1tF2CZKlQfYPgbiBVf+
SIwDmdPaTFv2HYr8J9kMdY9EitvSba3lb/E3jWVCLEfmsea+GI5py2QBA0AO
oWZwBoQN6VS9ldoG00/7wH15isR1lNVATCo9ciojLHSas7K3ODhnP2T2DYe6
iMX2bj+8+bRvw4hBoOVpE5L/tJg6UzPNe57nqncSNKOhhcSSBKFComWdOjgW
JkhQWRZ8YvWmsSWfLntpTjb+UG0O0vgBLvWynyfxXwNE0v0wC3P/gOJwXVXc
j/bHUMPHdtrdaNUBXh1SNDAcOAR6SRNVnc6C2AdiJnyIh5PjDfSj1bIzF2cp
e2rkQ7jKEVEWG+wBxZV5PRMXyUGbSlIbIvGAUvJt3MHE3bGYojmOfPcDo6uC
NGNe8ec2RlyjiRve5ooYkrOSPQgp2vK+IamDTM0dUBFvntRr0J+Uj8h4TlOl
jqSa+wgaMWeL/DqR9PgVH+ohxysOSfJ1piTUxJqC5/iE3A77dBZISsDZbOmY
WCGFk/OKK88tC7CGtqFwGDIrXJ3tORCXIhRZLFl/FrnDsk1nqoSbiciA1IVq
JhtcmGZsUcwRCmAOheCfahEX/DyQNEVYqzbzPDgumURqbdqEhaIQNuGcNOV8
MnNpZMewtGLEmvV3Zmikc+l323JshFz8zOwkT3NEEWU4AhcJT8USKxEe7bjT
OtV8ZtFo7XHmpQUX/Wkk5KJRruzmBKULrW0SkhPB4+thC0r/0jlEtsPf2I9d
6/zYseIv3/TNuDEfo/Rjx51tNaRqIL7VHNyvI19AMLi7rXEqtMcEBQFOtjlO
GJMZPDp+aXHaVNq3OIk7kLgLRQS9yzR3pTlwDWx/O3Cv2SR7tC9DGvmaKgMC
uidEv8+zpf9855/0elGJeJoAvkLElzRHFDnDGpdCULmBTJqev+z18H0d9EsV
TSJOMt8dCiF/YRh27yRRv6agVdEOYRgKoHB8OZd8OE0/3MqUN/0UWjDZUSfx
IERSkl5xOzox+1rz5qZ7pqpDNs2bs6HQ/g7tbEjKO2wmFCRmCQNwR44ulKDb
TfgVoizsou0b0abieGHs+ja+kkQkn1Un7iRcB+IwoC6gwyZqfIuebqoYFAug
qK/JHAh0C5VdHCc76d0J5mQuhj8vyIYLIO3qSC+w+5/PSbNSH4/sp4wTWTsB
m3R4z7gBYYvAAZFFvYFaKx+I2YZ2BkWj2BaVgYrXZyBriAdYrij+QzMOhX5x
Cy6hKLiJTlcu+zvoiCSGuZewSRbvvlPBP+4cEa5Csag/kbka/wuWGNjAkU6T
QrXSsLhvbx/gI9CHwt1fXUoZQQC/mQWndu+oqTQBRUYdlbp08QLzhINFTsVo
QSOqb7l5JT+YqPUEY+wd7/ekJh4OMsUtDFGDQWg3CrMH6BqOHoCNNExT6Y3M
f9gWydUJlAnOWtWs7hUImnvLX0ko7jjHIubJQvBSU5YJfdEhA8togW9Xx8Kh
ymUz4YrRcOSyTVeTyB8kmlNizfBFgaR2ASGbbMSGCnQXDDIIm5H26NCx0RlV
MRkpBYwfDyG+f15nykIR3JBmkkI795iFuvdZJ21tfrWM8dycY4lAB/HoKSP0
om3CkfYqHJLBivfYkEmVisDEPIBfLkLo4PutLzAUi8pxgiCLLVnYE7RFHD0B
0pxHQ6+5xrZteZrJOIlPbWrPf1v65S5Z0XZdlx6CivxVlH0xIQJGBITnvhWj
x2CwV69GkW/aaBvTBIwLp/kM+fGizjq0oACl9Olcm415ck7lEMJH5H8FI7dy
P4b6ZeecT9nkgLsVBxmnjMsenRvCKTrpkeOZtMgWQ6qQOnxchdpunbh2MLLn
0j1IdEUJQQuBUu6U80roL5MSPIFR8OQBRTbwqvBRFI60+s3Nez2Ji7np2ymO
TrerBNG1YN1QY7twSeGckYIrwZJOeriBT8c8jbaC3vKZFGQjq3j3SEym6YR3
0FQlk0wai1De5qSGT0PVtW7i08bA8thlPNAKgXyTJxUzF6p1WBJJED9kJAMk
uhgSCWGYfg4o84u8Shj7dE7YaTl7IJgU7VJhBBNsCk59AXA31W7kL0g1AjdC
Lb13mFESOsIByY3jQuqzRbU0aNJ3aTLjBUnYEdTq3/71aGCPnz3/t38nM1mF
ikqHChrV1ms8yqgTNzLmHpGYIFyiBeH1MeKLOvLRsI4FQdMdU2TCgnFo+z1C
vjrKwpgOL6S3NuFEPWytlGOYg41qRqwtk1WC4jDbGWGaUnFEAi1vWzF9ZivN
2gxCTKijhk7N9hdZzbsfP7ptWTaBeo0XCSMW7oGHUceM8NEsScBmxPMVsp9y
eQczwipLFMX1WG7LXCzoIU/nOxS1ywgpPeyiVKAQLKJ06F2GuS8Ik8xCvZFP
uhKixFGw0E/2bHQEIn/58o94I8/xC5y2WAFyN4W0qr+fcslpo0nIf8k5GpVT
hwoAek3QuFo1rwVgY+6xGLktpxuqEIR+un0zfKk+Ch0FfCwDY3F2lU0uH/RS
p0MSR06UsP6e1wZTPRnXrdsnpWkoyFWMZY1qE8pX5f7IIhPIFVpm8JLzVXGR
FAc5ke/c8iBNDxLymrK/DbZaczjB3QYwN1D6iGyJFk6bkL1kaRpONkOWqmnD
G4V8m3C4DTW/Jv8bj1b4VkRmpkmcJhWfJWFvqWkZRJAPLqR6ZrWX7I+KRkIb
8bD4pQ4wkzCwkWnoFYN1JNEGCtlRhup1+8S2TXMIbcy11gYk7i5o+6W2pIuT
TqUnvKfHz6QdSlV4T842ujJcDs/9/dFodPwfR8+HR//LaAdHp/loPwhzXeqx
ljWnBxgRdjgxIVgaCua6GfZrmk7ZrRWBIa4ymg0RY8G5bbmbo6/nz56dPNO9
0DLFcKEfXDN28ayz3GsPLzLKVuK6blZHfVfr4bpLIqflkaLTGgQX9Hj55i89
xQjhHjG8uEhtcpO8eiiUcslvy9RphOekSBypn5oCbQGRyK0tEaTJnedz6png
415ZO7y5xe5djK/31VadvHj6En1kYswVwUjvVAVfVZo+ezgULvAGjxJGt/cz
lq5Z91nOQBR3kn+ez5OfpSkid6tgzwilN8p5mZmOA5WYkgt3oSLLtNselTG5
HH8ssXd08MmLBUyjLnRP7xzyiFum2oq12mMuPkwbLceUIl4B+XQ4hVoTFjHl
AL8xtkTlNAlvKNjyJmfNrwYNeVh+UwpTAa4zMDPlU3KAe/3QNUYoOBIUii6m
28kXHba51TC8lF7P3gsPmNZsLFhMtQsleEm8oS5lSyKWKOLT7wBtcOAv1yC2
WVpLA3JTFBOq+Q3HhvWAEHfZdkkaciGwhdGJG01oN3soCZdSrKkZnu6SCr8g
0M0tZg1QbULXAMWWfnrX9KNjxN9ho0rl7eZJGokeUf+68i40f3DbbGcHzc5l
4yVXpXor7LBT3hnDOTdUjxT5StxPVJqJDQ/hXVij2bHGtSM7SLAkwRO7ZaGx
saFWONk0OZpdwjEw4goj1bFR0jBO0EyiUZmN5E2zcAiFwu3S9BtNJ77Tjzrb
1XkaaRXtqtC+BBPJl0urfOGBQOQQuRqDbgaCz1n0TiWH8lFzdjqcYZBqGSnj
gpsUaAm7Tjr0Mmj99PaIXTv7n5QPoGKcO+/XfYFvayu8lKrXymCQaJjxIWuU
Pr0r+E0Y7VMS70qjaNz1wUF+xCGw+j4pqrqpB7e/GXkTgh7Mn2IWTqAxHyM1
lFqTnjgdaMc4d5E3K4Tjw1u0OHdJ+J6TOXFfSeCWCEZdRu0X3Q2Iu3wgR43g
vudF4xims5CQF2kOykAuJ0J+3fAmqm/jTAlOFnCZ28ubJgizmqKWUmSTwGxe
Z9Bmavm9B502es3HNB1FWy6jyg2i1QK5uuhkabewJD2qUhlqEFio2RIXJ2nO
xotgpE/dhj8RpZGmGnJtnBeuR1615e+nWpsJw9lS2VsZ0uOhRKiVAXIKLt2U
iXhiVoi6MoCdUxLxtkEvvPhCjqLE57cgAyHaSEJ6oELD/2BHxYz0kqSvVOsn
z6beyGtxrHqLAkmmKD8waFoTG6Er6ykqEPrGilbmIlEz26LWGBAUvfi9KUwd
VHj1VF9nNyWIYQMx2Oo8kviUV1e0Pb0cM8qNvcbe5p1CHNwtCwAB0euYyhav
pZiQdsKYrn1go9hjbWdrDGV434LmG7feJwXak69EYYiCCLFdjU1oOwaDNw72
U0WiOUetAtR5H5ZpGNsvt4wC6ukBMray281Y2213vVc5qCa2p7S2G3W6b0to
2/4ihWvfiCD1Obcx/KIG/KTdQt0eMe48at6RwKWZ0a+tDuB1RRy5RKoYHW9G
0VIOYZbVJvXRe3OjM1c+soJl6A7Yvapb7eSIz6BN8wJneNOo+Mu3m9ihh/c+
amY8INhRqK5IZwWF7NGRlyQzv7KeZz+g6zRPa+nSb9IhofYQxM2w+9X34nq7
SPMJ2wjtqYj8W9S4p2/0AataKyv5zO3nyHgM4thngHVo2xRc6NX4DOJehHdg
2ZNjjnLJ4GYUkOi7JAbB437K2FTxIj/JZJfnzWR7nz6hTZdjVLy8GUChLeVy
HRcOCQAWp0lkux2cJQ2AilrkFSliQ9pXyvRfv4LOtJimoRLSnIiPqKHYQNtJ
wgMcYGh9RVpVOm88iCrtmhXg2xIt13UH+/Of/rODSzSWNY8JGr+LJymbCLyT
lkEU3551bmyU2VJb6Z2VyAbSgZ6fzqs82nZJIlfPjPdz+wra+XUKENtNLgea
ti3oyHDg0x7WCCfn2v6MaNyBFKxFrkLal69FIAwaz1RFk5ucMYiaIWw4T6hN
RKXgTpqcxRKup21ILzVM7aA6KUf2g05dddcQSx9YtGbRBRNWlcXVWumFQoTA
1NFyddhg991FDGcbmrGLvRx/P952r7j6tf/SvRWDqiyXZwBtcM5CX8vIZQca
bzyF+Kd+tpBEUH+QQOW6Wtedw3mdNqJzjw0RyHKrgZT80GWx1XEZWqhPzWuf
/YgciH3t62KWk8ITxv/y5cvrH//r/xWZfefIU30lT2Xil9fjzfV0JU9XOMlx
9l//l0CaSxbLgcF78nHSkix66gam/zb/gblCtzgtcJmvAHPNVb50Kzezr92s
cPw1vBZ2YD6kfmGv/Z0r6PMDScGbIvEpV+dN/P8l2HrLITLO8gY88S962Pyn
2jFiwvu5/AOytbTrzH7nZrV05/whX2ZoBuROrpH5b7k5EKw/YgAA
</rfc> </rfc>
 End of changes. 93 change blocks. 
940 lines changed or deleted 353 lines changed or added

This html diff was produced by rfcdiff 1.48.