<?xmlversion='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 -->version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-external-psk-guidance-06"category="info"number="9257" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 2.42.0 --><front> <title abbrev="Guidance for External PSK Usage in TLS">Guidance for ExternalPSKPre-Shared Key (PSK) Usage in TLS</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-external-psk-guidance-06"/>name="RFC" value="9257"/> <author initials="R." surname="Housley" fullname="Russ Housley"><organization>Vigil Security</organization><organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <email>housley@vigilsec.com</email> </address> </author> <author initials="J." surname="Hoyland" fullname="Jonathan Hoyland"> <organization>Cloudflare Ltd.</organization> <address> <email>jonathan.hoyland@gmail.com</email> </address> </author> <author initials="M." surname="Sethi" fullname="Mohit Sethi"><organization>Ericsson</organization><organization>Aalto University</organization> <address><email>mohit@piuha.net</email><email>mohit@iki.fi</email> </address> </author> <authorinitials="C.A."initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> <address> <email>caw@heapingbits.net</email> </address> </author> <date year="2022"month="February" day="04"/>month="July"/> <area>security</area> <workgroup>tls</workgroup><keyword>Internet-Draft</keyword><abstract> <t>This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions,andthen it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.</t> </abstract><note removeInRFC="true"> <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> <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <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 applies to Datagram TLS (DTLS) 1.3 <xreftarget="I-D.ietf-tls-dtls13"target="RFC9147" format="default"/> and Compact TLS 1.3 <xref target="I-D.ietf-tls-ctls" format="default"/>. For readability, this document uses the termTLS"TLS" to refer to all such versions.</t> <t>External PSKs are symmetric secret keys provided to the TLS protocol implementation as external inputs. External PSKs are provisionedout-of-band.</t>out of band.</t> <t>This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. This document also provides advice for applications in various use cases to help meet these assumptions.</t> <t>There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for externalPre-Shared Keys (PSKs)PSKs in TLS. This document aims to reduce that gap.</t> </section> <section anchor="conventions-and-definitions" numbered="true" toc="default"> <name>Conventions and Definitions</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="notation" numbered="true" toc="default"> <name>Notation</name> <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 potentially be realized with multiple physical instances operating under common administrative control, e.g., a server farm. An "endpoint" is a client or server participating in a connection.</t> </section> <section anchor="sec-properties" numbered="true" toc="default"> <name>PSK Security Properties</name> <t>The use of a previously established PSK allows TLS nodes to authenticate the endpoint identities. It also offers other benefits, including resistance to attacks in the presence of quantum computers; see <xref target="entropy" format="default"/> for related discussion. However, these keys do not provide privacy protection of endpoint identities, nor do they provide non-repudiation (one endpoint in a connection can deny the conversation); see <xref target="endpoint-privacy" format="default"/> for related discussion.</t> <t>PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and oneserver,server andthat thesethey never switch roles. If this assumption is violated, then the security properties of TLS are severely weakened as discussed below.</t> <section anchor="shared-psks" numbered="true" toc="default"> <name>Shared PSKs</name> <t>As discussed in <xref target="use-cases" format="default"/>, to demonstrate their attack, <xref target="AASS19" format="default"/> describes scenarios where multiple clients or multiple servers share a PSK. If this is done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall system is inherently rather brittle. There are a number of obvious weaknesses here:</t> <ol spacing="normal" type="1"> <li>Any group member can impersonate any other group member.</li> <li>If a PSK is combined with the result of a fresh ephemeral key exchange, then compromise of a group member that knows the resulting shared secret will enable the attacker to passively read traffic (and activelymodify) traffic.</li>modify it).</li> <li>If a PSK is not combined with the result of a fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively read all traffic (and activelymodify) all traffic,modify it), includingreadingpast traffic.</li> </ol> <t>Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described below. Note that a partial mitigationagainstfor this class of attack is available: each group member includes theSNIServer Name Indication (SNI) extension <xref target="RFC6066" format="default"/> and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity. See <xref target="Selfie" format="default"/> for details.</t> <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> <ol spacing="normal" type="1"> <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> <tt>C</tt> responds with a second flight (<tt>ServerHello</tt>, ...) to <tt>A</tt>.</li> <li> <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> <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> </ol> <t>In this attack, peer authentication is not provided. Also, if <tt>C</tt> supports a weaker set ofcipher suitesciphersuites than <tt>B</tt>, cryptographic algorithm downgrade attacks might be possible. This rerouting is a type of identity misbinding attack <xref target="Krawczyk"format="default"/><xrefformat="default"/> <xref target="Sethi" format="default"/>. Selfie attack <xref target="Selfie" format="default"/> is a special case of the rerouting attack against a group member that can actbothas both a TLS server and a client. In the Selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint.</t> <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 possible without establishing a new PSK for all of thenon-revoked members.</t>members that have not been revoked.</t> </section> <section anchor="entropy" numbered="true" toc="default"> <name>PSK Entropy</name> <t>Entropy properties of external PSKs may also affect TLS security properties. For example, if ahigh entropyhigh-entropy PSK is used, then PSK-only key establishment modes provide expected security properties for TLS, includingestablishingestablishment of the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection. See <xref section="E.1"sectionFormat="comma"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 PSK-DHmode, or, alternatively,mode or by using PSKs with short lifetimes.</t> <t>In contrast, if alow entropylow-entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive searchattacksattacks, which will reveal the 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 mounted 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 because those also depend on the Diffie-Hellman (DH) exchange.Low entropyLow-entropy keys are only secure against active attack if apassword-authenticated key exchangePassword-Authenticated Key Exchange (PAKE) is used with TLS.TheAt the time of writing, the Crypto Forum Research Group (CFRG) iscurrentlyworking on specifying recommended PAKEs (see <xref target="I-D.irtf-cfrg-cpace" format="default"/> and <xref target="I-D.irtf-cfrg-opaque"format="default"/>,format="default"/> for the symmetric and asymmetric cases, respectively).</t> </section> </section> <section anchor="external-psks-in-practice" numbered="true" toc="default"> <name>External PSKs in Practice</name> <t>PSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral part of the TLSversion1.3 specification <xref target="RFC8446" format="default"/>. TLS 1.3 also uses PSKs for session resumption. It distinguishes these resumption PSKs from external PSKswhichthat have been provisionedout-of-band.out of band. This section describes known use cases and provisioning processes for external PSKs with TLS.</t> <section anchor="use-cases" numbered="true" toc="default"> <name>Use Cases</name> <t>This section lists some exampleuse-casesuse cases wherepair-wisepairwise externalPSKs, i.e.,PSKs (i.e., external PSKs that are shared between only one server and oneclient,client) have been used for authentication in TLS. There was no attempt to prioritize the examples in any particular order.</t> <ul spacing="normal"> <li>Device-to-device communication with out-of-band synchronized keys. PSKs provisionedout-of-bandout of band for communicating with known identities, wherein the identity to use is discovered via a different online protocol.</li> <li>Intra-data-center communication. Machine-to-machine communication within a single data center orpoint-of-presencePoint of Presence (PoP) may use externally provisionedPSKs,PSKs; this is primarily for thepurposespurpose of supporting TLS connections with earlydata; seedata. See <xref target="security-con" format="default"/> for considerations when using early data with external PSKs.</li> <li>Certificateless server-to-server communication. Machine-to-machine communication may use externally provisionedPSKs,PSKs; this is primarily for the purposes of establishing TLS connections without requiring the overhead of provisioning and managing PKI certificates.</li> <li>Internet of Things (IoT) and devices with limited computational capabilities. <xref target="RFC7925" format="default"/> defines TLS and DTLS profiles for resource-constrained devices and suggests the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance LightweightMachine to MachineMachine-to-Machine (LwM2M) Technical Specification <xref target="LwM2M" format="default"/> states that LwM2M serversMUST<bcp14>MUST</bcp14> support the 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 in <xref target="RFC6614" format="default"/>.</li> <li>3GPPserver to userserver-to-user equipment authentication. The Generic Authentication Architecture (GAA) defined by3GGP3GPP mentions thatTLS-PSKTLS PSK ciphersuites can be used between server and user equipment for authentication <xref target="GAA" format="default"/>.</li> <li>Smart Cards. TheelectronicGermanIDelectronic Identity (eID) card supports authentication of a card holder to online services withTLS-PSKTLS PSK <xref target="SmartCard" format="default"/>.</li> <li>Quantum resistance. Some deployments may use PSKs (or combine them with certificate-based authentication as described in <xref target="RFC8773" format="default"/>) because of the protection they provide against quantum computers.</li> </ul> <t>There are also use cases where PSKs are shared between more than two entities. Some examples below (as noted byAkhmetzyanovaAkhmetzyanova, et al. <xref target="AASS19" format="default"/>):</t> <ul spacing="normal"> <li>Group chats. In thisuse-case,use case, group participants may be provisioned an external PSKout-of-bandout of band for establishing authenticated connections with other members of the group.</li><li>Internet of Things (IoT)<li>IoT and devices with limited computational capabilities. Many PSK provisioning examples are possible in thisuse-case.use case. For example, in a given setting, IoT devices may all share the same PSK and use it to communicate with a central server (one key for n devices), have their own key for communicating with a central server (n keys for n devices), or have pairwise keys for communicating with each other(n^2(n<sup>2</sup> keys for n devices).</li> </ul> </section> <section anchor="provisioning-examples" numbered="true" toc="default"> <name>Provisioning Examples</name> <t>The exact provisioning process depends on the system requirements and threat model. Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several nodes is sometimes unavoidable. When PSK sharing happens, other accommodationsSHOULD<bcp14>SHOULD</bcp14> be used as discussed in <xref target="recommendations" format="default"/>.</t> <t>Examples of PSK provisioning processes are included below.</t> <ul spacing="normal"> <li>Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: (1) typing the PSK into thedevices,devices or (2) using aTrust On First Usetrust-on-first-use (TOFU) approach with a device completely unprotected before the first logindid taketook place. Many devices have a very limited UI. For example, they may only have a numeric keypad or even fewer buttons. When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.</li> <li>Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.</li> <li>Some secrets may be baked into hardware or software device components. Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.</li> </ul> </section> <section anchor="provisioning-constraints" numbered="true" toc="default"> <name>Provisioning Constraints</name> <t>PSK provisioning systems are often constrained in application-specific ways. For example, although one goal of provisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distributepair-wisepairwise shared keys to achieve this. As another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities. Identities may sometimes need to be routable, as is currently under discussion forEAP-TLS-PSK<xref target="I-D.mattsson-emu-eap-tls-psk" format="default"/>.</t> </section> </section> <section anchor="recommendations" numbered="true" toc="default"> <name>Recommendations for External PSK Usage</name> <t>Recommended requirements for applications using external PSKs are as follows:</t> <ol spacing="normal" type="1"> <li>Each PSKSHOULD<bcp14>SHOULD</bcp14> be derived from at least 128 bits of entropy,MUST<bcp14>MUST</bcp14> be at least 128 bits long, andSHOULD<bcp14>SHOULD</bcp14> be combined with an ephemeral key exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS1.3,1.3 for forward secrecy. As discussed in <xref target="sec-properties" format="default"/>,low entropy PSKs, i.e.,low-entropy PSKs (i.e., those derived from less than 128 bits ofentropy,entropy) are subject to attack andSHOULD<bcp14>SHOULD</bcp14> be avoided. If only low-entropy keys are available, then key establishment mechanisms such asPassword Authenticated Key Exchange (PAKE)PAKE that mitigate the risk of offline dictionary attacksSHOULD<bcp14>SHOULD</bcp14> be employed. Note that no such mechanisms have yet beenstandardised,standardized, and further that these mechanisms will not necessarily follow the same architecture as the process for incorporating external PSKs described in <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/>.</li> <li>Unless other accommodations are made to mitigate the risks of PSKs known to a group, each PSKMUST<bcp14>MUST</bcp14> be restricted in 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 nodesMAY<bcp14>MAY</bcp14> be the same, in different roles.) Two acceptable accommodations are described in <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/>: (1) exchanging client and server identifiers over the TLS connection after thehandshake,handshake and (2) incorporating identifiers for both the client and the server into the context string for an external PSK importer.</li> <li>NodesSHOULD<bcp14>SHOULD</bcp14> use external PSK importers <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/> when configuring PSKs for a client-server pair when applicable. Importers make provisioning external PSKs easier and lesserror proneerror-prone by deriving a unique, imported PSK from the external PSK for each key derivation function a node supports. See the Security Considerationsinof <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/> for more information.</li> <li>Wherepossiblepossible, the main PSK (that which is fed into the importer)SHOULD<bcp14>SHOULD</bcp14> be deleted after the imported keys have been generated. This prevents an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node;otherwiseotherwise, the attacker can recover the main key and then re-run the importer itself.</li> </ol> <section anchor="stack-interfaces" numbered="true" toc="default"> <name>Stack Interfaces</name> <t>Most major TLS implementations support external PSKs. Stacks supporting external PSKs provide interfaces that applications may use when configuring PSKs for individual connections. Details about some existing stacks at the time of writing are below.</t> <ul spacing="normal"> <li>OpenSSL and BoringSSL: Applications can specify support for external PSKs via distinct ciphersuites in TLS 1.2 and below.They alsoAlso, they can then configure callbacks that are invoked for 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, with new callback functions added specifically to OpenSSL for TLS 1.3 <xref target="RFC8446" format="default"/> PSK support. The PSK length is validated to be between[1, 256] bytes.1-256 bytes (inclusive). The PSK identity may be up to 128 bytes long.</li> <li>mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. Servers must implement callbacks similar to that of OpenSSL. Both PSK identity and key lengths may be between[1, 16]1-16 byteslong.</li>long (inclusive).</li> <li>gnuTLS: Applications configure PSKvalues, eithervalues as either raw byte strings or hexadecimal strings. The PSK identity and key size are not validated.</li> <li>wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.</li> </ul> <section anchor="psk-identity-encoding-and-comparison" numbered="true" toc="default"> <name>PSK Identity Encoding and Comparison</name><t>Section 5.1 of <xref<t><xref target="RFC4279"format="default"/>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 configured by human users). On the other hand, <xref target="RFC7925" format="default"/> advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for any operation. When PSK identities are configuredmanuallymanually, it is important to be aware thatdue to encoding issuesvisually identical strings may, in fact,differ.</t>differ due to encoding issues.</t> <t>TLSversion1.3 <xref target="RFC8446" format="default"/> follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> 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 least 1 byte and at the most 65535 bytes in length. Although <xref target="RFC8446" format="default"/> does not place strict requirements on the format of PSK identities,we do howevernote that the format of PSK identities can vary depending on the deployment:</t> <ul spacing="normal"> <li>The PSK identityMAY<bcp14>MAY</bcp14> be auser configureduser-configured string when used in protocols like Extensible Authentication Protocol (EAP) <xref target="RFC3748" format="default"/>. For example, gnuTLSfor exampletreats PSK identities as usernames.</li> <li>PSK identitiesMAY<bcp14>MAY</bcp14> have a domain name suffix for roaming and federation. In applications and settings where the domain name suffix is privacy sensitive, this practice isNOT RECOMMENDED.</li><bcp14>NOT RECOMMENDED</bcp14>.</li> <li>Deployments should take care that the length of the PSK identity is sufficient to avoid collisions.</li> </ul> </section> <section anchor="psk-identity-collisions" numbered="true" toc="default"> <name>PSK Identity Collisions</name> <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 callbacks influences the application's behavior when identity collisions occur. When a server 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 internal session resumption cache. This means that if a PSK identity collision occurs, the application's external PSK usage will typically take precedence over the internal session resumption path.</t><t>Since<t>Because resumption PSK identities are assigned by the TLS stack implementation, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether.</t> </section> </section> </section> <section anchor="endpoint-privacy" numbered="true" toc="default"> <name>Privacy Considerations</name> <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, an adversary learns information about the external PSK or its identifier by virtue of the identifier appearing in cleartext in a ClientHello. As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire. Depending on the PSK identity, a passive attacker may also be able to identify the device, person, or enterprise running the TLS client or TLS server. An active attacker can also use the PSK identity to suppress handshakes or application data from a specific device by blocking, delaying, or rate-limiting traffic. Techniques for mitigating these risks require further analysis and are out of scope for this document.</t> <t>In addition to linkability in the network, external PSKs are intrinsically linkable 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> </section> <section anchor="security-con" numbered="true" toc="default"> <name>Security Considerations</name> <t>Security considerations are provided throughout this document. It bears 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 PSKs are known to a group.</t> <t>It isNOT RECOMMENDED<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 rely on sharing the same PSK among multiple nodes. <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/> helps in mitigating rerouting andSelfie styleSelfie-style reflection attacks when the PSK is shared among multiple nodes. This is achieved by correctly using the node identifiers in the ImportedIdentity.context construct specified in <xreftarget="I-D.ietf-tls-external-psk-importer"target="RFC9258" format="default"/>. One solution would be for each endpoint to select one globally unique identifierandto useitin all PSK handshakes. The unique identifier can, for example, be one of itsMACMedia Access Control (MAC) addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) <xref target="RFC4122" format="default"/>. Note that such persistent, global identifiers have privacy implications; see <xref target="endpoint-privacy" format="default"/>.</t> <t>Each endpointSHOULD<bcp14>SHOULD</bcp14> know the identifier of the other endpoint with which it wants to connect andSHOULD<bcp14>SHOULD</bcp14> compare it with the other endpoint's identifier used in ImportedIdentity.context.ItHowever, it ishoweverimportant to remember that endpoints sharing the same group PSK can always impersonate each other.</t> <t>Considerations for external PSK usage extend beyond proper identification. When early data is used with an external PSK, the random value in the ClientHello 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 source on the client has a significant role in the protection of the early data.</t> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas no IANArequests.</t>actions.</t> </section> </middle> <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> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <referenceanchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> </reference> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> </reference> <reference anchor="I-D.ietf-tls-external-psk-importer" target="https://www.ietf.org/archive/id/draft-ietf-tls-external-psk-importer-06.txt">anchor="RFC9258" target="https://www.rfc-editor.org/info/rfc9258"> <front> <title>Importing ExternalPSKs 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- SharedPre-Shared Keys (PSKs)into TLS 1.3. </t> </abstract> </front> </reference> </references> <references> <name>Informative References</name> <reference anchor="RFC8773" target="https://www.rfc-editor.org/info/rfc8773"> <front> <title>TLS 1.3 ExtensionforCertificate-Based Authentication with an 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 aTLS1.3 extension that allows a server 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/rfc7925"> <front> <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title> <seriesInfo name="DOI" value="10.17487/RFC7925"/> <seriesInfo name="RFC" value="7925"/>1.3</title> <authorfullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig">initials='D' surname='Benjamin' fullname='David Benjamin'> <organization/> </author> <authorfullname="T. Fossati" initials="T." surname="Fossati">initials='C. A.' surname='Wood' fullname='Christopher Wood'> <organization/> </author> <datemonth="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 actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</t> <t>This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.</t> </abstract>month='July' year='2022'/> </front></reference> <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066"> <front> <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title> <seriesInfo name="DOI" value="10.17487/RFC6066"/><seriesInfo name="RFC"value="6066"/> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"> <organization/> </author> <date month="January" year="2011"/> <abstract> <t>This document provides specifications for existing TLS extensions. 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_request. [STANDARDS-TRACK]</t> </abstract> </front> </reference> <reference anchor="RFC6614" target="https://www.rfc-editor.org/info/rfc6614"> <front> <title>Transport Layer Security (TLS) Encryption for RADIUS</title>value="9258"/> <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 Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]</t> </abstract> </front>value="10.17487/RFC9258"/> </reference><reference anchor="RFC4122" target="https://www.rfc-editor.org/info/rfc4122"> <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 for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and 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</references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8773.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7925.xml"/> <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"/> <!-- [I-D.ietf-tls-dtls13] [RFCYYY2] isderived from the DCE specification with the kind permission of the OSF (now knownnow RFC 9147 --> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9147.xml"/> <!-- [I-D.ietf-tls-ctls] I-D Exists status asThe Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]</t> </abstract> </front> </reference> <reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2865"> <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 which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]</t> </abstract> </front> </reference> <reference anchor="I-D.ietf-tls-dtls13" target="https://www.ietf.org/archive/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.3ofthe Datagram Transport 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 Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. </t> </abstract> </front> </reference> <reference anchor="I-D.ietf-tls-ctls" target="https://www.ietf.org/archive/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" version7/22/22--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-ctls.xml"/> <!-- [I-D.irtf-cfrg-cpace] I-D Exists status as ofTLS 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> </abstract> </front> </reference> <reference anchor="I-D.irtf-cfrg-cpace" target="https://www.ietf.org/archive/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</organization> </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 parties 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 group7/22/22 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-irtf-cfrg-cpace.xml"/> <!-- [I-D.irtf-cfrg-opaque] I-D Exists status as ofboth prime- and non-prime order, and comes with a security proof providing composability guarantees. </t> </abstract> </front> </reference> <reference anchor="I-D.irtf-cfrg-opaque" target="https://www.ietf.org/archive/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 asymmetric 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> </abstract> </front> </reference> <reference anchor="I-D.mattsson-emu-eap-tls-psk" target="https://www.ietf.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 (PSK), EAP- TLS with TLS 1.3 explicitly forbids PSK authentication except when used for resumption.7/22/22 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-irtf-cfrg-opaque.xml"/> <!-- [draft-mattsson-emu-eap-tls-psk] Thisdocument specifies a separate EAP method (EAP-TLS-PSK) for use cases that require authentication based on external PSKs. </t> </abstract> </front> </reference>reference has expired --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.mattsson-emu-eap-tls-psk.xml"/> <reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf"> <front> <title>Selfie: reflections on TLS 1.3 with PSK</title> <authorinitials="N."initials="N" surname="Drucker" fullname="Nir Drucker"><organization/><organization /> </author> <authorinitials="S."initials="S" surname="Gueron" fullname="Shay Gueron"><organization/><organization /> </author> <dateyear="2019"/>month="May" year="2021"/> </front> <seriesInfo name="DOI" value="10.1007/s00145-021-09387-y"/> </reference> <reference anchor="AASS19" target="https://eprint.iacr.org/2019/421.pdf"> <front> <title>Continuing to reflect on TLS 1.3 with external PSK</title> <authorinitials="L."initials="L" surname="Akhmetzyanova" fullname="LiliyaAkhmetzyanova"> <organization/>Akhmetzyanov"> <organization /> </author> <authorinitials="E."initials="E" surname="Alekseev" fullname="Evgeny Alekseev"><organization/><organization /> </author> <authorinitials="E."initials="E" surname="Smyshlyaeva" fullname="Ekaterina Smyshlyaeva"><organization/><organization /> </author> <authorinitials="A."initials="A" surname="Sokolov" fullname="Alexandr Sokolov"><organization/><organization /> </author> <date month="April" year="2019"/> </front> </reference> <reference anchor="LwM2M" target="http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf"> <front> <title>Lightweight Machine to Machine Technical Specification</title> <author><organization/><organization>Open Mobile Alliance</organization> </author><date>n.d.</date><date month="February" year="2017"/> </front> <refcontent>version 1.0</refcontent> </reference> <reference anchor="GAA" target="https://www.etsi.org/deliver/etsi_tr/133900_133999/133919/12.00.00_60/tr_133919v120000p.pdf"> <front><title>TR33.919 version 12.0.0 Release 12</title><title>Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Generic Authentication Architecture (GAA); System description</title> <author><organization/><organization showOnFrontPage="true">ETSI</organization> </author><date>n.d.</date><date month="October" year="2014"/> </front> <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&v=1"> <front> <title>Technical Guideline TR-03112-7 eCard-API-Framework - Protocols</title><author> <organization/><author initials="" surname="" fullname=""> <organization>Bundesamt für Sicherheit in der Informationstechnik</organization> </author> <date month="April" year="2015"/> </front> <refcontent>version 1.1.5</refcontent> </reference> <reference anchor="Krawczyk" target="https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_24.pdf"> <front> <title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols</title><seriesInfo name="Annual International Cryptology Conference. Springer, Berlin, Heidelberg" value=""/><authorinitials="H."initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"><organization/><organization /> </author> <date year="2003"/> </front> <seriesInfo name="DOI" value="10.1007/978-3-540-45146-4_24"/> </reference> <reference anchor="Sethi" target="https://arxiv.org/pdf/1902.07550"> <front> <title>Misbinding Attacks on Secure Device Pairing and Bootstrapping</title><seriesInfo name="Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security" value=""/><authorinitials="M."initials="M" surname="Sethi" fullname="Mohit Sethi"><organization/><organization /> </author> <authorinitials="A."initials="A" surname="Peltonen" fullname="Aleksi Peltonen"><organization/><organization /> </author> <authorinitials="T."initials="T" surname="Aura" fullname="Tuomas Aura"><organization/><organization /> </author> <date month="May" year="2019"/> </front></reference> <reference anchor="RFC4279" target="https://www.rfc-editor.org/info/rfc4279"> <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="Eronen"> <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-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange 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/rfc3748"> <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 (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]</t> </abstract> </front>value="10.1145/3321705.3329813"/> </reference> <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> <section anchor="acknowledgements"numbered="true"numbered="false" toc="default"> <name>Acknowledgements</name> <t>This document is the output of the TLS External PSK Design Team, comprised of the following members: Benjamin Beurdouche, <contact fullname="Björn Haase"/>,Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel,<contact fullname="Christopher Wood"/>, <contact fullname="Colm MacCarthaigh"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Jonathan Hoyland"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Mohamad Badra"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Oleg Pekar"/>, <contact fullname="Owen Friel"/>, andRuss Housley.</t><contact fullname="Russ Housley"/>.</t> <t>This document was improved bya high qualityhigh-quality reviews byBen Kaduk<contact fullname="Ben Kaduk"/> andJohn Mattsson.</t><contact fullname="John Preuß Mattsson"/>.</t> </section> </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>