<?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 --> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-external-psk-importer-08" number="9258" submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.42.0 -->

  <front>
    <title abbrev="Importing External PSKs for TLS">Importing TLS 1.3">Importing External PSKs Pre-Shared Keys (PSKs) for TLS</title> TLS 1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-external-psk-importer-08"/> name="RFC" value="9258"/>
    <author initials="D." surname="Benjamin" fullname="David Benjamin">
      <organization>Google, LLC.</organization>
      <address>
        <email>davidben@google.com</email>
      </address>
    </author>
    <author initials="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="April" day="22"/>
    <area>General</area> month="July"/>

    <area>sec</area>
    <workgroup>tls</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.</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/draft-ietf-tls-external-psk-importer"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>

      <t>TLS 1.3 <xref target="RFC8446" format="default"/> supports Pre-Shared Key (PSK) authentication, wherein PSKs
can be established via session tickets from prior connections or externally via some external, out-of-band
mechanism. The protocol mandates that each PSK only be used with a single hash function.
This was done to simplify protocol analysis. TLS 1.2 <xref target="RFC5246" format="default"/>, in contrast,
has no such requirement, as a PSK may be used with any hash algorithm and the
TLS 1.2 pseudorandom function (PRF). While there is no known way in which the same
external PSK might produce related output in TLS 1.3 and prior versions, only limited
analysis has been done.  Applications SHOULD <bcp14>SHOULD</bcp14> provision separate PSKs for (D)TLS 1.3 and
prior versions. In cases where this is not possible, e.g., possible (e.g., there are already deployed already-deployed
external PSKs or provisioning is otherwise limited, re-using limited), reusing external PSKs across different
versions of TLS may produce related outputs, which may may, in turn turn, lead to security problems;
see <xref target="RFC8446" format="default"/>, Section E.7.</t> sectionFormat="of" section="E.7"/>.</t>
      <t>To mitigate against such problems, this document specifies a PSK Importer importer
interface by which external PSKs may be imported and subsequently bound to a specific
key derivation function (KDF) and hash function for use in TLS 1.3 <xref target="RFC8446" format="default"/>
and DTLS 1.3 <xref target="DTLS13" target="RFC9147" format="default"/>. In particular, it describes a
mechanism for importing PSKs derived from external PSKs by including the target KDF,
(D)TLS protocol version, and an optional context string to ensure uniqueness. This process yields a set of candidate
PSKs, each of which are bound to a target KDF and protocol, that are separate from those
used in (D)TLS 1.2 and prior versions. This expands what would normally have been a single
PSK and identity into a set of PSKs and identities.</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 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <t>The following terms are used throughout this document:</t>
      <ul
      <dl newline="false" spacing="normal">
        <li>External
        <dt>External PSK (EPSK): A (EPSK):</dt>
	<dd>A PSK established or provisioned out-of-band out of band (i.e., not
from a TLS connection) which that is a tuple of (Base Key, External Identity, Hash).</li>
        <li>Base Key: The Hash).</dd>
        <dt>Base Key:</dt>
	<dd>The secret value of an EPSK.</li>
        <li>External Identity: A EPSK.</dd>
        <dt>External Identity:</dt>
	<dd>A sequence of bytes used to identify an EPSK.</li>
        <li>Target protocol: The EPSK.</dd>
        <dt>Target protocol:</dt>
	<dd>The protocol for which a PSK is imported for use.</li>
        <li>Target KDF: The use.</dd>
        <dt>Target KDF:</dt>
	<dd>The KDF for which a PSK is imported for use.</li>
        <li>Imported use.</dd>
        <dt>Imported PSK (IPSK): A (IPSK):</dt>
	<dd>A TLS PSK derived from an EPSK, optional context string,
	target protocol, and target KDF.</li>
        <li>Non-imported PSK: An KDF.</dd>
        <dt>Non-imported PSK:</dt>
	<dd>An EPSK which that is used directly as a TLS PSK without being imported.</li>
        <li>Imported Identity: A imported.</dd>
        <dt>Imported Identity:</dt>
	<dd>A sequence of bytes used to identify an IPSK.</li>
      </ul> IPSK.</dd>
      </dl>
      <t>This document uses presentation language from <xref target="RFC8446" format="default"/>, Section 3.</t> sectionFormat="of" section="3"/>.</t>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>The PSK Importer importer interface mirrors that of the TLS Exporters exporter interface (see <xref target="RFC8446" format="default"/>)
in that it diversifies a key based on some contextual information. In contrast to the Exporters exporter
interface, wherein output uniqueness is achieved via an explicit label and context string,
the PSK Importer importer interface defined herein takes an external PSK and identity and "imports" it into
TLS, creating a set of "derived" PSKs and identities that are each unique. Each of these
derived PSKs are bound to a target protocol, KDF identifier, and optional context string.
Additionally, the resulting PSK binder keys are modified with a new derivation label
to prevent confusion with non-imported PSKs. Through this interface, importing external
PSKs with different identities yields distinct PSK binder keys.</t>
      <t>Imported keys do not require negotiation for use since a client and server will not agree upon
identities if imported incorrectly. Endpoints may incrementally deploy PSK Importer importer support
by offering non-imported PSKs for TLS versions prior to TLS 1.3.
Non-imported and imported PSKs
are distinct not equivalent since their identities are different. See <xref target="rollout" format="default"/> for more details.</t>
      <t>Endpoints which that import external keys MUST NOT <bcp14>MUST NOT</bcp14> use the keys that are input to the
import process for any purpose other than the importer, and MUST NOT they <bcp14>MUST NOT</bcp14> use the derived
keys for any purpose other than TLS PSKs. Moreover, each external PSK fed to the
importer process MUST <bcp14>MUST</bcp14> be associated with at most one hash function. function at most.  This
is analogous to the rules in Section 4.2.11 of <xref target="RFC8446" format="default"/>. sectionFormat="of" section="4.2.11"/>. See <xref target="security-considerations" format="default"/> for
more discussion.</t>
    </section>
    <section anchor="psk-import" numbered="true" toc="default">
      <name>PSK Import</name> Importer</name>
      <t>This section describes the PSK Importer importer interface and its underlying diversification
mechanism and binder key computation modification.</t>
      <section anchor="external-psk-diversification" numbered="true" toc="default">
        <name>External PSK Diversification</name>
        <t>The

        <t>As input, the PSK Importer importer interface takes as input an EPSK with External Identity <tt>external_identity</tt> and base key <tt>epsk</tt>,
as <tt>epsk</tt>
(as defined in <xref target="terminology" format="default"/>, format="default"/>) along with an optional context, and context. It then transforms it the input into a set of PSKs
and imported identities for use in a connection based on target protocols and KDFs.
In particular, for each supported target protocol <tt>target_protocol</tt> and KDF <tt>target_kdf</tt>,
	the importer constructs an ImportedIdentity structure as follows:</t>
        <artwork

<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="">
struct {
   opaque external_identity<1...2^16-1>; external_identity&lt;1...2^16-1&gt;;
   opaque context<0..2^16-1>; context&lt;0..2^16-1&gt;;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;
]]></artwork>
</sourcecode>
        <t>The list of ImportedIdentity.target_kdf values is maintained by IANA as described in <xref target="IANA" format="default"/>.
External PSKs MUST NOT <bcp14>MUST NOT</bcp14> be imported for (D)TLS 1.2 or prior versions. See <xref target="rollout" format="default"/> for
discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions
co-exist
coexist for incremental deployment.</t>
        <t>ImportedIdentity.context MUST <bcp14>MUST</bcp14> include the context used to determine the EPSK, if any exists.
For example, ImportedIdentity.context may include information about peer roles or identities
to mitigate Selfie-style reflection attacks <xref target="Selfie" format="default"/>. See <xref target="mitigate-selfie" format="default"/> for more details.
Since the EPSK is a key derived from an external protocol or sequence of protocols,
ImportedIdentity.context MUST <bcp14>MUST</bcp14> include a channel binding for the deriving protocols
<xref target="RFC5056" format="default"/>. The details of this binding are protocol specific and out of scope for
this document.</t>
        <t>ImportedIdentity.target_protocol MUST <bcp14>MUST</bcp14> be the (D)TLS protocol version for which the
PSK is being imported. For example, TLS 1.3 <xref target="RFC8446" format="default"/> uses 0x0304, which will
therefore also be used by QUICv1 <xref target="QUIC" target="RFC9000" format="default"/>. Note that this means the number
of PSKs derived from an EPSK is a function of the number of target protocols.</t>
        <t>Given an ImportedIdentity and corresponding EPSK with base key <tt>epsk</tt>, an Imported imported PSK
IPSK with base key <tt>ipskx</tt> is computed as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
   epskx = HKDF-Extract(0, epsk)
   ipskx = HKDF-Expand-Label(epskx, "derived psk",
                             Hash(ImportedIdentity), L)
]]></artwork>
        <t>L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in <xref target="IANA" format="default"/>.
For hash-based KDFs, such as HKDF_SHA256(0x0001), HKDF_SHA256 (0x0001), this is the length of the hash function
output, e.g., 32 octets for SHA256. This is required for the IPSK to be of length suitable
for supported ciphersuites. Internally, HKDF-Expand-Label uses a label corresponding to
ImportedIdentity.target_protocol, e.g.,
ImportedIdentity.target_protocol (e.g., "tls13" for TLS 1.3, as per <xref target="RFC8446" format="default"/>, Section 7.1, sectionFormat="of" section="7.1"/>
or "dtls13" for DTLS 1.3, as per <xref target="I-D.ietf-tls-dtls13" format="default"/>, Section 5.10.</t> target="RFC9147" sectionFormat="of" section="5.10"/>).</t>
        <t>The identity of <tt>ipskx</tt> as sent on the wire is ImportedIdentity, i.e., the serialized content
of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension.
The corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'.</t> "ipskx".</t>
        <t>As the maximum size of the PSK extension is 2^16 2<sup>16</sup> - 1 octets, an Imported Identity that exceeds
this size is likely to cause a decoding error. Therefore, the PSK Importer importer interface SHOULD <bcp14>SHOULD</bcp14> reject
any ImportedIdentity that exceeds this size.</t>
        <t>The hash function used for HKDF HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869" format="default"/> is that which is associated with the EPSK.
It is not the hash function associated with ImportedIdentity.target_kdf. If the EPSK
does not have such an associated hash function, SHA-256 <xref target="SHA2" format="default"/> SHOULD <bcp14>SHOULD</bcp14> be used.
Diversifying EPSK by ImportedIdentity.target_kdf ensures
that an IPSK is only used as input keying material to at most one KDF, KDF at most, thus satisfying
the requirements in <xref target="RFC8446" format="default"/>. See <xref target="security-considerations" format="default"/> for more details.</t>
        <t>Endpoints SHOULD <bcp14>SHOULD</bcp14> generate a compatible <tt>ipskx</tt> for each target ciphersuite they offer.
For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would
yield two PSKs, PSKs: one for HKDF-SHA256 and another for HKDF-SHA384. In contrast, if
TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one
derived key is necessary. Each ciphersuite uniquely identifies the target KDF.
Future specifications that change the way the KDF is negotiated will need to update this
specification to make clear how target KDFs are determined for the import process.</t>
        <t>EPSKs MAY <bcp14>MAY</bcp14> be imported before the start of a connection if the target KDFs, protocols, and
context string(s) are known a priori. EPSKs MAY <bcp14>MAY</bcp14> also be imported for early data use
if they are bound to the protocol settings and configuration that are required for
sending early data. Minimally, this means that the Application-Layer Protocol Negotiation (ALPN) value
<xref target="RFC7301" format="default"/>, QUIC transport parameters (if used for QUIC), and any other relevant
parameters that are negotiated for early data MUST <bcp14>MUST</bcp14> be provisioned alongside these EPSKs.</t>
      </section>
      <section anchor="schedule" numbered="true" toc="default">
        <name>Binder Key Derivation</name>
        <t>To prevent confusion between imported and non-imported PSKs, imported PSKs change
the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder
key computation is defined as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
           0
           |
           v
 PSK ->  HKDF-Extract = Early Secret
           |
           +-----> Derive-Secret(., "ext binder" | "res binder", "")
           |                     = binder_key
           V
]]></artwork>
        <t>Imported PSKs use the string "imp binder" rather than "ext binder" or "res binder"
when deriving <tt>binder_key</tt>.
This means the binder key is computed as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
           0
           |
           v
 PSK ->  HKDF-Extract = Early Secret
           |
           +-----> Derive-Secret(., "ext binder"
           |                      | "res binder"
           |                      | "imp binder", "")
           |                     = binder_key
           V
]]></artwork>
        <t>This new label ensures a client and server will negotiate use of an external PSK if
and only if (a) both endpoints import the PSK or (b) neither endpoint imports the
PSK. As <tt>binder_key</tt> is a leaf key, changing its computation does not affect any
other key.</t>
      </section>
    </section>
    <section anchor="deprecating-hash-functions" numbered="true" toc="default">
      <name>Deprecating Hash Functions</name>
      <t>If a client or server wishes to deprecate a hash function and no longer use it for TLS 1.3,
they remove
it removes the corresponding KDF from the set of target KDFs used for importing keys.
This does not affect the KDF operation used to derive Imported imported PSKs.</t>
    </section>
    <section anchor="rollout" numbered="true" toc="default">
      <name>Incremental Deployment</name>
      <t>In deployments that already have PSKs provisioned and in use with TLS 1.2, attempting
to incrementally deploy the importer mechanism would then result in concurrent use of
the already provisioned already-provisioned PSK both directly as both a TLS 1.2 PSK and as an EPSK, which which, in
turn turn, could mean that the same KDF and key would be used in two different protocol contexts.
This is not a recommended configuration; see <xref target="security-considerations" format="default"/> for more details.
However, the benefits of using TLS 1.3 and of using PSK importers may prove sufficiently
compelling that existing deployments choose to enable this noncompliant configuration for
a brief transition period while new software (using TLS 1.3 and importers) is deployed.
Operators are advised to make any such transition period as short as possible.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The PSK Importer importer security goals can be roughly stated as follows: avoid PSK re-use reuse across
      KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs
assume that input keying material (IKM) is sampled from some "source" probability distribution
and that any two IKM values are chosen independently of each other <xref target="Kraw10" format="default"/>. This source-independence requirement implies that the same IKM value cannot be used for two different
KDFs.</t>
      <t>PSK-based authentication is functionally equivalent to session resumption in that a connection
uses existing key material to authenticate both endpoints. Following the work of
<xref target="BAA15" format="default"/>, this is a form of compound authentication. Loosely
speaking, compound authentication is the property that an execution of multiple authentication
protocols, wherein at least one is uncompromised, jointly authenticates all protocols.
Authenticating Therefore, authenticating with an externally provisioned PSK, therefore, PSK should ideally authenticate both
the TLS connection and the external provisioning process. Typically, the external provision provisioning process
produces a PSK and corresponding context from which the PSK was derived and in which it should
be used. If available, this is used as the ImportedIdentity.context value. We refer to an
external PSK without such context as "context-free".</t>
      <t>Thus, in considering the source-independence and compound authentication requirements, the PSK
Import
importer interface described in this document aims to achieve the following goals:</t>
      <ol spacing="normal" type="1">
        <li>Externally provisioned PSKs imported into a TLS connection achieve compound authentication
of the provisioning process and connection.</li>
        <li>Context-free PSKs only achieve authentication within the context of a single connection.</li>
        <li>Imported PSKs are not used as IKM for two different KDFs.</li>
        <li>Imported PSKs do not collide with future protocol versions and KDFs.</li>
      </ol>
      <t>There are no known related outputs or security issues caused from the process
for computing Imported imported PSKs from an external PSK and the processing of existing
external PSKs used in (D)TLS 1.2 and below, as noted in <xref target="rollout" format="default"/>. However,
only limited analysis has been done, which is an additional reason why applications
SHOULD
<bcp14>SHOULD</bcp14> provision separate PSKs for (D)TLS 1.3 and prior versions, even when the
importer interface is used in (D)TLS 1.3.</t>
      <t>The PSK Importer importer does not prevent applications from constructing non-importer PSK identities
that collide with imported PSK identities.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>External PSK identities are commonly static by design so that endpoints may use them to
lookup
look up keying material. As a result, for some systems and use cases, this identity
may become a persistent tracking identifier.</t>
      <t>Note also that ImportedIdentity.context is visible in cleartext on the wire as part of
the PSK identity. Unless otherwise protected by a mechanism such as TLS Encrypted
ClientHello <xref target="ECH" target="I-D.ietf-tls-esni" format="default"/>, applications SHOULD NOT <bcp14>SHOULD NOT</bcp14> put sensitive information
in this field.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This specification introduces a new registry for TLS KDF identifiers, titled
      <t>IANA has created the "TLS KDF Identifiers", Identifiers" registry under the existing "Transport Layer Security (TLS) Parameters" heading.</t> registry.</t>
      <t>The entries in the registry are:</t> are as follows:</t>
      <table anchor="kdf-registry" align="center">
        <name>Target
        <name>TLS KDF Identifiers Registry</name>
        <thead>
          <tr>
            <th align="left">Value</th>
	    <th align="left">KDF Description</th>
            <th align="left">Value</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Reserved</td>
            <td align="left">0x0000</td>
	    <td align="left">N/A</td> align="left">Reserved</td>
            <td align="left">RFC 9258</td>
          </tr>
          <tr>
	    <td align="left">HKDF_SHA256</td>
            <td align="left">0x0001</td>
            <td align="left">
              <xref align="left">HKDF_SHA256</td>
            <td align="left"><xref target="RFC5869" format="default"/></td>
          </tr>
          <tr>
            <td align="left">HKDF_SHA384</td>
            <td align="left">0x0002</td>
	    <td align="left">
              <xref align="left">HKDF_SHA384</td>
            <td align="left"><xref target="RFC5869" format="default"/></td>
          </tr>
        </tbody>
      </table>
      <t>New target KDF values are allocated according to the following process:</t>
      <ul spacing="normal">
        <li>Values in the range 0x0000-0xfeff are assigned via Specification Required <xref target="RFC8126" format="default"/>.</li>
        <li>Values in the range 0xff00-0xffff are reserved for Private Use <xref target="RFC8126" format="default"/>.</li>
      </ul>
      <t>The procedures for requesting values in the Specification Required space are specified in Section 17 of <xref target="RFC8447" format="default"/>.</t> sectionFormat="of" section="17"/>.</t>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-tls-esni" to="ECH"/>
    <displayreference target="RFC9000" to="QUIC"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="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="RFC8447" target="https://www.rfc-editor.org/info/rfc8447">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <seriesInfo name="DOI" value="10.17487/RFC8447"/>
            <seriesInfo name="RFC" value="8447"/>
            <author fullname="J. Salowey" initials="J." surname="Salowey">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t>
              <t>This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</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="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.3 of the 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 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="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="RFC5056" target="https://www.rfc-editor.org/info/rfc5056">
          <front>
            <title>On the Use of Channel Bindings to Secure Channels</title>
            <seriesInfo name="DOI" value="10.17487/RFC5056"/>
            <seriesInfo name="RFC" value="5056"/>
            <author fullname="N. Williams" initials="N." surname="Williams">
              <organization/>
            </author>
            <date month="November" year="2007"/>
            <abstract>
              <t>The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer.  This allows applications to delegate session protection to lower layers, which has various performance benefits.</t>
              <t>This document discusses and formalizes the concept of channel binding to secure channels.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5869"/>
            <seriesInfo name="RFC" value="5869"/>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk">
              <organization/>
            </author>
            <author fullname="P. Eronen" initials="P." surname="Eronen">
              <organization/>
            </author>
            <date month="May" year="2010"/>
            <abstract>
              <t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/>
            <seriesInfo name="RFC" value="8126"/>
            <seriesInfo name="BCP" value="26"/>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well

<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.8447.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- [I-D.ietf-tls-dtls13] Published as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
        </reference> 9147. -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9147.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.5056.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

      </references>
      <references>
        <name>Informative References</name>

<reference anchor="SHA2"> anchor="SHA2" target="https://doi.org/10.6028/NIST.FIPS.180-4">
        <front>
          <title>Secure Hash Standard</title>
            <seriesInfo name="FIPS PUB 180-3" value=""/> Standard (SHS)</title>
          <author>
              <organization>National
            <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
          </author>
          <date year="2008" month="October"/> year="2015" month="August"/>
        </front>
        <seriesInfo name="FIPS PUB" value="180-4"/>
        <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
      </reference>

        <reference anchor="Selfie" target="https://eprint.iacr.org/2019/347.pdf">
	  <front>
	    <title>Selfie: reflections on TLS 1.3 with PSK</title>
          <author initials="N." initials="N" surname="Drucker" fullname="Nir Drucker">
              <organization/>
            <organization />
          </author>
          <author initials="S." initials="S" surname="Gueron" fullname="Shay Gueron">
              <organization/>
            <organization />
          </author>
          <date year="2019"/> month="May" year="2021"/>
        </front>
          <seriesInfo name="DOI" value="10.1007/s00145-021-09387-y"/>
        </reference>

        <reference anchor="Kraw10" target="https://eprint.iacr.org/2010/264">
          <front>
            <title>Cryptographic Extraction and Key Derivation: The HKDF Scheme</title>
            <seriesInfo name="Proceedings of CRYPTO 2010" value=""/>
            <author initials="H." surname="Krawczyk"> initials="H" surname="Krawczyk" fullname="Hugo Krawczyk">
              <organization/>
            </author>
	    <date month="May" year="2010"/>
          </front>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <seriesInfo name="DOI" value="10.17487/RFC5246"/>
            <seriesInfo name="RFC" value="5246"/>
            <author fullname="T. Dierks" initials="T." surname="Dierks">
              <organization/>
            </author>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <seriesInfo name="DOI" value="10.17487/RFC9000"/>
            <seriesInfo name="RFC" value="9000"/>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core
	  <refcontent>Proceedings of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front> Crypto 2010</refcontent>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>

        <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.3 of the 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 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="RFC7301" target="https://www.rfc-editor.org/info/rfc7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <seriesInfo name="DOI" value="10.17487/RFC7301"/>
            <seriesInfo name="RFC" value="7301"/>
            <author fullname="S. Friedl" initials="S." surname="Friedl">
              <organization/>
            </author>
            <author fullname="A. Popov" initials="A." surname="Popov">
              <organization/>
            </author>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author>
            <author fullname="E. Stephan" initials="E." surname="Stephan">
              <organization/>
            </author>
            <date month="July" year="2014"/>
            <abstract>
              <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="BAA15"> anchor="BAA15" target='https://doi.org/10.14722/ndss.2015.23277'>
          <front>
            <title>Verified Contributive Channel Bindings for Compound Authentication</title>
            <seriesInfo name="DOI" value="10.14722/ndss.2015.23277"/>
            <seriesInfo name="Proceedings 2015 Network and Distributed System Security" value="Symposium"/>
            <author initials="K" surname="Bhargavan" fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan"> Bhargavan">
              <organization/>
            </author>
            <author initials="A" surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud"> Delignat-Lavaud">
              <organization/>
            </author>
            <author initials="A" surname="Pironti" fullname="Alfredo Pironti" initials="A." surname="Pironti"> Pironti">
              <organization/>
            </author>
            <date month="February" year="2015"/>
          </front>
        </reference>
        <reference anchor="ECH" target="https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-14"/>
            <author fullname="Eric Rescorla">
              <organization>RTFM, Inc.</organization>
            </author>
            <author fullname="Kazuho Oku">
              <organization>Fastly</organization>
            </author>
            <author fullname="Nick Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="13" month="February" year="2022"/>
            <abstract>
              <t>   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft
          <refcontent>Proceedings 2015 Network and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

              </t>
            </abstract>
          </front> Distributed System Security</refcontent>
          <seriesInfo name="DOI" value="10.14722/ndss.2015.23277"/>
        </reference>

<!-- [ECH] [I-D.ietf-tls-esni] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-esni.xml"/>

      </references>
    </references>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank Eric Rescorla and Martin Thomson for discussions that led to the
production of this document, as well as Christian Huitema for input regarding privacy
considerations of external PSKs. John Mattsson provided input regarding PSK importer
deployment considerations. Hugo Krawczyk provided guidance for the security considerations.
Martin Thomson, Jonathan Hoyland, Scott Hollenbeck, Benjamin Kaduk, and others all
provided reviews, feedback, and suggestions for improving the document.</t>
    </section>
    <section anchor="mitigate-selfie" numbered="true" toc="default">
      <name>Addressing Selfie</name>
      <t>The Selfie attack <xref target="Selfie" format="default"/> relies on a misuse of the PSK interface.
The PSK interface makes the implicit assumption that each PSK
is known only to one client and one server. If multiple clients or
multiple servers with distinct roles share a PSK, TLS only
authenticates the entire group. A node successfully authenticates
its peer as being in the group whether the peer is another node
or itself. Note that this case can also occur when there are two
      nodes sharing a PSK without predetermined roles.</t>

      <t>Applications which that require authenticating finer-grained roles while still
configuring a single shared PSK across all nodes can resolve this
mismatch either by exchanging roles over the TLS connection after
the handshake or by incorporating the roles of both the client and the server
into the IPSK context string. For instance, if an application
identifies each node by MAC the Media Access Control (MAC) address, it could use the following
context string.</t>
      <artwork
 <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="">
  struct {
    opaque client_mac<0..2^8-1>; client_mac&lt;0..2^8-1&gt;;
    opaque server_mac<0..2^8-1>; server_mac&lt;0..2^8-1&gt;;
  } Context;
]]></artwork>
</sourcecode>
      <t>If an attacker then redirects a ClientHello intended for one node to a different
node, including the node that generated the ClientHello, the receiver will
compute a different context string and the handshake will not complete.</t>
      <t>Note that, in this scenario, there is still a single shared PSK across all nodes,
so each node must be trusted not to impersonate another node's role.</t>
    </section>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank <contact fullname="Eric Rescorla"/> and <contact fullname="Martin Thomson"/> for discussions that led to the
production of this document, as well as <contact fullname="Christian Huitema"/> for input regarding privacy
considerations of external PSKs. <contact fullname="John Preuß Mattsson"/> provided input regarding PSK importer
deployment considerations. <contact fullname="Hugo Krawczyk"/> provided guidance for the security considerations.
<contact fullname="Martin Thomson"/>, <contact fullname="Jonathan Hoyland"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Benjamin Kaduk"/>, and others all
provided reviews, feedback, and suggestions for improving the document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAPDHYmIAA81cW3MbN5Z+x6/AMg+Rask2KfkWZZIZWXJira9jydlKbe3a
YDdIImp2cxrdkhnb+e17LgAaaFK5VO3DqjJjkY0+AA7O5TsXaDKZiNa0pT6R
F+tN3bSmWsqnH1vdVKqUby6fW7moG3n14lKo+bzRN388rqjzSq2BYNGoRTsx
ul1M2tJOtBs92djriSEiuplMH4tctXpZN9sTadtCCLNpTmTbdLY9mk6/mR4J
1Wh1In/UlW5UKW7r5nrZ1N0GBpVWXOstfFPAsiokr9vJOU4rhG1VVbxXZV3B
Urbaio05kf/V1vlYWpi60QsLv23X+Mt/C6G6dlU3J0LKCfxPSlPZE3meySe6
+kWtTUVf8r7O1Y0p0gd1s1SV+VW1pq5gqXW9LPVYvnhxltFjvVamBIbgi3Nd
/WNJA7K8XqfznWXyNJP/WddFNN3ZqjG2rTcr3SRPYU54WNZdsSiBRfFEubr9
x0qrDRzS3LQ2A7YIIaq6WcMKbzTu8u0PZ0ez2Tfu18f37z86AdZXi3jM5bPT
oxOi60RkdKnzrtHymbIreYkMVk0xohFWN0ZbJHAif7h4cynfvHsiZ4+nk2N6
XMAZn8jXeVvPYRtwsI/p657r/DPhXb0iRoJgXVQWpu5aLetFmNBK+Fde6XxV
1WW93OJKdbkw2tHpF0tfSjjhUudI0cq6QhmVs+xY3pp2hZLL699ZijuX8EMH
9CqT502XX+smfcgn9co0u4/3kbnM5I+dbupqH5XLldomj5l3R9PZN25/qlnq
9kSu2nZjT+7d05vGVG1mVN5kwL57OPLe8f1H2aZYwBvPG3U7mw54c9ZsN229
bNRmZXJU5EYRh4i1z/VWnsN53jh5vlrBkT8//0Fe5iu91qPBsqb8OZaAN02d
a12A/Fk8ubO3P7+5eh2N/RNbmN47enh/z9EEfhInn2W0v/zX7bUQk8lEqrml
vQhxtTJWgjHq1rpqZaFt3pi5RuGBV8FWLFSuyWiZYNB0MGiNnsA5NJqYYeUB
WrhD0I+29vKT8XxrUxSlFuIrNEBNXXTERpjdSdmnT//G+vXwyxdpuw1OZQf0
ifwhbROWanJi+1jegsZrU5F1BSNZybmWGszavDR2BW/eGAVMtxaPDd661kB4
0dRrCcyEbeV1VQWxb8Leyi2/WK9Bqbp2Ui8mczh0sQZ9Ahtm1xmd96apwVbW
pVyj0rXAt3alWqlVTkoDigSEYEGdhZWQKgFN4GGp5Qqtw6KraO6Mz+FW4VlU
WgIDLTC8NIttP4eCdW2tsZlj7hGw7e/AtgdHyLYxnBfuBs7VtmMB5GUFVDpY
SaP/1ZlG4wmPJXyvaG1rNVxateVVqRIcDXyzJjkHdgs/4cbqrqgb+BoY6BcP
B/P2h0OwuSsD+2rxPKSh2a+r+raCXW1xbbegQyt8LC1osNCRWwT5WK5a3ClI
hob1lsDLAhm/6Vp818sJrofP7UY3eKTgnYjHpVkbeEV4HuFGYHe6In6Cw9gA
M1lkLFjs1+9enON0N4bkwuqNamDK3kUfnB9Gc4p0zgykGLwHSBVLH2wKZqQt
wyZqkLU5OjadLbOx44fC/5XgoostKNmmrLewWJ0gA5ggrAjVDOjV+PKtsdrv
bwy8mXQ21UJ8GUwCzCsLs1jAdFUr/FrRsOBO8LT389eO3dGs+ZzarqlkCSsl
KURXZlp6Fza1tt8Kq3Wir2PwKywHT7NHoO9XNRxna5bIT7VUYIBaFkNPYsz8
CkbHbnRuwAd5wbxwqEf0Bmi+dWtMd+1E2MGkgsTDdnML8g6EUfXqrqJ9KD9L
jlgIjsDb7UiKwXYfEolENUkcQEliMYy3L/CN8+gJ/j47/u5icp4FVFfA/82O
v3whyQFZA0PUARwBnU1sbm9eBiaXdkuLhl2S9UoZMceTy8sOfQmpGLsOCVsa
CyfLwY440RjTXsFg1huHI9B6AF0AmA3RqaWuLCKZrjLIUbCiaPbg7DbouUDe
tkaXiDRATlqUNLC/hUFDKHBZYzaE8D0fHipBdCL9Gp1e8/rGbENxcNBL2jK4
N6sF2Ss4i6ChR3usglum/riBZ6ilQPC27spCErxD875SN5othDfJuGaiZQp0
MC3ylEWHN8eK1j8Hic3QpZ3V1Q1+gdpGwqAXpjL0Gf2rlihxCL+tHL18d3k1
GvO/8tVr+v3t03++u3j79Bx/BzD54kX4xY9ggzUaC/db/+bZ65cvn74655fh
Wzn46uXpzyM+6NHrN1cXr1+dvhiRkgN7RNBA5DXsFFUJVW7TaNImG2STOP7k
7I2c3QcRd6gYXLVThNmj+6AIYAudUJFJ5o8gjFupNhutGqQBrAch2ZhWlZZ8
kV2hi0AbSby80g1ECwRY5aev2v7TF2bloi7L+pakE55ZWjlJRLuCaGe5ApOW
WhfA65MkBJMHTxFHnMhT+hRDhdgCs3n0fl8emEyDMQcDD8CKpFGRNejhw6ET
coPq0HabktD4wRNwE4hexv0iLpx4jSlCOMxggX4Uo0gwunAC8kaVHREBHcU1
Z/FOPBHcB9u7nMbOt4hCmCW1k1QAERGJK1Y7r24nKZBBu+O0lfiDjs2bV2cJ
IyKgu/w+KvGffPXCf0eHceEPA7mJ3yRWzi17fJeNGguPkiPzQaAlrA+nfFVX
ExNNC/MxYbdeYlcBEClHp0EIyS8HkREK1VyTT3ZEkn389aO4oKMYYO8O8QSo
noUP7JpKVS07tXTmj/Ru6HKPSWteg927MfqWdST2oRGIX5umqRuHUGF56CZw
l08/8lAbjT1gJ+8m7Kd7lD348gURPlNB72XI5jr3jZZurnDHiKoQPLvz6uDo
QtwMeJcQlAOryB1cTFhI7/h7eO+wYO+JSNHyldE3DuQDX8HeA8qDVZVqrksS
hKG8tHczqEC7DcTcjK265jgoQaqJfyC7yjJhR8gNdBgIlscSNFiR6w7uY+Qk
e7TPkfQ+j1wmbzOTT53/hFWD6/Oqwe/vdaa9FqBGOpkzunF2eb8WZeK0KAw/
KrdkswEj2q702EPOTQWT4/HyxOu6QLIhpqn0bYypiP0C1gXijK4R51t0BLXp
hWqgj+SvyX47KN2f/27YSdCC6QS4G3PSYZLCWHgtb4frB4UJmkv7KWrC7S5I
gq0s69aoBPoBPgD5UDIvDblLhJmgcUDx1oBDw9fVsgGV6TYQ1UZrMYveBAKN
umETAwdbFZsatmkd6s45PCNkwvFBKqUuJhYA9GrcMzJkh4s+uRhgkENFUTie
mkKSwZgCZhF7zvG2QRpMEzOYxzjOZ2Ab0FQ06Ji7FjABLmJd4xjdKlMiw/vd
Oh9Jc/aKRefgIRFxvGXYFOmFqVD/2VQIR8DDUJwSo9dN10D4pTluwlcrIuTT
qKwEO/M4tRI03++Qci4BhPUlbK++QYKkrYmBWLC571epm7BOmhpQlrK2zg3F
YKxALXAMDCGG/mleQBKQFWjrYIJ6WXfWm8umK1HCqmCc72dH2WyG5iKOT/wB
+UhuArpo4TQbDob5wAQfmLF5R5kS8iq9ADpXZd1EfcTyO9aUZAtOvEPNK7co
sMFXcCAeRTs4uNdRMBdrOGzWQTY1/AYu66sUzZ0PaP6eB3QW3TpZUh4D4BHs
ACv5wR/re2/vP/A6EavhKj/ojb3+MBaEk9l1wGl8+hSjVnDVmFxf+gzLjgl2
cKVRlUXvaL0XScMOkWhqpItRcKoiMNo74YFfYL8DvgHUchCKIikSZ2drdDF8
WX7gL977Lz54auHJdbH4wE42CD/KW9t0eUvO1NvewGZ+hlGmsg7eWwDtv/32
m+BH8hPmMuuNAo8od87kb7Msy47+Z/ZwMvv+22igY+/fpunTDng7eygH+9jz
CDbyrfiys9xvaWEkZBA00PkMh2Q9BYbwBFXWCsgrEhKw4Renr0534qtPn/Br
0FiRloyCwYpTHUmS6ohDlzQC3mOXRa/hKBsQesn9DsTn2va7GIjlwBH2c4m8
nuiPyA7KWvTOzLky/BC53cAoj0Jog5y/YIvsH3jsDJ6EdIqfckRgFmSnaV4Q
5h8oeavWG8y83TmTc7Y0UQRHpZojxt9o2BQwTFMyrtcyRDIhpcX1koltt6WO
iiZgw1uVX1tgOY/oLa9/dWLdgz0u8tK7WjZJxoPpYTQUXE3QSSAVBx1B0cd/
kt9gNsAIVwCX0QCjmcbVBb+IXwSagh3Lg+kDcixXq7ADBqmwbE8EXXZYo8+9
MQjtSG1sXm+osiCSeH2fnAy0NbhRXOQdya0oGEVP7Hg6COJkIjR7axEUlE0/
To+n932aFCGfoKzuoqasrq1DHh1U+5/vLs5uZpiax9++A1LfTKdTZNerutWM
Z2jHaw02n/ZQdeu5boRPMe2LgFkiQk7ShW/8In0amHlg449ApNprcjkuAixq
Aa7SafV+cOjdYgK4PHGxZ6iBoR8/4BrZc3PyKDXmWHfFYfI7qpJNXDXtYDqm
7w9xgEkHYPJu8gJjiQN6dRxiKAkfR+O0Ljj8weTKwXDvh2P54pBt+IuIBwFU
oS9zoWapq2W7+iMLP3T+3oSjaCGUm7AnRo875jQ4vIH7e4914wcPD0C4ptPZ
4TgUEXAZ/dz4KYGEgpfnywvHYPvzlopaMCPTdNlP+M8FNUXQaTo9TvUBcTeN
7QwmwbTAUb33zw1W0/GhppKHr4yNd8+H9US5uDuVLYiI/0ij/WZGlCYfxW6I
koQbEPK96Y9H2WwsYPCoiN48333173uz8T2dB9lsmrFbD8E98McLNuYpMfCr
OZ64NVzhGm4LnBJlCanGBYKqSvOrdimIqhV7JAmpkOFQtnd8FcM+ex3YFSWk
A+RGT1BZVzvUA56TxSCQ6w/eWzfUV5uvdAHRA87+NW3xa9j8KS9hrT6adbeG
4O9X7QUwmQ/fQkglJ3LmZC+1EmFzXAv9iDVuy1aeiMK/pbnWEOmCIOYK4asC
JcprWrrGLBX5Fjaw498LMlw6vNG/wEEKxAM7HI4XIcMi3GGnlR46CWQYlfGd
r3v8EBPdxkWifY53EMJ51w2wuvWlwB3d3XnrdywLaNwiUBVFrZkmlS3YjiTk
knnGaAgmYAkQjYBJgA04TjlHlQkfN22D+Z/vMi82dFwKwnNUrc9hUo0Sc/1e
hlnmQMaQKmArUgJKUEURLhalYGcQyVpAX5aWIDjnFOrUlq3pXwxj7847uO0v
qT2qJdQDngreBbMX1DxEQM6bRgaQ6xiUehlgzT5BxYjN2a73p08v38+OHr//
8eylM/XckOMewWf/6PjxfS5OCUpdyfa2llw+Q255eZxERFTFaYn4GVBJsqqI
kMUfLOTs2Sn8dzR9/+b1i59nx9MHYQAW37wjcCV2WEzIQOJGUcg1pjVUs3WZ
yphhnMKE90IS0g4qk8DIjgI/Dw9deZ4kDEHpkiEe9g9430yTcoKOdAizb5qD
hG6DhUeubCUU8eEaQn+Zl1iFwqinX4RLZ/kAo/eUaYoJhYmDsdOfkzhsziiQ
TD5QJdOdROJmMdg2nGsP0qm7IM3GHthDWhM3TyiO60wm+/k95EyCQQzKtthu
pFAbBU+7TdPEbVzpsbptqfXIpckXZtk1jmE+6RbjBwEukC10mCmTL01l1j5r
HIFaxdYvarsAoLAFkX3jp38V5VkpTBbczfLoeDpD14zomfMifA6qUWtNZYoD
2Fsw1Tjs0Jeyty5d1+hS3yhwudFbYU+R/Az45uOKuAhI2Rs0NJyD51PgPNQT
TlilfWDy01fevX6hXojdFPhct7dYd07SsDuR9ngQmrNChPpFlC0bJt53mgyc
cFJbYAACPRExTLmZHtPug/H+Zxp/+Bx/uBFEfvK9TLA+IPunxO1LKnDe+fq/
T/Dne+aqnvDoA8SHqCW86JH8LEfgj/xHeDg6TCjuDQq+c+Pfw57j0T9xTHCR
sNwniF0/BFZ6wuygKSExnCwL0Wi0LqqK96H0h376D67pq48DozP9o1Dq/8cZ
/DG/B6f0516I+Px/c6zEZ6xRcXzioMzvFHS8iSAR4Ap8kuQH1xr6HMAaHahD
MLKA53QAHM59eHXFbN38EAgbEhs/zg2zPkmRSUDhsYxw3A9+a4FiMWYrQEmM
1iY6GwCiAoyS45a2go0hvEfp/HMNpijnoiS1Jv/g0KIFuV/0zKCEkuOFXWnL
CTh+F4HTANGS7ZJoJbVLRbdJ/CbIDQGqq298ci+OVKhxgLt7tM94x945GPoe
Z3EVzxXP012HEH7jgGGUQkQ5TlIZ3L1zEaUrz0O6Esy4z5wKTJT3iUzvSVwz
H+FxshaJ16goHYDsIJzv0rRjzBLq9aYlxFvvr/slyfO+RMLtS9j76mqzrt8T
4HDj2geAd+Qf/NriFZG5r6lmOmxzwPyxL20r2/dcuFinEtQRmNP8aKx6946N
nKF/i7uccJDPhmG0Cli2r9IG7OEQjz9GFy8p2BnINDCk0ANI8q20fxn+P6tv
NRXpyLYC8l+g0tQIHlCM4jx3+JKUe+0bIlzTJEVcC4CThroKBeqdLkvutaPo
kiqmy0RK8lWN9UNqosPkCuMjcPP4dmmUgwQ96EKIpeS8MXrBuIcq8pjAMHWB
h1FqsmG2XrS3CGQOdvcRln7ITpwbTTPxmvQBuz+oEbUAsWC1IFyMwIlCyt1p
uUMLDBmmUlxnK6nNpW8MPUsOYk/9LbSQLmsArtK1aFO1v8Tyjxr4OKluasMC
S82u2jW3CrIHzAc4lA1WFZNucISm3v5iN7Km4iFAQSIfGUvQdM3eEDhCnRJW
QCjdrV16dn8Ue3Dx/CWx1VLk5/Kz1OQysnXX5HpELa5qbkrcLpbRGzPvKGnH
jdQUOW9JKYCYrw7hkeTY24gt93BmKP7UvQpSyQ2UZMc/feI7Cpx5xyCHJp30
7+RJCC2pgVzbgbqGifEkUOu8tlLgE6ur4DIh+iWXxUx775EX3g+QAcO5gTTO
Ta3DXGhCa7Xe8As+tIgCJEGpw6BCaEWSxEE/pR74WMzfh25AjBPr5hpNIMQR
T05PZw++O399gXm92f1HR0f3qgKiuKPp7EF2dHz06BGGGD7jqnDva+pfBSGh
YCndaSZfoDKD6kNgqa6xkeiuoT6DyxLq80+EH0APfPJ+jb012CKYviyiwNA3
PinMRCuXOsF0IRkQED1U4bH8BVmRKgKKVFnGtYDTVEt8LTq67DBwFa5tnfNv
YADQqoOS09CdExE+vxhFve7iQFKv6lvbfVAtr7YboBOajnZH+6HC9a77HvHd
EoYPokkr+7sGVK1QfVHFeWbn21q3OeHzYph0UzfgPxS18HsJiXO0d5bVSKvA
8FBZUFPbjarSew6+m5CsrX8P6I7c75NFo/WIkpOd9Tc6yLx6Id+n9MyM/eIY
59RCKtXFOUnvW1SITtvzlVkTBnTNdkSjb8Mlow5xySwLLRS74mTjLijqbRiK
i6N9xy6orr/werUjRz6D4ahl4ihDtxQY6u5XIFj3Ew24hOficuv+VCiP4+7q
xLSPsxREck6hboOMoIHdsaWu5eL+8GXXfAZqWmKOgTRzwVmxYUkzbt0QV+FW
SbhmM7jVwTjeuV4D3k1bTrYXPd72yrWgi1DoH5Gr6Qp3Ks9e/SIC+BY6K2fE
Bxdb7ujYh0isvqUaDXDAl89Cu0ImPXwT8QUfuf+CzzhKzIM0hW5GYIqyeL4r
akIPV4DEX74CtHPtCLM61OOetnr1KmX27Pw42wOQQhDjU0XxSpn/oYdm0PfX
MGCNOhUodxpLU5xFGt5ceIOJo3wXwyUdVoPOPwTodCKI3EyOZQMwHmaJ/b4O
Die9jS6JssY6YFnX191miKwo6FUuquE+JEJVdmshWGKxRyp048rbZGd8BV8B
ynG8QtAKokEVNIR31xQohx5Y2DKV4Cl9Siu905TDDCgXCNvRBmPemI1CVABE
RMwJ35CU86vK5LuqRMPUX+BCbQYTwj0CKorrfE2YWrEhHtxu8B7bGcXizyDK
qLF8+fTsWXqhSNvKUHPZnntt2CqEANZqAvM3SauL8PZ9gbUGjoCxGSkVAQh/
qZDtG/+SdLpxVzjJGWNE0uglYt1Q+xj0HuOZ4YXaQoz8w4v+4WjMLYIOADgY
OLoKmV/OG4d44wBoHMo3IbE7kisIdqmLmVQLCDeGGyO5puTWBrILbuozTX9O
3o4xKeWUfiJADL+81WSvc/wgPp9Mdn/Cl8lTGAzvUt6kSLJVVN6fys+v7p1G
ibbPcQvAYPBMfo5Lj/FgrBSlg4+Ggz+dyK+ui8Uk7JtY/92ov7AB6+RHIzje
VzouhsQRCfjxOufYLAek5Ur5A+/v7D9dsvnJ9bo5vlP5hnc/mX5c6MWCyVq0
Fa5l/zKRq7e+2OBvFR1h3e9OyosFU144yo1nP0ohWTbQ9XdWD8iJK++3CkoC
4mgESZoF7yaZ644F2g11uPalKzbzvptg9ihpwn1E0+I16DnYJNS40xxdNmjE
koEZL4ovcFO8Vl3Lpw0YVxAp4H2puHEZU/oVxH712roOp76fz4V5Zd99vAn3
rENzlsd05HVvwbjgv/yXEwz4zWdYuFsr18WHJgSkSPHRb9hViDTvwl4/cvaZ
/I96VcFS29Zahu83piD2pPTiRIvo8yYypQ8ooFvW4fJ6T27ZmUJV7mo6pw6d
fRgQECnXxrC+SlHW/lm9LYGtY3mZ120LH0uIXMGVXI/DX62Qz1XRXbu7E2jK
KbISYRXgr42+Bfu20LrAwx27K6jLJYoTuW9OXeIbDsFHnW4gCUXROADFbYNg
eYf9giwd7jG3GUZdhoj70N4hipYQFLqMdXBJHo9kAXhEV4KoIdolHPnmDOVB
Nn0V0F9lxxZ0xpnk/EHGMB6N8uf4kfPGFESFCJeHIBwV4TseFy5xuOsG3Hlp
V2QmOApFf4HziTS8bdnOoxemP3ICCAJQUUGNEWiPFt0wULUCc3/U4KlCHyDr
OFFAJOcKOpqHEZTkzAuSxi4jIAFM32nkQ1xCaS0CFnUOghiAoQPpEAsIpMLb
42aBOB4E5BeVoIkR2JETO3cGuP6WyiDvhcW6ZrJsVP++y5QBb0FifabRXUji
qMbyn1YgPM/XxxVdZik0Z+lAMOvyxlXUQbIAQOBlB65gzLH1NlQjXNPsje6b
jeLoboFKzt0wVQHTXmuMTvjSct2AEeBdkHVnSgvO9VBANqzR8B+YCN1sg7tM
1NSJl87RPLg24RgmiagfgYSbBAfW8vL0DCMHVEe6l80Jb18DDD5vUK3PfEku
blYPTei09PdrlXMf+mPfhu4H8IZ2B3zx8avrN7/gXZDuM4/xeDiVjygshouo
3pRAR9ODWkkbpKi7T+3hd+PBnXEeh2Lt22Q4yIuI+7thuTa+WCZcnTImP7xJ
7sPF/vjDvSnKhoPoe3CO849DEsLmugJ9qf2fUcCvUKD/lBCPBahjf8TrzlKy
k/5oki64Q6tGywemCJ2CThT+a0uymIn/BbFL2w79SQAA

-->
</rfc>