<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.0.7) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!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-emu-bootstrapped-tls-11" number="9966" updates="" obsoletes="" submissionType="IETF" xml:lang="en" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">

<!--[rfced] Might we remove the abbreviation from the title as it
     currently doesn't share a 1:1 relationship with the expansion?
     Or is there a way to match them up?

Original:
Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)

Expansion of TLS-POK per the document:
TLS Proof of Knowledge
-->
  <front>
    <title abbrev="TLS-POK">Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)</title>
    <seriesInfo name="RFC" value="9966"/>
    <author initials="O." surname="Friel" fullname="Owen Friel">
      <organization>Cisco</organization>
      <address>
        <email>ofriel@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Harkins" fullname="Dan Harkins">
      <organization>Hewlett-Packard Enterprise</organization>
      <address>
        <email>daniel.harkins@hpe.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="01"/> year="2026" month="April"/>
    <area>SEC</area>
    <workgroup>emu</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>

<?line 69?>
<t>This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a TLS server. Bootstrapping devices have a public/private key pair, and pair; this mechanism enables a TLS server to prove to the device that it knows the public key, key and enables the device to prove to the TLS server that it knows the private key. The mechanism leverages existing Device Provisioning Protocol (DPP) and TLS standards and can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server.</t>
    </abstract>
  </front>
  <middle>
    <?line 73?>

<section anchor="introduction"><name>Introduction</name>

<t>On-boarding anchor="introduction">
      <name>Introduction</name>
      <t>Onboarding devices with no, or limited, user interface can be difficult.  Sometimes a credential is needed to access an a network based on  <xref target="IEEE802.1X"></xref>/EAP-based network, target="IEEE802.1X"/> or EAP, and network connectivity is needed to obtain a credential.
This poses a challenge for on-boarding onboarding devices.</t>
      <t>If a device has a public / private keypair, public/private key pair, and trust in the integrity of a device's public key can be obtained in an out-of-band fashion, a device can be authenticated and provisioned with a usable credential for <xref target="IEEE802.1X"></xref>/EAP-based target="IEEE802.1X"/> / EAP-based network access.  While this authentication can be strong, the device's authentication of the network is somewhat weaker.  <xref target="duckling"></xref> target="DUCKLING"/> presents a functional security model to address this asymmetry.</t>
      <t>Device on-boarding onboarding protocols such as the Device Provisioning Profile <xref target="DPP"></xref>, target="DPP"/>, also referred to as Wi-Fi Easy Connect, address this use case case, but they have drawbacks. For instance, <xref target="DPP"></xref> for instance target="DPP"/> does not support wired network access, access and does not specify how the device's DPP keypair key pair can be used in a TLS handshake.  This document describes an an authentication mechanism that a device can use to mutually authenticate against a TLS server, server and describes how that authentication protocol can be used in an EAP exchange for <xref target="IEEE802.1X"></xref> wired network access. access as described in <xref target="IEEE802.1X"/>. This protocol is called TLS "TLS Proof of Knowledge Knowledge" or TLS-POK.</t> "TLS-POK".</t>
      <t>This document does not address the problem of wireless network discovery, where a bootstrapping device detects multiple different wireless networks and needs a more robust and scalable mechanism than simple round-robin to determine the correct network to attach to. DPP addresses this issue for Wi-Fi Wi-Fi, but DPP's discovery will not work on a wired 802.1X <xref target="IEEE802.1X"/> ethernet port, but TLS-POK will. Therefore, TLS-POK <bcp14>SHOULD NOT</bcp14> be used for bootstrapping against wireless networks, networks and <bcp14>SHOULD</bcp14> be used for bootstrapping against wired networks.</t>
      <section anchor="terminology"><name>Terminology</name>

<t>The anchor="terminology">
        <name>Terminology</name>
        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

<?line -18?> here.
        </t>

<!--[rfced] We note that the Terminology section defines "802.1X".
     However, most uses in the document are actually the citation.
     Please review and let us know if/how to update. -->

	<t>The following terminology is used throughout this document.</t>

<t><list style="symbols">
  <t>802.1X: IEEE
        <dl spacing="compact">
          <dt>802.1X:</dt><dd>IEEE Port-Based Network Access Control</t>
  <t>BSK: Bootstrap Key Control <xref target="IEEE802.1X"/></dd>

            <dt>BSK:</dt><dd>Bootstrap Key, which is an elliptic curve public/private key pair from a cryptosystem suitable for doing ECDSA</t>
  <t>DPP: Device ECDSA</dd>
            <dt>DPP:</dt><dd>Device Provisioning Protocol <xref target="DPP"></xref></t>
  <t>EAP:  Extensible target="DPP"/></dd>
            <dt>EAP:</dt><dd>Extensible Authentication Protocol <xref target="RFC3748"/></t>
  <t>EC:  Elliptic Curve</t>
  <t>ECDSA: Elliptic target="RFC3748"/></dd>
            <dt>EC:</dt><dd>Elliptic Curve</dd>
            <dt>ECDSA:</dt><dd>Elliptic Curve Digital Signature Algorithm</t>
  <t>EPSK: External Algorithm</dd>
            <dt>EPSK:</dt><dd>External Pre-Shared Key</t>
  <t>EST: Enrollment Key</dd>
            <dt>EST:</dt><dd>Enrollment over Secure Transport <xref target="RFC7030"/></t>
  <t>NAI: Network target="RFC7030"/></dd>
            <dt>NAI:</dt><dd>Network Access Identifier</t>
  <t>PSK: Pre-Shared Key</t>
  <t>TEAP: Tunnel Identifier</dd>
            <dt>PSK:</dt><dd>Pre-Shared Key</dd>
            <dt>TEAP:</dt><dd>Tunnel Extensible Authentication Protocol <xref target="RFC7170"/></t>
</list></t> target="RFC9930"/></dd>
        </dl>
      </section>
      <section anchor="bootstrapping-overview"><name>Bootstrapping anchor="bootstrapping-overview">
        <name>Bootstrapping Overview</name>
        <t>A bootstrapping device holds a public / private elliptic curve public/private Elliptic Curve (EC) key pair pair, which this document refers to as a Bootstrap Key (BSK). "Bootstrap Key" (or "BSK"). The private key of the BSK is known only by the device. The public key of the BSK is known is:</t>
	<ul spacing="compact">
	  <li>known by the device, is known device,</li>
	  <li>known by the owner or holder of the device, and is provisioned and</li>
	<li>provisioned on the TLS server by the TLS server operator. In operator.</li></ul>
	<t>In order to establish trust and mutually authenticate, the TLS server proves to the device that it knows the public part of the BSK, and the device proves to the TLS server that it knows the private part of the BSK. More details on the BSK are given in <xref target="bootstrap-key"/>.</t>
        <t>The TLS server could be an EAP server for <xref target="IEEE802.1X"></xref> target="IEEE802.1X"/> network access, access or could could, for example example, be an Enrollment over Secure Transport (EST) <xref target="RFC7030"/> server. In the case of authentication against an EAP server, the EAP server <bcp14>SHOULD</bcp14> provision the device with a credential that it uses for subsequent EAP authentication.</t>
      </section>
      <section anchor="eap-network-access"><name>EAP anchor="eap-network-access">
        <name>EAP Network Access</name>
        <t>Enterprise deployments typically require an <xref target="IEEE802.1X"></xref>/EAP-based target="IEEE802.1X"/> / EAP-based authentication to obtain network access. Protocols like Enrollment over Secure Transport (EST) <xref target="RFC7030"/> can be used to enroll devices with a Certification Authority to allow them to authenticate using 802.1X/EAP. IEEE 802.1X / EAP. This creates a problem for bootstrapping devices where a certificate is needed for EAP authentication and 802.1X network access is needed to obtain a certificate.</t>

<!--[rfced] Is there text missing here?  Specifically, please focus on
     the part beginning with "for instance".  (Note that RFC 7170 has
     been obsoleted by RFC 9930.)

Original:
   Devices whose BSK public key can be obtained in an out-of-band
   fashion and provisioned on the EAP server can perform a TLS-based EAP
   exchange, for instance Tunnel Extensible Authentication Protocol
   (TEAP) [RFC7170], and authenticate the TLS exchange using the
   authentication mechanisms defined in Section 3.

-->

        <t>Devices whose BSK public key can be obtained in an out-of-band fashion and provisioned on the EAP server can perform a TLS-based EAP exchange, for instance Tunnel Extensible Authentication Protocol (TEAP) <xref target="RFC7170"/>, target="RFC9930"/>, and authenticate the TLS exchange using the authentication mechanisms defined in <xref target="bootstrapping-in-tls-13"/>. This network connectivity can then be used to perform an enrollment protocol (such as provided by <xref target="RFC7170"/>) target="RFC9930"/>) to obtain a credential for subsequent EAP authentication. Certificate lifecycle management may also be performed in subsequent TEAP transactions..</t> transactions.</t>
      </section>
      <section anchor="supported-eap-methods"><name>Supported anchor="supported-eap-methods">
        <name>Supported EAP Methods</name>
        <t>This document defines a bootstrapping mechanism that results in a certificate being provisioned on a device that can be used for subsequent EAP authentication. Therefore, an EAP method supporting the provisioning of a certificate on a device is required. The only EAP method that currently supports provisioning of a certificate on a device is TEAP, therefore TEAP; therefore, this document assumes that TEAP is the only supported EAP method. Section <xref target="using-tls-bootstrapping-in-eap"/> describes how TLS-POK is used with TEAP, including defining a suitable Network Access Identifier (NAI).</t> NAI.</t>
        <t>If future EAP methods are defined supporting certificate provisioning, then TLS-POK could potentially be used with those methods. Defining how this would work is out of scope of this document.</t>
      </section>
    </section>
    <section anchor="bootstrap-key"><name>Bootstrap anchor="bootstrap-key">
      <name>Bootstrap Key</name>
      <t>The mechanism for device on-boarding onboarding defined in this document relies on an elliptic curve (EC) bootstrap key (BSK). EC BSK. This BSK <bcp14>MUST</bcp14> be from a cryptosystem suitable for doing ECDSA. A bootstrapping client device has an associated EC BSK. The BSK may be static and baked into device firmware at manufacturing time, time or may be dynamic and generated at on-boarding onboarding time by the device. The BSK public key <bcp14>MUST</bcp14> be encoded as the DER representation of an ASN.1 SEQUENCE SubjectPublicKeyInfo from <xref target="RFC5480"/>. The subjectPublicKey <bcp14>MUST</bcp14> be the compressed format of the public key. Note that the BSK public key encoding <bcp14>MUST</bcp14> include the ASN.1 AlgorithmIdentifier in addition to the subjectPublicKey. If the BSK public key can be shared in a trustworthy manner with a TLS server, a form of "entity authentication" entity authentication (the step from which all subsequent authentication proceeds) can be obtained.</t>
      <t>The exact mechanism by which the TLS server gains knowledge of the BSK public key is out of scope of this specification, but possible mechanisms include scanning a QR code to obtain a base64 encoding of the DER representation of the ASN.1 SubjectPublicKeyInfo or uploading of a Bill of Materials (BOM) which that includes this information. More information on QR encoding is given in <xref target="alignment-with-wi-fi-alliance-device-provisioning-profile"/>. If the QR code is physically attached to the client device, or the BOM is associated with the device, the assumption is that the BSK public key obtained in this bootstrapping method belongs to the client. In this model, physical possession of the device implies legitimate ownership of the device.</t>
      <t>The TLS server may have knowledge of multiple BSK public keys corresponding to multiple devices, and existing TLS mechanisms are leveraged that enable the server to identify a specific bootstrap public key corresponding to a specific device.</t>
      <t>Using the process defined herein, the client proves to the TLS server that it has possession of the private key of its BSK. Provided that the mechanism in which the server obtained the BSK public key is trustworthy, a commensurate amount of authenticity of the resulting connection can be obtained. The server also proves that it knows the client's BSK public key key, which, if the client does not gratuitously expose its public key, can be used to obtain a modicum of correctness, that the client is connecting to the correct server (see <xref target="duckling"></xref>).</t> target="DUCKLING"/>).</t>
      <section anchor="alignment-with-wi-fi-alliance-device-provisioning-profile"><name>Alignment anchor="alignment-with-wi-fi-alliance-device-provisioning-profile">
        <name>Alignment with Wi-Fi Alliance Device Provisioning Profile</name>

        <t>The definition of the BSK public key aligns with <xref target="DPP"></xref>. target="DPP"/>. This, for example, enables the QR code format as defined in <xref target="DPP"></xref> target="DPP"/> to be reused for TLS-POK. Therefore, a device that supports both wired LAN and Wi-Fi LAN connections can have a single QR code printed on its label, or dynamically display a single QR code on a display, and the bootstrap key BSK can be used for DPP if the device bootstraps against a Wi-Fi network, network or TLS-POK if the device bootstraps against a wired network. Similarly, a common bootstrap public key format could be imported into a BOM into a server that handles devices connecting over both wired and Wi-Fi networks.</t>
        <t><xref target="DPP"></xref>, target="DPP"/>, and therefore TLS-POK, does not support the use of RSA or post-quantum postquantum crypto systems due to the size of public key and its unsuitableness to be represented in a QR code. If <xref target="DPP"></xref> target="DPP"/> is modified in the future to support post-quantum postquantum crypto systems, this memo document will be updated to track support.</t>
        <t>Any bootstrapping method defined for, or used by, <xref target="DPP"></xref> target="DPP"/> is compatible with TLS-POK.</t>
      </section>
    </section>
    <section anchor="bootstrapping-in-tls-13"><name>Bootstrapping anchor="bootstrapping-in-tls-13">
      <name>Bootstrapping in TLS 1.3</name>
      <t>Bootstrapping in TLS 1.3 leverages <xref target="RFC8773"/> Certificate-Based Authentication (as per <xref target="RFC8773"/>) with an External Pre-Shared Key. EPSK. The External PSK (EPSK) EPSK is derived from the BSK public key as described in <xref target="external-psk-derivation"/>, and the EPSK is imported using <xref target="RFC9258"/> Importing "Importing External Pre-Shared Keys (PSKs) for TLS 1.3. 1.3" <xref target="RFC9258"/>. As the BSK public key is an ASN.1 SEQUENCE SubjectPublicKeyInfo from <xref target="RFC5480"/>, and not a full PKI Certificate, the Certificate. The client must present the BSK as a raw public key as described in <xref target="RFC7250"/> and use ECDSA as defined in <xref target="NIST.FIPS.186-5"/> for authentication.</t>
      <t>The TLS PSK handshake gives the client proof that the TLS server knows the BSK public key. Certificate-based authentication of the client to the server using the BSK gives the server proof that the client knows the BSK private key. This satisfies the proof of ownership requirements outlined in <xref target="introduction"/>.</t>
      <section anchor="external-psk-derivation"><name>External PSK anchor="external-psk-derivation">
        <name>EPSK Derivation</name>
        <t>An EPSK <xref target="RFC9258"/> EPSK is made up of the tuple of (Base Key, External Identity, Hash). The Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key. Zero byte Zero-byte padding <bcp14>MUST NOT</bcp14> be added to the DER-encoded representation of the BSK public key.</t>
        <t>The External Identity is derived from the DER-encoded representation of the BSK public key using <xref target="RFC5869"/> with the SHA-256 hash algorithm <xref target="sha2"></xref> target="SHA2"/> as follows:</t>

<figure><artset><artwork
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="160" width="480" viewBox="0 0 480 160" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <g class="text">
                <text x="28" y="36">epskid</text>
                <text x="64" y="36">=</text>
                <text x="188" y="36">HKDF-Expand(HKDF-Extract(&lt;&gt;,</text>
                <text x="324" y="36">Base</text>
                <text x="368" y="36">Key),</text>
                <text x="280" y="52">&quot;tls13-bspsk-identity&quot;,</text> y="52">"tls13-bspsk-identity",</text>
                <text x="388" y="52">L)</text>
                <text x="28" y="68">where:</text>
                <text x="24" y="84">-</text>
                <text x="60" y="84">epskid</text>
                <text x="100" y="84">is</text>
                <text x="128" y="84">the</text>
                <text x="164" y="84">EPSK</text>
                <text x="220" y="84">External</text>
                <text x="292" y="84">Identity</text>
                <text x="24" y="100">-</text>
                <text x="52" y="100">Base</text>
                <text x="88" y="100">Key</text>
                <text x="116" y="100">is</text>
                <text x="144" y="100">the</text>
                <text x="208" y="100">DER-encoded</text>
                <text x="280" y="100">ASN.1</text>
                <text x="388" y="100">subjectPublicKeyInfo</text>
                <text x="92" y="116">representation</text>
                <text x="164" y="116">of</text>
                <text x="192" y="116">the</text>
                <text x="224" y="116">BSK</text>
                <text x="268" y="116">public</text>
                <text x="312" y="116">key</text>
                <text x="24" y="132">-</text>
                <text x="40" y="132">L</text>
                <text x="76" y="132">equals</text>
                <text x="120" y="132">32,</text>
                <text x="152" y="132">the</text>
                <text x="196" y="132">length</text>
                <text x="236" y="132">in</text>
                <text x="276" y="132">octets</text>
                <text x="316" y="132">of</text>
                <text x="344" y="132">the</text>
                <text x="392" y="132">SHA-256</text>
                <text x="452" y="132">output</text>
                <text x="24" y="148">-</text>
                <text x="44" y="148">&lt;&gt;</text>
                <text x="68" y="148">is</text>
                <text x="88" y="148">a</text>
                <text x="116" y="148">NULL</text>
                <text x="156" y="148">salt</text>
                <text x="200" y="148">which</text>
                <text x="236" y="148">is</text>
                <text x="256" y="148">a</text>
                <text x="292" y="148">string</text>
                <text x="332" y="148">of</text>
                <text x="352" y="148">L</text>
                <text x="384" y="148">zeros</text>
              </g>
            </svg>
</artwork><artwork
          </artwork>
          <artwork type="ascii-art"><![CDATA[
epskid = HKDF-Expand(HKDF-Extract(<>, Base Key),
                       "tls13-bspsk-identity", L)
where:
  - epskid is the EPSK External Identity
  - Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo
    representation of the BSK public key
  - L equals 32, the length in octets of the SHA-256 output
  - <> is a NULL salt salt, which is a string of L zeros
]]></artwork></artset></figure>
]]></artwork>
        </artset>
        <t>SHA-256 <bcp14>MUST</bcp14> be used when deriving epskid using <xref target="RFC5869"/>.</t>
        <t>The <xref target="RFC9258"/> ImportedIdentity structure <xref target="RFC9258"/> is defined as:</t>

<figure><artset><artwork
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="128" width="328" viewBox="0 0 328 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <g class="text">
                <text x="28" y="36">struct</text>
                <text x="64" y="36">{</text>
                <text x="52" y="52">opaque</text>
                <text x="204" y="52">external_identity&lt;1...2^16-1&gt;;</text>
                <text x="52" y="68">opaque</text>
                <text x="160" y="68">context&lt;0..2^16-1&gt;;</text>
                <text x="52" y="84">uint16</text>
                <text x="148" y="84">target_protocol;</text>
                <text x="52" y="100">uint16</text>
                <text x="128" y="100">target_kdf;</text>
                <text x="8" y="116">}</text>
                <text x="88" y="116">ImportedIdentity;</text>
              </g>
            </svg>
</artwork><artwork
          </artwork>
          <artwork type="ascii-art"><![CDATA[
struct {
   opaque external_identity<1...2^16-1>;
   opaque context<0..2^16-1>;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;
]]></artwork></artset></figure>
]]></artwork>
        </artset>

<!--[rfced] Is the following text a comment?  If so, may we request it
     be updated as follows (as this is in SVG, we assume the authors
     will update and regenerate.

Original:
   target_kdf = <as per RFC9258>

Perhaps:
   target_kdf = <as per RFC 9258>
-->
        <t>and is created using the following values:</t>

<figure><artset><artwork
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="96" width="264" viewBox="0 0 264 96" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <g class="text">
                <text x="72" y="36">external_identity</text>
                <text x="152" y="36">=</text>
                <text x="188" y="36">epskid</text>
                <text x="32" y="52">context</text>
                <text x="72" y="52">=</text>
                <text x="128" y="52">&quot;tls13-bsk&quot;</text> y="52">"tls13-bsk"</text>
                <text x="64" y="68">target_protocol</text>
                <text x="136" y="68">=</text>
                <text x="204" y="68">TLS1.3(0x0304)</text>
                <text x="44" y="84">target_kdf</text>
                <text x="96" y="84">=</text>
                <text x="120" y="84">&lt;as</text>
                <text x="152" y="84">per</text>
                <text x="204" y="84">RFC9258&gt;</text>
              </g>
            </svg>
</artwork><artwork
          </artwork>
          <artwork type="ascii-art"><![CDATA[
external_identity = epskid
context = "tls13-bsk"
target_protocol = TLS1.3(0x0304)
target_kdf = <as per RFC9258>
]]></artwork></artset></figure>
]]></artwork>
        </artset>
        <t>The ImportedIdentity context value <bcp14>MUST</bcp14> be "tls13-bsk". This informs the server that the mechanisms specified in this document for deriving the EPSK and executing the TLS handshake <bcp14>MUST</bcp14> be used. The EPSK and ImportedIdentity are used in the TLS handshake as specified in <xref target="RFC9258"/>. Multiple ImportedIdentity values may be imported as per <xref target="RFC9258"/> section 5.1. target="RFC9258" section="5.1"/>. The target_kdf follows <xref target="RFC9258"/> and aligns with the cipher suite hash algorithms advertised in the TLS 1.3 handshake between the device and the server.</t>
        <t>A server can choose a tradeoff trade-off between performance and storage by precomputing the identity of every bootstrapped key with every hash algorithm that it uses in TLS and use that to quickly lookup the bootstrap key and generate the PSK. Servers that choose not to employ this optimization will have to do a runtime check with every bootstrap key it holds against the identity the client provides.</t>
        <t>Test vectors for derivation of an EPSK External Identity from a BSK are given in the appendix.</t>
      </section>
      <section anchor="tls-13-handshake-details"><name>TLS anchor="tls-13-handshake-details">
        <name>TLS 1.3 Handshake Details</name>
        <t>The client includes the "tls_cert_with_extern_psk" extension in the ClientHello, per <xref target="RFC8773"/>. The client identifies the BSK public key by inserting the serialized content of ImportedIdentity into the PskIdentity.identity in the PSK extension, per <xref target="RFC9258"/>. The client <bcp14>MUST</bcp14> also include the <xref target="RFC7250"/> "client_certificate_type" extension per <xref target="RFC7250"/> in the ClientHello and <bcp14>MUST</bcp14> specify type of RawPublicKey.</t>
        <t>Upon receipt of the ClientHello, the server looks up the client's EPSK key in its database using the mechanisms documented in <xref target="RFC9258"/>. If no match is found, the server <bcp14>MUST</bcp14> terminate the TLS handshake with an alert. If the server finds the matching BSK public key, it includes the "tls_cert_with_extern_psk" extension in the ServerHello message, message and the corresponding EPSK identity in the "pre_shared_key" extension. When these extensions have been successfully negotiated, the TLS 1.3 key schedule <bcp14>MUST</bcp14> include both the EPSK in the Early Secret derivation and an (EC)DHE a Diffie-Hellman Ephemeral (DHE) or ECDHE shared secret value in the Handshake Secret derivation.</t>
        <t>After successful negotiation of these extensions, the full TLS 1.3 handshake is performed with the additional caveat that the server <bcp14>MUST</bcp14> send a CertificateRequest message and the client <bcp14>MUST</bcp14> authenticate with a raw public key (its BSK) per <xref target="RFC7250"/>. The BSK is always an elliptic curve EC key pair, therefore pair; therefore, the type of the client's Certificate <bcp14>MUST</bcp14> be ECDSA and <bcp14>MUST</bcp14> contain the client's BSK public key as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE.</t>
        <t>Note that the client <bcp14>MUST NOT</bcp14> share its BSK public key with the server until after the client has completed processing of the ServerHello and verified the TLS key schedule. The PSK proof is completed at this stage, and the server has proven to the client that it knows the BSK public key, and it is therefore safe for the client to send the BSK public key to the server in the Certificate message. If the PSK verification step fails when processing the ServerHello, the client terminates the TLS handshake and the BSK public key <bcp14>MUST NOT</bcp14> be shared with the server.</t>
        <t>When the server processes the client's Certificate, it <bcp14>MUST</bcp14> ensure that it is identical to the BSK public key that it used to generate the EPSK and ImportedIdentity for this handshake.</t>
        <t>When clients are configured to trust the first network which that proves possession of their public key (as in <xref target="duckling"></xref>), target="DUCKLING"/>), they <bcp14>MAY</bcp14> forgo the checking of the server's certificate in the CertificateVerify and rely on the integrity of the bootstrapping method employed to distribute its key in order to validate trust in the authenticated TLS connection.</t>
        <t>The handshake is shown in <xref target="arch-one"/>.</t>

<!--[rfced] Please review the difference between the SVG and ASCII art
     for Figure 1 with regard to the text immediately under
     ClientHello.  In the ASCII, these are +'s while in the SVG a
     single line.  If an update is necessary, please provide updated
     artwork.-->

        <figure title="TLS anchor="arch-one">
          <name>TLS 1.3 TLS-POK Handshake" anchor="arch-one"><artset><artwork Handshake</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="472" viewBox="0 0 472 368" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,80 L 8,128" fill="none" stroke="black"/>
                <path d="M 8,48 L 64,48" fill="none" stroke="black"/>
                <path d="M 408,48 L 464,48" fill="none" stroke="black"/>
                <path d="M 224,128 L 288,128" fill="none" stroke="black"/>
                <path d="M 224,288 L 288,288" fill="none" stroke="black"/>
                <path d="M 224,336 L 288,336" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="296,336 284,330.4 284,341.6" fill="black" transform="rotate(0,288,336)"/>
                <polygon class="arrowhead" points="296,128 284,122.4 284,133.6" fill="black" transform="rotate(0,288,128)"/>
                <polygon class="arrowhead" points="232,288 220,282.4 220,293.6" fill="black" transform="rotate(180,224,288)"/>
                <g class="text">
                  <text x="28" y="36">Client</text>
                  <text x="428" y="36">Server</text>
                  <text x="48" y="68">ClientHello</text>
                  <text x="100" y="84">cert_with_extern_psk</text>
                  <text x="136" y="100">client_cert_type=RawPublicKey</text>
                  <text x="56" y="116">key_share</text>
                  <text x="76" y="132">pre_shared_key</text>
                  <text x="424" y="148">ServerHello</text>
                  <text x="296" y="164">+</text>
                  <text x="388" y="164">cert_with_extern_psk</text>
                  <text x="224" y="180">+</text>
                  <text x="352" y="180">client_cert_type=RawPublicKey</text>
                  <text x="384" y="196">+</text>
                  <text x="432" y="196">key_share</text>
                  <text x="344" y="212">+</text>
                  <text x="412" y="212">pre_shared_key</text>
                  <text x="384" y="228">{EncryptedExtensions}</text>
                  <text x="388" y="244">{CertificateRequest}</text>
                  <text x="416" y="260">{Certificate}</text>
                  <text x="392" y="276">{CertificateVerify}</text>
                  <text x="428" y="292">{Finished}</text>
                  <text x="56" y="308">{Certificate}</text>
                  <text x="80" y="324">{CertificateVerify}</text>
                  <text x="44" y="340">{Finished}</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
         Client                                            Server
         --------                                          --------
         ClientHello
         + cert_with_extern_psk
         + client_cert_type=RawPublicKey
         + key_share
         + pre_shared_key           -------->
                                                        ServerHello
                                             + cert_with_extern_psk
                                    + client_cert_type=RawPublicKey
                                                        + key_share
                                                   + pre_shared_key
                                              {EncryptedExtensions}
                                               {CertificateRequest}
                                                      {Certificate}
                                                {CertificateVerify}
                                    <--------            {Finished}
         {Certificate}
         {CertificateVerify}
         {Finished}                 -------->
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>
      </section>
    </section>
    <section anchor="using-tls-bootstrapping-in-eap"><name>Using anchor="using-tls-bootstrapping-in-eap">
      <name>Using TLS Bootstrapping in EAP</name>
      <t>Upon "link up", an Authenticator on an 802.1X-protected port will issue an EAP Identity request to the newly connected peer. For unprovisioned devices that desire to take advantage of TLS-POK, there is no initial realm in which to construct an NAI (see <xref target="RFC7542"/>). This document uses the NAI mechanisms defined in <xref target="I-D.ietf-emu-eap-arpa"/> target="RFC9965"/> and defines the EAP username "tls-pok-dpp" for use with the TEAP realm "teap.eap.arpa". The username "tls-pok-dpp" <bcp14>MUST</bcp14> be included included, yielding an initial identity of "tls-pok-dpp@teap.eap.arpa". This identifier <bcp14>MUST</bcp14> be included in the EAP Identity response in order to indicate to the Authenticator that TEAP is the desired EAP method. <xref target="I-D.ietf-emu-eap-arpa"/> target="RFC9965"/> recommends how the device should behave if the Authenticator does not support TEAP or TLS-POK.</t>

<figure><artset><artwork

<!--[rfced] Please review the title we added for Figure 2 in Section 4
     and let us know if any further updates are necessary.

Current:
Figure 2: EAP Exchange Using TLS-POK

-->
              <figure anchor="fig2">
          <name>EAP Exchange Using TLS-POK</name>
      <artset>
        <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="320" viewBox="0 0 320 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
            <path d="M 8,48 L 64,48" fill="none" stroke="black"/>
            <path d="M 200,48 L 272,48" fill="none" stroke="black"/>
            <g class="text">
              <text x="16" y="36">EAP</text>
              <text x="52" y="36">Peer</text>
              <text x="208" y="36">EAP</text>
              <text x="252" y="36">Server</text>
              <text x="204" y="68">&lt;-</text>
              <text x="268" y="68">EAP-Request/</text>
              <text x="228" y="84">Identity</text>
              <text x="56" y="116">EAP-Response/</text>
              <text x="36" y="132">Identity</text>
              <text x="112" y="148">(tls-pok-dpp@teap.eap.arpa)</text>
              <text x="236" y="148">-&gt;</text>
              <text x="204" y="180">&lt;-</text>
              <text x="268" y="180">EAP-Request/</text>
              <text x="248" y="196">EAP-Type=TEAP</text>
              <text x="204" y="212">(TLS</text>
              <text x="252" y="212">Start)</text>
              <text x="56" y="244">EAP-Response/</text>
              <text x="56" y="260">EAP-Type=TEAP</text>
              <text x="20" y="276">(TLS</text>
              <text x="92" y="276">client_hello</text>
              <text x="164" y="276">with</text>
              <text x="108" y="292">tls_cert_with_extern_psk</text>
              <text x="24" y="308">and</text>
              <text x="104" y="308">pre_shared_key)</text>
              <text x="180" y="308">-&gt;</text>
              <text x="160" y="340">.</text>
              <text x="160" y="356">.</text>
              <text x="160" y="372">.</text>
            </g>
          </svg>
</artwork><artwork
        </artwork>
        <artwork type="ascii-art"><![CDATA[
    EAP Peer                EAP Server
    --------                ----------
                            <- EAP-Request/
                            Identity

    EAP-Response/
    Identity
    (tls-pok-dpp@teap.eap.arpa) ->

                            <- EAP-Request/
                            EAP-Type=TEAP
                           (TLS Start)

    EAP-Response/
    EAP-Type=TEAP
    (TLS client_hello with
     tls_cert_with_extern_psk
     and pre_shared_key) ->

                       .
                       .
                       .
]]></artwork></artset></figure>
]]></artwork>
      </artset>
	      </figure>
      <t>Both client and server have derived the EPSK and associated  ImportedIdentity <xref target="RFC9258"/> ImportedIdentity from the BSK public key as described in <xref target="external-psk-derivation"/>. When the client starts the TLS exchange in the EAP transaction, it includes the ImportedIdentity structure in the pre_shared_key extension in the ClientHello. When the server receives the ClientHello, it extracts the ImportedIdentity and looks up the EPSK and BSK public key. As previously mentioned in <xref target="bootstrap-key"/>, the exact mechanism by which the server has gained knowledge of or been provisioned with the BSK public key is outside the scope of this document.</t>
      <t>The server continues with the TLS handshake and uses the EPSK to prove that it knows the BSK public key. When the client replies with its Certificate, CertificateVerify CertificateVerify, and Finished messages, the server <bcp14>MUST</bcp14> ensure that the public key in the Certificate message matches the BSK public key.</t>
      <t>Once the TLS handshake completes, the client and server have established mutual trust. The server can then proceed to provision a credential onto the client using, for example, the mechanisms outlined in <xref target="RFC7170"/>.</t> target="RFC9930"/>.</t>
      <t>The client can then use this provisioned credential for subsequent EAP authentication. The BSK is only used during bootstrap, bootstrap and is not used for any subsequent EAP authentication.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<!--[rfced] We note that this document and the registry at https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-provisioning-ids both use hyphenated "Method-Type".  However, see the use of "Method Type" at https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4.

Should these be made uniform here and at the IANA registry?

Note that draft-ietf-emu-eap-arpa-10 now uses "Method Types" to match the "Method Types" registry.

-->
      <t>This document adds the following entry to the "EAP Provisioning Identifiers" registry in the "Extensible Authentication Protocol (EAP) Registry" registry group.</t>

<t>NAI: tls-pok-dpp@teap.eap.arpa
Method Type: TEAP
Reference: THIS DOCUMENT</t>

      <dl spacing="normal" newline="false">
	<dt>NAI:</dt><dd>tls-pok-dpp@teap.eap.arpa</dd>
	<dt>Method-Type:</dt><dd>TEAP</dd>
	<dt>Reference:</dt><dd>RFC 9966</dd>
      </dl>
    </section>
    <section anchor="implementation-considerations"><name>Implementation anchor="implementation-considerations">
      <name>Implementation Considerations</name>
      <t>Three key points are documented above, above and are repeated here.</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The subjectPublicKey contained in the ASN.1 SEQUENCE SubjectPublicKeyInfo <bcp14>MUST</bcp14> be the compressed format of the public key.</t>
        </li>
        <li>
          <t>When deriving the External PSK EPSK from the BSK, zero byte zero-byte padding <bcp14>MUST NOT</bcp14> be added to the DER-encoded representation of the BSK public key.</t>
        </li>
        <li>
          <t>SHA-256 <bcp14>MUST</bcp14> be used when using following <xref target="RFC5869"/> to derive the External PSK EPSK from the BSK.</t>
        </li>
        <li>
          <t>The BSK public key <bcp14>MUST NOT</bcp14> be freely available on the network.</t>
</list></t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Bootstrap and trust establishment by the TLS server is are based on proof of knowledge of the client's bootstrap public key, a non-public datum. The TLS server obtains proof that the client knows its bootstrap public key and, in addition, and also possesses its corresponding private key.</t>
      <t>Trust on the part of the client is based on successful completion of the TLS 1.3 handshake using the EPSK derived from the BSK. This proves to the client that the server knows its BSK public key. In addition, the client assumes that knowledge of its BSK public key is not widely disseminated and therefore disseminated; therefore, any server that proves knowledge of its BSK public key is the appropriate server from which to receive provisioning, for instance via <xref target="RFC7170"/>. target="RFC9930"/>. <xref target="duckling"></xref> target="DUCKLING"/> describes a security model for this type of "imprinting".</t>
      <t>An attack on the bootstrapping method method, which substitutes the public key of a rogue device for the public key of an honest device device, can result in the TLS server on-boarding onboarding and trusting the rogue device.</t>
      <t>If an adversary has knowledge of the bootstrap public key, the adversary may be able to make the client bootstrap against the adversary's network. For example, if an adversary intercepts and scans QR labels on clients, and the adversary can force the client to connect to its server, then the adversary can complete the TLS-POK handshake with the client and the client will connect to the adversary's server. Since physical possession implies ownership, there is nothing to prevent a stolen device from being on-boarded.</t> onboarded.</t>
      <t>The BSK keypair key pair used for ECDSA <bcp14>MUST</bcp14> be generated and validated according to section Section 6.2 of <xref target="NIST.FIPS.186-5"/>.</t>
      <t>Manufacturers <bcp14>SHOULD</bcp14> use a unique BSK for every single device they manufacture. If multiple devices share the same BSK, then network operators cannot differentiate between these devices, devices and cannot ensure that only specific authorized devices are allowed connect to their networks.</t>
    </section>
  </middle>
  <back>
    <references title='References' anchor="sec-combined-references">
      <name>References</name>
      <references title='Normative References' anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="NIST.FIPS.186-5" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf">
          <front>
            <title>Digital Signature Standard (DSS)</title>
    <author fullname="Dustin Moody" surname="Moody">
      <organization>Information Technology Laboratory</organization>
    </author>
            <author>
      <organization>National
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
      <address>
        <postal>
          <country>US</country>
          <city>Gaithersburg</city>
        </postal>
      </address>
            </author>
            <date month="February" year="2023"/>
          </front>
          <seriesInfo name="NIST Federal Information Processing Standards Publications" FIPS" value="186-5"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8773.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9258.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>

<!-- [RFC9965]
draft-ietf-emu-eap-arpa-10
companion doc RFC9965
in EDIT as of 12/12/25
-->
        <reference anchor="RFC2119"> anchor="RFC9965" target="https://www.rfc-editor.org/info/rfc9965">
          <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <title>The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/> initials="A." surname="DeKok" fullname="Alan DeKok">
              <organization>InkBridge Networks</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> month='April' year='2026'/>
          </front>
          <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/> value="9965"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/> value="10.17487/RFC9965"/>
        </reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- [rfced] [IEEE802.1X] Please review.  This reference currently
     points to the version of Uppercase vs Lowercase IEEE 802.1X from 2010. This version has
     been superseded. The newest version - IEEE 802.1X:2020 - was
     published in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words 2020. Note that may be used this IEEE Std was also made an
     international standard - IEEE/ISO/IEC 8802-1X:2021 - in protocol specifications. This document aims 2021.

Should this reference be updated to reduce the ambiguity by clarifying that only UPPERCASE usage one of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> more current versions?
-->
        <reference anchor="RFC5480"> anchor="IEEE802.1X" target="https://ieeexplore.ieee.org/document/5409813">
          <front>
    <title>Elliptic Curve Cryptography Subject Public Key Information</title>
    <author fullname="S. Turner" initials="S." surname="Turner"/>
    <author fullname="D. Brown" initials="D." surname="Brown"/>
    <author fullname="K. Yiu" initials="K." surname="Yiu"/>
    <author fullname="R. Housley" initials="R." surname="Housley"/>
    <author fullname="T. Polk" initials="T." surname="Polk"/>
    <date month="March" year="2009"/>
    <abstract>
      <t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers
            <title>IEEE Standard for the Internet X.509 Public Key Infrastructure Certificate Local and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</t>
    </abstract> metropolitan area networks--Port-Based Network Access Control</title>
            <author initials="" surname="IEEE" fullname="IEEE">
              <organization>IEEE</organization>
            </author>
            <date year="2010"/>
          </front>
          <seriesInfo name="RFC" value="5480"/> name="IEEE Std" value="802.1X-2010"/>
          <seriesInfo name="DOI" value="10.17487/RFC5480"/> value="10.1109/IEEESTD.2010.5409813"/>
        </reference>

<!-- Possible XML update for [IEEE802.1X]
(2020 IEEE version)
(note '/' in the title for double hyphens)
        <reference anchor="RFC8773"> anchor="IEEE802.1X" target="https://ieeexplore.ieee.org/document/5409813">
          <front>
    <title>TLS 1.3 Extension
            <title>IEEE Standard for Certificate-Based Authentication with an External Pre-Shared Key</title> Local and metropolitan area networks-/-Port-Based Network Access Control</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/> initials="" surname="IEEE" fullname="IEEE">
              <organization>IEEE</organization>
            </author>
            <date month="March" year="2020"/>
    <abstract>
      <t>This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).</t>
    </abstract>
          </front>
          <seriesInfo name="RFC" value="8773"/> name="IEEE Std" value="802.1X-2020"/>
          <seriesInfo name="DOI" value="10.17487/RFC8773"/> value="10.1109/IEEESTD.2020.9018454"/>
        </reference>
<reference anchor="RFC9258">
  <front>
    <title>Importing External Pre-Shared Keys (PSKs)
-->

<!-- Possible XML update for TLS 1.3</title>
    <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
    <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
    <date month="July" year="2022"/>
    <abstract>
      <t>This document describes an interface [IEEE802.1X]
     (IEEE/ISO/IEC version)
(note '/' in the title for importing external Pre-Shared Keys (PSKs) into TLS 1.3.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9258"/>
  <seriesInfo name="DOI" value="10.17487/RFC9258"/>
</reference> double hyphens)

        <reference anchor="RFC7250"> anchor="IEEE8802.1x" target="https://ieeexplore.ieee.org/document/9650828">
          <front>
    <title>Using Raw Public Keys in Transport Layer Security (TLS)
          <title>IEEE/ISO/IEC International
Standard-Telecommunications and Datagram Transport Layer Security (DTLS)</title>
    <author fullname="P. Wouters" initials="P." role="editor" surname="Wouters"/>
    <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
    <author fullname="J. Gilmore" initials="J." surname="Gilmore"/>
    <author fullname="S. Weiler" initials="S." surname="Weiler"/>
    <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
    <date month="June" year="2014"/>
    <abstract>
      <t>This document specifies a new certificate type and two TLS extensions exchange between information
technology systems-/-Requirements for exchanging raw public keys in Transport Layer Security (TLS) local and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.</t>
    </abstract> metropolitan area
networks-/-Part 1X:Port-based network access control</title>
            <author>
              <organization>IEEE/ISO/IEC</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="RFC" value="7250"/> name='ISO/IEC/IEEE' value='8802-1X:2021' />
          <seriesInfo name="DOI" value="10.17487/RFC7250"/> name='DOI' value='10.1109/IEEESTD.2021.9650828' />
        </reference>
<reference anchor="RFC5869">
  <front>
    <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
    <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
    <author fullname="P. Eronen" initials="P." surname="Eronen"/>
    <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.
-->

<!-- [rfced] We had the following questions regarding DPP:

a) The key derivation function (KDF) is intended [DPP] reference: Please review. We were unable to support find 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>
  <seriesInfo name="RFC" value="5869"/>
  <seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>

<reference anchor="I-D.ietf-emu-eap-arpa">
   <front>
      <title>The eap.arpa. domain and EAP provisioning</title>
      <author fullname="Alan DeKok" initials="A." surname="DeKok">
         <organization>InkBridge Networks</organization>
      </author>
      <date day="4" month="September" year="2025"/>
      <abstract>
	 <t>   This document defines
specification from Wi-Fi Alliance with the eap.arpa. domain for use only in Network
   Access Identifiers (NAIs) as a way for Extensible Authentication
   Protocol (EAP) peers to signal to EAP servers title "Device Provisioning
Profile".

We noticed that they wish this document states:

Device on-boarding protocols such as the Device Provisioning Profile
[DPP], also referred to
   obtain limited, and unauthenticated, network access.  EAP peers
   signal which kind of access is required via certain predefined
   identifiers which as Wi-Fi Easy Connect, address this use case
but they have drawbacks.

And the Network Access Identifier (NAI) format of
   RFC 7542.  A table most current version of identifiers Wi-Fi Easy Connect specification
states:

The terms "Device Provisioning Protocol" and meanings is defined, which
   includes entries for RFC 9140.

   This "DPP" found throughout
this document updates RFC5216 and RFC9190 are interchangeable with "Wi-Fi Easy Connect".

May we update this reference to define an
   unauthenticated provisioning method.  Those specifications suggested point to the most current version of
the Wi-Fi Alliance "Wi-Fi Easy Connect" specification?

Current:
   [DPP]      Wi-Fi Alliance, "Device Provisioning Profile", 2020.

Perhaps:
   [DPP]  Wi-Fi Alliance, "Wi-Fi Easy Connect(TM) Specification",
              Version 3.0, 2022, <https://www.wi-fi.org/system/files/Wi-
              Fi_Easy_Connect_Specification_v3.0.pdf>.

b) Please note that such a method has possible, but they did not define we see both of the following expansions for the
DPP abbreviation:

Device Provisioning Protocol

Device Provisioning Profile

Please let us know how it would
   be done.  This document also updates RFC9140 to deprecate &quot;eap-
   noob.arpa&quot;, and replace it with &quot;@noob.eap.arpa&quot;

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-arpa-10"/>

</reference>

    </references>

    <references title='Informative References' anchor="sec-informative-references"> update for uniformity.-->
        <reference anchor="IEEE802.1X" > anchor="DPP">
          <front>
    <title>Port-Based Network Access Control</title>
    <author initials="" surname="IEEE" fullname="IEEE">
      <organization>IEEE</organization>
            <title>Device Provisioning Profile</title>
            <author>
              <organization>Wi-Fi Alliance</organization>
            </author>
            <date year="2010"/> year="2020"/>
          </front>
        </reference>

<!-- Possible update to [DPP]
        <reference anchor="DPP" > anchor="DPP-upd" target="https://www.wi-fi.org/system/files/Wi-Fi_Easy_Connect_Specification_v3.0.pdf">
          <front>
    <title>Device Provisioning Profile</title>
    <author >
            <title>Wi-Fi Easy Connect(TM) Specification</title>
            <author>
              <organization>Wi-Fi Alliance</organization>
            </author>
            <date year="2020"/> year="2022"/>
          </front>
          <refcontent>Version 3.0</refcontent>
        </reference>
-->
        <reference anchor="duckling" anchor="DUCKLING" target="https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf">
          <front>
            <title>The Resurrecting Duckling: Security Issues for Ad-Hoc Wireless Networks</title>
            <author initials="F." surname="Stajano" fullname="Frank Stajano">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R." surname="Anderson" fullname="Ross Anderson">
      <organization></organization>
              <organization/>
            </author>
            <date year="1999"/>
          </front>
          <refcontent>Security Protocols, 7th International Workshop Proceedings, Lecture Notes in Computer Science, vol. 1796,
pp. 172-182</refcontent>
          <seriesInfo name="DOI" value="10.1007/10720107_24"/>
        </reference>
        <reference anchor="sha2" target="https://doi.org/10.6028/NIST.FIPS.180-4"> anchor="SHA2" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
    <title>FIPS 180-4 Secure
            <title>Secure Hash Standard (SHS)</title>
    <author >
      <organization>National Standard</title>
            <author>
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
            </author>
            <date year="2015" month="August"/>
  </front>
</reference>

<reference anchor="RFC3748">
  <front>
    <title>Extensible Authentication Protocol (EAP)</title>
    <author fullname="B. Aboba" initials="B." surname="Aboba"/>
    <author fullname="L. Blunk" initials="L." surname="Blunk"/>
    <author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/>
    <author fullname="J. Carlson" initials="J." surname="Carlson"/>
    <author fullname="H. Levkowetz" initials="H." role="editor" surname="Levkowetz"/>
    <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>
  <seriesInfo name="RFC" value="3748"/>
  <seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference>
<reference anchor="RFC7030">
  <front>
    <title>Enrollment over Secure Transport</title>
    <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
    <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
    <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
    <date month="October" year="2013"/>
    <abstract>
      <t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
    </abstract> month="August" year="2015"/>
          </front>
          <seriesInfo name="RFC" value="7030"/> name="NIST FIPS" value="180-4"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/> value="10.6028/NIST.FIPS.180-4"/>
        </reference>
<reference anchor="RFC7170">
  <front>
    <title>Tunnel Extensible Authentication Protocol (TEAP) Version 1</title>
    <author fullname="H. Zhou" initials="H." surname="Zhou"/>
    <author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/>
    <author fullname="J. Salowey" initials="J." surname="Salowey"/>
    <author fullname="S. Hanna" initials="S." surname="Hanna"/>
    <date month="May" year="2014"/>
    <abstract>
      <t>This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>

<!--[rfced] We note that enables secure communication between a peer and a server RFC 7170 has been obsoleted by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used RFC 9930.  We
     have updated to convey authentication-related data between the EAP peer and latter.  Please let us know any
     objections. -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9930.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7542.xml"/>
      </references>
    </references>

<!--[rfced] We see that the EAP server.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7170"/>
  <seriesInfo name="DOI" value="10.17487/RFC7170"/>
</reference>
<reference anchor="RFC7542">
  <front>
    <title>The Network Access Identifier</title>
    <author fullname="A. DeKok" initials="A." surname="DeKok"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>In order to provide inter-domain authentication services, it is necessary to have a standardized method test vectors that domains can use to identify each other's users. This document defines exist in the syntax for appendices
     are not formatted in the Network Access Identifier (NAI), XML as <sourcecode>.  Additionally, as
     they currently exist, the user identifier submitted by portion in <tt> extends beyond the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international 72
     character sets and makes line limit.  We suggest reformatting these as
     <sourcecode> with a number of other corrections type set to RFC 4282.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7542"/>
  <seriesInfo name="DOI" value="10.17487/RFC7542"/>
</reference>

    </references>

</references>

<?line 332?> test-vectors (or maybe base64?).

See https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
for more information on <sourcecode> types.

-->

    <section anchor="test-vectors"><name>Test anchor="test-vectors">
      <name>Test Vectors</name>
      <section anchor="test-vector-1-prime256v1"><name>Test anchor="test-vector-1-prime256v1">
        <name>Test Vector 1: prime256v1</name>
        <t>Base64 encoding of BSK:</t>

<t><spanx style="verb">MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxpEC6KITLb9g=</spanx></t>
        <t><tt>MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxpEC6KITLb9g=</tt></t>
        <t>Base64 encoding of epskid:</t>

<t><spanx style="verb">Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=</spanx></t>
        <t><tt>Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=</tt></t>
      </section>
      <section anchor="test-vector-2-secp384r1"><name>Test anchor="test-vector-2-secp384r1">
        <name>Test Vector 2: secp384r1</name>
        <t>Base64 encoding of BSK:</t>

<t><spanx style="verb">MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZKilryZRDfNioq7+EPquT6l9laRvw</spanx></t>
        <t><tt>MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZKilryZRDfNioq7+EPquT6l9laRvw</tt></t>
        <t>Base64 encoding of epskid:</t>

<t><spanx style="verb">yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=</spanx></t>
        <t><tt>yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=</tt></t>
      </section>
      <section anchor="test-vector-3-secp521r1"><name>Test anchor="test-vector-3-secp521r1">
        <name>Test Vector 3: secp521r1</name>
        <t>Base64 encoding of BSK:</t>

<t><spanx style="verb">MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD</spanx></t>
        <t><tt>MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD</tt></t>
        <t>Base64 encoding of epskid:</t>

<t><spanx style="verb">D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=</spanx></t>
        <t><tt>D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=</tt></t>
      </section>
      <section anchor="test-vector-4-brainpoolp256r1"><name>Test anchor="test-vector-4-brainpoolp256r1">
        <name>Test Vector 4: brainpoolP256r1</name>
        <t>Base64 encoding of BSK:</t>

<t><spanx style="verb">MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/reuCvq8lHowtwWNOZ</spanx></t>
        <t><tt>MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/reuCvq8lHowtwWNOZ</tt></t>
        <t>Base64 encoding of epskid:</t>

<t><spanx style="verb">j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=</spanx></t>
        <t><tt>j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=</tt></t>
      </section>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA8U82XbbRpbv/AqM8hBpLNKi5EVWJ+mmRapFa1+85mQ8IFAk
YYEAjQJE0zrOt8y3zJfNXaoKVQAoyzndZ3SykCBw69bdt0K73W618iiPxZ63
9jJNc5ln/nwuQu/6+MrrFflUJHkU+HmUJt4iyqfeeZamYw/+OUrSRSzCifDW
4d72+dnRxlrLH40ycbvnqSutMA0SfwbAw8wf5+1I5OO2mBXtkbVUO49lu9tt
wSpikmbLPU/mYSuaZ3tenhUy397aerG13WrJ3E/Cj36cJgBvKWRrHu15v+dp
sOnJNMszMZbwaTnDD3+0Wj4gn2Z7La/d8uAvSuSed9bxDrJIxHSFETtbiMS6
mGaTPW8/kkFKX8XMj+I92C7e8I8Ar3eCdOYA7Xe8Qz+7gc8W2L6fOFcJ7qEA
iuV5+9wPbvws9AZJLrJ5FklhLxb6CSzWmfLT/5jOBS3ZStJsBoy4BegtuP90
eHXdORieX3W6u8/aT/cIhNm0ZxY9Jeb5sTdMJHC6yAVy7wqJCThID/7vXYtg
mqRxOlnSk0ogELhHwL1+NIlygHEVTRI/LzJhAHjr/aurDX7MzyYi3/OmeT6X
e48fh2nUARQed7c6z7a2dx9XMKZnQmD6HgjaBBjtbW9t77RaUTI2O8WNDgeD
we7Wdqf7rmmPxAK8RX1n8lsXiAj43bP3dg4S037pS5D0U5Ev0uzG6wWBkNLb
T5M8S2MLu+2t7hYi0j8/X0nlt1H7IPJ6cRz5SSDslfriNgoE6s1tJIETUTLB
L+MoFs4a27RGWAQ3MdzStFBb/V9t+qCDTPjkJ6m5zps/yPzkpvJb5dnLjtdL
QpHJNKk8fJkCDcxv9kbWrqfCuxSyyDIR5LiNvkbWuxJBkUX50htKWQjpAQe9
Xtg+TAOgTCZiJKyis1xrFJbFYtEJ4k7gzzp+0CluHv85nsnt54/n/hxQedx9
8eJFW20JsGtrOnXm4dgiI96GSMupv/3v04it9hPesQAdl1NLF64O/4IuALgm
Xeg+bbXa7bbnj9BSBnmrdT2NpAcmtZiBVfZCMY4SoLXvzQBZMBpy5uVTP/dE
4o9i+qE0s8iukCUxTz0BtnQUR4A6WVja8azICz+Ol0QxZfWF5098EBi4gxyC
FNmtyDreywa40pv6t/CANy8AdPAY7NotQrgRS2/uR9kmrZLjFkp8S1RL8Ijg
HLSFMAVUDN64tyj3bsDxSPqBV8IVNHBhbdKBYYOvwylR7Xgo5SWCsYBH/Amg
KL5EkqW+WaHBEaUxWMPz8w2WIFzRkakAfMJIeAUanSiBS97gSy4SGQEJqr62
BDjoAUDxBRECX0s+GJ/snWtusJTMojAEi9Jq/QRiDQYMFAQBtVpnCXhbwMHm
FEFJ0k3QBy+OZlEuwk3EKwO8wCWNfdifwjaMxuMoKOK843lX6Uzk0Yz4FWQi
RHxBjYCjiYBvIRLbZysKD/9eGu4/HgO+7RGZ24TNAHNMffGCNEnQqNyiDXHg
paPcR2JZC3ZYEeapZEymILYCiYNWJ61vFyg0HMONSjSmvjRS6j22mW+JKakF
rIvigTSZkHVLSzA/S0v8NLEYWcPetMjb6Rj2DRDHYCiAH5slHuoZW91CWnyu
JQu+M7+BN6gnNtFxr/dTWLEC+PZ2Cs6GVc93xUzhALqcJpNNS4F+rt0Ke8ef
NXCAJUEcFqhMC+HfoFnwftdm+Q/YhJDwNJJ6XCSBsrhS+4lZGoqY5CUMMxQY
xg7CNxCxbAksU2pm83OulAKWLgIgC2vvPQ7W+x3U8Q+geSxTD+JCAa6LpVQq
jz2AJdHlo/RtusiAPgB94D+jIseFlmzgIJJdjCCAA8ISdOIE2kh0/GCdQSaT
NAcM53OIMYCBWY0lLGPlrXMRRGMAny5cDgB4LZY140H2BWxCCK7uRgDtq85B
Blk0EqSJ+I/LzIrHcGQS9w0kerg/UNsxK/I+EKy7qGZfkyEEc2ZsXFW0G2nY
4Q0bmPA5QDvAhrchSwGgKivp1Dyp5kTJf3QKKajcDIEsdAijUQgxEYCdg99Z
TEUmVrnaUOQgV+DwwH5G85itKdyf5DWYUtlDEZJHTwEoIKCds4S9kQVwGJd4
Mpoh2CwtICaC+9FipbRsNgNDRBsJUgrYDPIo/nnugwLlaYdkTG1bKMGPMIYj
LrCOoPzDbSCQZt+AfhwTyQhkigLJXGKeeQJWzmBFD5Vgk0Ao6tOj5GZBIWGb
m+aHq8Oz18d97/Ts2kgHIuFSVgtgjX4shQrGw543MoUu4qefIOhDqnHU18I4
AE07/A4sWTt5fXW9tsn/RxTx8+Xg4vXwctDHz1eHveNj86Gl7mB0yk/lk/tn
JyeD0z4/jFt2LrXWTnrv13hLa2fn18Oz097xGjskW3L9jHR1xE4KcklBTkS2
tDaSgr3cP//f/+k+8e7u/uPyYH+7233x7Zv6stt9/gS+gBQnvFqagMrzV7R5
LUzR/YzUNEbNnWMeiMQGIwyKnnjIRyDff/6OlPljz/tlFMy7T35TF3DDzkVN
M+ci0ax+pfYwE7HhUsMyhprO9QqlXXx7753vmu7WxV/+HqNatbu7f/+txTIy
TuM4XaBo5aX4eOw/MCQF3ZxMU3IhFucwalO6orLT72ek8MTLq6O9Mvr2jlA+
pxGockSGXkD+OQd764GXvRWrInFvnKUziqiW8zyVS5mDmZNFlJOFQZWBbAX2
M9jvX/VwVUx87w97yRPirWDI97yHxLV3d38H8dt5/mT32zd6cB+f0/jvI/58
GXDYq/zQUI7oxZMUAovpjB46RzIhEhkGHeeZaF9NfdR3IBjdcHUNvydA1JjU
CG2azuiuIXuW5LoZxedbO1uM4mlvuFflzZDisXEkMryD1q0vd01UuS4gyogf
Rhtct/uc1gW75KZbZ4DsbSQWrVav2etM0zhsDHEr4rE+2N8ohYLlyDUvFDJJ
FTD5FcFbB2Hc4HzJljAVJ8KPKJSYZCVsVEZLK7pRz5URdNNjzhObtevwEdgG
4oobxk9j53a0ZhwhmGg6TarJoAJlXUnnkPDlKYSzQ0A8CzkhfXDGvFmFR2mo
fGguO/dB8Epa1PJaF9qDstoKyI53gsEFxAh+BJG0IgnSHZ3JJLoVCVr7uzsj
W23gz7dvHTZ31pJBWsQhpTB2PloP36rBb6ofxTvFF59CGAXmezq5Dqq74Wim
KUoMeScUsmOi5iqXCVxtXJlZFu7KmxiZsUmvUjErB9M0L6QqecliJMXnAtFH
oC4KHGPgddeGtFplHRjWmsfpckaZU76cRwEJWAZAo0zck1VXdlsmztWo+dzk
UHF0I/4Swe3wHVWDQLi1Bd/bFxnaRYVPj6pwmPihLUGHiZSd0Tc7vSgk2jHe
Hu5ORflAc/iVbJqKyuuBnVlfBeSBQUBYFQV8rs4a0jIVuboEW1WMKIGbVBWX
TiWr0l8pDdRyfyV+lngiLDBPWB/nDExx306fNt2E9OFeZ/2aSk2K1eR92Pw4
HNJmx2RrzDK8vCrHlKpUGVbsCrKtHSXc/9kBC8PMbqwJ4c4Rui14hhKJkkES
Y5MRrusiAdEUOQjG3t7dxor60gNU2RJvAYo0FsEywOzMT/yJIDRm/pLLDoCw
QpQJYAFGgoM/AVXzqUAiO2wjrrh2oBh7ArlUGsrV5V9XDyqpPSR2kHxKryq2
gJcqqdjy5jsOylb0B9DESumUlZ0R6roWouVkboeQVFKz8bKxgP0q0xdywECB
hAWZ0cSORJLDL2oh+WNLIBvIEzD21RQLsuEZpca+4ljE/pVwkQ6rGKsOWlFS
gbs70g6S8JrYC38OxtQtm+hUWKcPZEwZvygJ4kKVNYHzlMuWUfvKsNRbh7B1
g0ug44Ji5RJTST5fa6fFJptaNi03WQk1muzG52nOioNBnrAQz8keqqU6kEEo
vLlABHtc0PO6nohJEvBKBhCCccDiJkw/uQEoxyOluFPiUi8aWranGtzGkaAA
qJ45UWhsOEZ23IS7AANNPGW3sN0fSaY6XjVkDwAHUuayNJ2gyKVBRPXgwT7H
bNcqRkOzQgVbH5FF6zzyb2h3VPchKOMomy2QsT6aoaQYg3UpMtK+aCYo/lJg
wmXizxSciUgw8MVYIncIiA81Be8VP6fpIZIgDakIwdXZwSVQWlWDTSUZNtm7
Ou10vavBxevB6f4AbN7oE2jNOQEE7g6Tccq05ULF0ye7W+wiBNoh516zNpe7
ZnOqZpHNmvkm9i1x7Xinaa5sXF7fCe0Ad05gWe8YNuNsck1Ly9C8hmGkg6+8
AUuIUMdNy+kaPKeMZKcpxwC1yKdL5CCmOSqscqqutEHc3hrikS8rFnnNWyc8
cjFnSnKKh3Ucy5LXi7QBFiE3qoFLx2OFg4A9yC21Gy1N6uhkBxRvUzqi6q+N
m1+l9lwTV0hx/XCeSg5grMBCM0cCssokXlx6KICOb8co6dmTkrEKl2bZLBnd
KJOgPQXE6H5oXMtLrIXCpxPQngzMoARbcXayoSszjKKurerhBnSYlIhZV9AW
AfoGTbjfysf8OJokaLnaKAvwn/Y4avtq4qDNmtm2jTV+wS4Iqo0SPU0czIun
S6nSCy4Hc1BFKmQbJbIXxLmzEyozlcZJGfky5aYoEP3lnLYTyZU6ZofDRJhq
EEPufSTiNJlIFy+V6WEfGZtIm2YnJCGg+RYftZOHFBNtfSwmoKIzigGweABx
99y9tZ7loqmkxo8jyqai7+5LcrUdUqeEbWdq1f45S+CY2nSTcSVLoNFs655z
aLfz2aSYBnnEpmeJMYBSFctf2dalio/1gNnya2nFZhRAaK+JQVHEtWAtFt8t
QaAXq7OiUiOKcsme7VxH50ZUStsCwlHaFl2f0ZLTbE0s04kWErwBqIwsMmpe
zdIiyZ3igOrqIiyOlMkpq8yjbJCWRvC6xITCe02NWvmFqfWzrOJIG4Jwbuyo
mu5ATQBRCB7SQoJeii/Y4yZS2aMOlfzbWDlQhwhiG9yP6vkkVG8xhFWLYUKt
dsgiYXeJ1N7WpRBWO3eDE5OeNkGs+u7Q072TTqRVHLjadrZCGzJxqoRAJWWO
tzbtStGmGRqxDZpy9b6Ta3J/lvsjmTBpjG4DOgmLk/iYPGKUAibcKjrunZLm
8qbxWykmknii5l9Ql+ISM5D7JOfsChkZ+yO0WRgXcvBFFjiM5Dz2l/WnOVXh
X8tioBuZVtM0bOlFjv0z90urgcsbMeMYJWEe8rDTPoOEJ5pFsZ/FRucA70Zz
pPhkSodgmTl9ogDWZyfDH22rgo1uZLku8ljyS2Uri08lj6zmnp4DYPqpPE9t
d7PetMfdF1xGvLzqIWlAEfP258JPclAwjvU9DvYBqcKMGcnoKz1lyzSWoYHx
RaKzgoRazEoqVfShIz/Fd3LYLL7s5zDKDPVAisrjEAWF8D3obeqZq1nKXVsU
lXlIDhyxzvzgRsPBGK+XLJudsVYsoB1JC8nbCDhu8MTQGwIZ9FacuJp+e7WH
EVEO6XU7O63Wql+s2SvVq3z+fAcyZqv0ovplTXPKarqqoQHENrz8EUzQOnaM
NnALIURwt7hJjJebLJT0nNbq3Z1QgNpzedOmxwkLXTyjCt45dzWMsHPNjHf1
YvvpLuxqONO59wq0IaoEMBCXKxOGJIJ8Uq7wg381w1JzWTgMAXIG4nJ+NLRJ
7oQCM2yFKAku2whYk8r8xf1kwxWfbz/FejIuiNpGKXLFhMONlbFheAApUKut
67ANaW3mYih+lpXohXyPcolW+FK6bpeaTrGvudyeOs5c2wIGW9ZHEWyJT9ke
svFRICq4uPOJmB7BunIcCTOqwtMuZVCrymbcSIAMKy4JGlnjgdTWwa6ErQ19
I8RoDbgbqaRUS/LMD9GK6I3nBQa48GUdFRKldbMEyVlyDpdwWFZ1DPV9upgG
qVhbVw5YbqvpM4lrc7ZW5dcHkYF1XVLvKywzeTVYApfKVMde90HAWdBqm2u0
HT8K3NgFrFE/3X2GYxomx7o67LW3nz7D6BpzeFWC8HBSYvsP1BoeRJB7rdaf
f/7p+b68nbQEGKUo9H71Do/6B+3Blzkoxrr6TEPF67/8tmmYsbFphsErf2t5
LLs77ZFEIxepPa9tescbLeq34Hx121OrKZaSrNQIRTf+Ne4Tcg+hI61x7IEK
YDK+s802C2dEc8zHvTTIBarF2CEsaMm8yOnZX34jE+qdvj4+Bl2Lc2vKAocl
Vep/7H0FSZNI71ZLg9G1KC6DYrWU5AIfUfSpc1lJVYNDEKGRMFi3CMjxR6WJ
9F1+8z3eHZIqnfufC6zXMAc+arb90u10Otv/1X3W7v72N+tGiKlyuPmXLffX
AuxF95kaaP+ouysNP92E47+16nj/jcmjuvHcyQstq1jOz9z6cSEq8ltFHkSZ
qdhS6MIFI5w3a60KmvArWHjwlOtbX7Z2tp5stEpk4bdfMFMFI6yo/hujiqyo
UV8vR0gaJltLK8vM5RzHxNcTW1PfaqpLcx1biYxRJC4aiKAwbRRnANQROxXh
6Mdqe8Eigx6+rEPyK9jZUtnxTnQ5owaV2adLyybWUSR2ZFuq7Pppp8u4WlxR
Zsx9gNqQVnJIrjKag+mhWruoWEVQ0/AWnXZlkxhVlhsdQX4ghNPj1xGbGa3v
2a3XYJpiPo71WfB/6XhsQKgOH6XBNK+Zpxi5YnEUzBXGxSXfjCiDBRE0TGmf
huMaAe6Rf6uYe2fkQMXKOn5iOUs98PyQti+9OE1vwEfXE0a73E8/n2Mh5oo2
qkoZaqsYB2KLf4ZTCSyn6TyHZO+rDrUhQqS8F9sPmLVlRUINg2AqIK+wNuKi
gGUiHlNSKaVDmUq1Ca5jEnct4L5bEJ00k6WW2D2FZpejWzS1GRcqVwLRkzD6
oiZAlZAcGiHp85wMWwVdQClLumwCPmK/7CNu9iNbrI9go9bI9CZUA1OL7dPz
hwIkfNPSCk5sWBP0Erq10Bjfg1gB0UTZUpVUeIbkM2RDxVWumopSZk0Mlzf6
Yicqf9XCUGK+WVNeB02yOlQHs9skTnS/xrd+tFqKH/PlXNxPHpJRgq6n4/EZ
Ssj9RdlSabVez+F5UDERzU2nxyGzZYhRIaSnVMLU50hoSCa5QgOpsY9RvuWj
7FEGZaabbCPk7EkKBjDnUGGMU9kOArQhHhO1ZylKk6RTVz8WmI2rqr0erIrg
NsYHl0DkXLnYRLX6y8LJ+s/Unwkp/YkoU1i3jMxpQEVu1sDSfeQu1kdAxlqh
472dsp2VoryqDoyN0H7KgvrWmHAuvURM0pw6DOUwHSol8khin6KIhdubo/JP
mWmruRmsR2ErPhO5bSrIlyTU4u0fDnTfTfJ97N4VhNIK1KBQpWSck//RqBvE
y8DU2e+mKt6Ayaw7o0haYyLGx+meoo+j17eC4ggVTNgiBfFw6MxciUvs7slc
M7Lko6239lyP6i9W8vZ1VabfsMwA63XZA8agOF74y6YJ5PLwX26NVwijzI4i
2jM1OpxRNQFtDNC4+Yo7qwrsVH94YD6piyNgSNyWsE0nzBtJSnTTwinna1bp
dB8IGns+iYYFCHsiGAbENKCvuixWK9JWPtwtfOEATCuALfxM+3OqDGDmH9mw
fTVpLnNHgRV6UzUPJZJKs6/ewKjaFi5kqpRN8VL6Yx5ycMsfJI8NfsutjGir
b7FdiauxfLhHJoWqtHAzmyZXKbeyKFkho1OoMjZXNgW8zcjaNQNlJCrMBqnR
hs0q5wT6KE2zaJORJtjUlypngTF5CFkfY02pKv3K6I8qGE4QtzreZwZF0j4v
plBnDLnvCMo1jiZFpgvDhQrLxlEmy+NDnAmrtletzRdljvnwKUi1+kh8qsQ7
6b1HrCZKBDFWtJSBaQlkc2Y4a9LyBgWDo9lMgKlPG45rOsGvXc3mkJa3GkaY
04/wIDhquIoFzOw3+IQoJCrbp0Ldc5soUWU/SM9KOOadj8twKz8Lpu00EZT5
l9luWX3hCGZFMabxjyW/hNBWfw+HoJ+oYkHaVF585DXFE87vZcBHkd6vdshm
3wiE5oDBvuhGEQ34/baqSPXdP8s6/BiM7+35/kcfRo4f/Guk3o887tL5B2Hc
DRLqMolwYMKbbz+Kx109XvlhGA2gfhzGXc2oPAzGL01KdncQQaYAjtqCsQK9
e9ct4dTWLTUB61V3e95P2qDwiyp+XdPxpe7omkh2DU8UeTzvgTfVmm+D3rlK
qtbAYt9AtkTHEO0eG52yx2s8MY9jRnjMFeMaPvEcx+oMqRoDNo4oU1Gp8m6J
WMRLbTbxcYHnOA6wt5jYg8m660vuD1KbiJufOTnv8NZPMNRBa286uhSh0Ow+
ZqYRTXVnwo/tkZIUV1YFU0D0tDfkqQc1Iv70yfa3b3rg0xTnCu3a8fZVE+7/
MWz3O+ZdR8Kft/1s7qsylp7bJpcNxMHXLuCrVyhXa8/Tm3Y4n6+Rz8aijgk5
aPSY97CWA8wO/otw1zgcXAFHB9IqVQq9ZSRiSuL8xJDGLknZj/+jvpCJUmjs
sQY9Ks8sWFzHxFEKx6lCLqsOFLAsuPJVG7ZmrrtT1vcQmmpuwLBQVk7Voxfm
0QNKPtWkg7t4bRyAEHHOj5c+G/URfz4H2a3qKV63/PIql9xu111vo7VBgG1l
KR/fe6/ptmj84DFmAj9ndWM8b30lxzc8sDH/MqTwxmt0gEjP++7EF4rhS3Wy
fGPVBuqw6CHla6eUR6Hq8DKrqiD8K5+7sb0h7Zt+W4Vm5y/8QM2Fl1iqUFkJ
VYp1XoavllANRCeat+Yt7+8P/QtGFspCjUZRIhfKpMmc+rH03DrAUi9A3dfF
SlTz2on37isKWugpslHhT3fUnbIfICK4xbkCEaStUxA0FK+2k3uYMoP14KE8
dAPslppOSXLWee+MtJWJT3iS0ZksxYNtgjNb9y0wDazl6WkZqbrrypMT1+Wy
WEGJkkJYjZR6Nmy8HNGkfJfSd2oEdfHJBA/e0lqYWzmJcHMup+MeXQyQ9RKq
nTmTDFkkWVlU4KppY0G9g69JCpoKsrquIp1yQlVxzelgoU8Fc67ojIuaI2xq
xF7TlQ+aOgfQ0sQtzlAlujIFWalLuzMe5SG3jtO5MDhwv6hyPPrHjsBZ9T86
CkVFiZAPmhitMMew0Z+aCUU/WX7/rKw37J328OUHKN8ZXa4dgvNDVRG33sLA
lFsjp2yPopanNeQaCOYEk/6yeP3gV3FdqifXvEmWFnOsHOJ7AVb60Baf3/PQ
W+1RKNG6FPQSmAC/Hw6vvP7Z/uuTwek1bRq5OzPzDe72qayQCVVXTSNdubGa
Ev4INFWd28xowJAb7uo1He3mAzSqrloGcA+ZHfvRUze4+ltnIIJMjD16ZPuw
TZqu+PfN8bS91SMb9oCeGsSh81Xon+/H2tD4nmriGFiIxy5u/Yjf6qMqV3qc
FuXAvFGxJgHlIbjyTWXGAJFW1F9qgAcsaHCNT/jwtFjtbI4pVzaN7uJkb5Im
bXUl9PNixkbAfnkCzaLLe6faorx5AdzOpn2QSr23S9UYBT/pNqLsyTjQDaKF
Iqb92oNy8N1QwWrbKBtvyUq9PVP2AsklNo2Jlm+kso5H2NV1y4uVlKh60KG9
f9vl2MdQHc41NCWUvV2A3PBwuRRc/g4rI9BkiK0pFYX8A+BTCXQO9wMLkAO6
R1meM8tTHZ5VjpA659NvI9/1V/ZL5Ky3mFVfHWdq2rqVtBbNaNQeHlzr0OAi
HWu60fLQWAVmTNEV8YtAq++V5ANeWTopTAKpux2VmxJINBOsbVhvUuMTJfYA
ilYT63ilUWItYPZq6tWFCc+zSJ8HQuqa26ywxCPzoBrM4cNE2Ka+EbaAlSDs
kQzz+M+ynPY/sOOQqIIfvYgqEPNc6jeXgT24uOSDD3TcVvUcyt5U+TBSDQgc
OJhxpQZrRFQ4AMDW2zuSBgg6aNNkpxJYpcleieasr1S/shaskkG/b+QqQvlt
Onymj5uZcVynIJVPVZiCSQWtj+NCMflFljDUIT6erwWlPH75kocV6JU9Jp7i
Lql2Y9ZJXuwkqu5FiG+0SDN9DEyPYD3rbKMQNc1Zg/CdmOPDOBmk3o5S0AxU
kUQ4NYj4UFxKQz7q9Io5SyOW1glkbutVz8Op1ioZRyxfkecnxuqOk34jD52y
Qbtm3qIX8YsMzBiXrJyyU/fb6QKf2tcn4PjtwDQ3o9Ghg9MYTPIsjSUFQHHr
SAkWcvA9kOisaTLpDU8mqTfJmQtedw/d1ExApHHbBfddP4uKb/Vqtf4b/k76
N4vB4v3hUfph+PXT1n7v4v1Qfe73LoL+cNLbP7k9XqZny5tPu/Lg1Zer9MP4
qz8u3gxuTx7dnL7f/zIf7D87Gl4fj15MfkWYjUvyEKVa9WX4KD6OJ48Hl2H+
3g/GX/vjaff4U3i89eji7auLw/D9u/Tq+av+1U1PQaxscXsP5Wm+s/sk63rf
2+Lg/WLQc7Z4cPRkMOjtD/snsL1F/93RRXe+zIPL7tvR+PO5f/pP/93F1uWr
JPr06p9dMdv9cBTF2fLDZX98GqWfnz8anH8urp/FL2L/8nbxsC0vT94ebT8T
wc5N/OZALCbbX5OjJL+YvEkvg8vLT293u8mz58//efxod9G85R3e8tPtbvZd
ph5MVuz4pH/Z6/V7w+hw2Dt7F56/KYa7N9P9BGh+3f30dCe7uEwO9oP3O/sf
Xt9+Cd8dvbp8cfT26eWblzuH/Yvx7Ca9eHs4+PrkXTJ591ocLPvv4miQ7oiD
Z7fTz/3/r3UfxoH+I7kz+LLb7e2e7jwb7A93euG7xcuv2dm7Ik0+vD4Jp9PD
d2+Gp9PJbjMHnux5oww81TxN43NQru/zoZ8uDlx6vDpaXvR7i+GwdzE47C2H
vd7OePn67efoze7p/ot+b39399XX2ZvPSXr9OBPF/u3n3fgwXeSLt6dnHx62
z0/b18dvg3d5di0+PRrvfH4++JBN50+vZuc73eKm++Hl9k44Di5f7Azeq33+
H12BeLyVYQAA

    <!--[rfced] We had the following queries related to abbreviation use:

) We have removed expansions after first use and simply used the abbreviation per the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev.

) As the K in BSK stands for "Key", is text like this redundant (more similar instances exist)?

Original:
Devices whose BSK public key can be obtained ...

Same goes for EPSK:
Original:
...the server looks up the client's EPSK key...

Note also that there are some uses of "bootstrap public key".  Please
compare and contrast with "Bootstrap Key public key" (or BSK public
key) to ensure that these are made uniform if necessary.

-->
  </back>

</rfc>