rfc9966xml2.original.xml   rfc9966.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.
0.7) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-emu-bootstrapped-tls-11" category="st <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
d" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> -ietf-emu-bootstrapped-tls-11" number="9966" updates="" obsoletes="" submissionT
<front> ype="IETF" xml:lang="en" category="std" consensus="true" tocInclude="true" sortR
<title abbrev="TLS-POK">Bootstrapped TLS Authentication with Proof of Knowle efs="true" symRefs="true" version="3">
dge (TLS-POK)</title>
<front>
<title abbrev="TLS-POK">Bootstrapped TLS Authentication with Proof of Knowle
dge</title>
<seriesInfo name="RFC" value="9966"/>
<author initials="O." surname="Friel" fullname="Owen Friel"> <author initials="O." surname="Friel" fullname="Owen Friel">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>ofriel@cisco.com</email> <email>ofriel@cisco.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Harkins" fullname="Dan Harkins"> <author initials="D." surname="Harkins" fullname="Dan Harkins">
<organization>Hewlett-Packard Enterprise</organization> <organization>Hewlett-Packard Enterprise</organization>
<address> <address>
<email>daniel.harkins@hpe.com</email> <email>daniel.harkins@hpe.com</email>
</address> </address>
</author> </author>
<date year="2026" month="May"/>
<date year="2025" month="October" day="01"/> <area>SEC</area>
<workgroup>emu</workgroup>
<abstract> <abstract>
<t>This document defines a mechanism that enables a bootstrapping device to esta
<?line 69?> blish trust and mutually authenticate against a TLS server. Bootstrapping device
s have a public/private key pair; this mechanism enables a TLS server to prove t
<t>This document defines a mechanism that enables a bootstrapping device to esta o the device that it knows the public key and enables the device to prove to the
blish trust and mutually authenticate against a TLS server. Bootstrapping device TLS server that it knows the private key. The mechanism leverages existing Devi
s have a public/private key pair, and this mechanism enables a TLS server to pro ce Provisioning Profile (DPP) and TLS standards and can be used in an Extensible
ve to the device that it knows the public key, and the device to prove to the TL Authentication Protocol (EAP) exchange with an EAP server.</t>
S 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 A
uthentication Protocol (EAP) exchange with an EAP server.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 73?>
<?line 73?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>Onboarding devices with no, or limited, user interface can be difficult
. Sometimes a credential is needed to access a network based on <xref target="
<t>On-boarding devices with no, or limited, user interface can be difficult. So IEEE8802.1x"/> or EAP, and network connectivity is needed to obtain a credential
metimes a credential is needed to access an <xref target="IEEE802.1X"></xref>/EA .
P-based network, and network connectivity is needed to obtain a credential. This poses a challenge for onboarding devices.</t>
This poses a challenge for on-boarding devices.</t> <t>If a device has a public/private key pair, and trust in the integrity o
f a device's public key can be obtained in an out-of-band fashion, a device can
<t>If a device has a public / private keypair, and trust in the integrity of a d be authenticated and provisioned with a usable credential for <xref target="IEEE
evice's public key can be obtained in an out-of-band fashion, a device can be au 8802.1x"/> / EAP-based network access. While this authentication can be strong,
thenticated and provisioned with a usable credential for <xref target="IEEE802.1 the device's authentication of the network is somewhat weaker. <xref target="D
X"></xref>/EAP-based network access. While this authentication can be strong, t UCKLING"/> presents a functional security model to address this asymmetry.</t>
he device's authentication of the network is somewhat weaker. <xref target="duc <t>Device onboarding protocols such as the Device Provisioning Profile <xr
kling"></xref> presents a functional security model to address this asymmetry.</ ef target="DPP"/>, also referred to as Wi-Fi Easy Connect, address this use case
t> , but they have drawbacks. For instance, <xref target="DPP"/> does not support w
ired network access and does not specify how the device's DPP key pair can be us
<t>Device on-boarding protocols such as the Device Provisioning Profile <xref ta ed in a TLS handshake. This document describes an authentication mechanism that
rget="DPP"></xref>, also referred to as Wi-Fi Easy Connect, address this use cas a device can use to mutually authenticate against a TLS server and describes ho
e but they have drawbacks. <xref target="DPP"></xref> for instance does not supp w that authentication protocol can be used in an EAP exchange for wired network
ort wired network access, and does not specify how the device's DPP keypair can access as described in <xref target="IEEE8802.1x"/>. This protocol is called "TL
be used in a TLS handshake. This document describes an an authentication mechan S Proof of Knowledge" or "TLS-POK".</t>
ism that a device can use to mutually authenticate against a TLS server, and des <t>This document does not address the problem of wireless network discover
cribes how that authentication protocol can be used in an EAP exchange for <xref y, where a bootstrapping device detects multiple different wireless networks and
target="IEEE802.1X"></xref> wired network access. This protocol is called TLS P needs a more robust and scalable mechanism than simple round-robin to determine
roof of Knowledge or TLS-POK.</t> the correct network to attach to. DPP addresses this issue for Wi-Fi, but DPP's
discovery will not work on a wired <xref target="IEEE8802.1x"/> ethernet port,
<t>This document does not address the problem of wireless network discovery, whe but TLS-POK will. Therefore, TLS-POK <bcp14>SHOULD NOT</bcp14> be used for boots
re a bootstrapping device detects multiple different wireless networks and needs trapping against wireless networks and <bcp14>SHOULD</bcp14> be used for bootstr
a more robust and scalable mechanism than simple round-robin to determine the c apping against wired networks.</t>
orrect network to attach to. DPP addresses this issue for Wi-Fi but DPP's discov <section anchor="terminology">
ery will not work on a wired 802.1X ethernet port, but TLS-POK will. Therefore, <name>Terminology</name>
TLS-POK <bcp14>SHOULD NOT</bcp14> be used for bootstrapping against wireless net <t>
works, and <bcp14>SHOULD</bcp14> be used for bootstrapping against wired network The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
s.</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<section anchor="terminology"><name>Terminology</name> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI be interpreted as
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO when, and only when, they appear in all capitals, as shown here.
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", </t>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>The following terminology is used throughout this document.</t>
<t><list style="symbols">
<t>802.1X: IEEE Port-Based Network Access Control</t>
<t>BSK: Bootstrap Key which is an elliptic curve public/private key pair from
a cryptosystem suitable for doing ECDSA</t>
<t>DPP: Device Provisioning Protocol <xref target="DPP"></xref></t>
<t>EAP: Extensible Authentication Protocol <xref target="RFC3748"/></t>
<t>EC: Elliptic Curve</t>
<t>ECDSA: Elliptic Curve Digital Signature Algorithm</t>
<t>EPSK: External Pre-Shared Key</t>
<t>EST: Enrollment over Secure Transport <xref target="RFC7030"/></t>
<t>NAI: Network Access Identifier</t>
<t>PSK: Pre-Shared Key</t>
<t>TEAP: Tunnel Extensible Authentication Protocol <xref target="RFC7170"/></t
>
</list></t>
</section>
<section anchor="bootstrapping-overview"><name>Bootstrapping Overview</name>
<t>A bootstrapping device holds a public / private elliptic curve (EC) key pair
which this document refers to as a Bootstrap Key (BSK). The private key of the B
SK is known only by the device. The public key of the BSK is known by the device
, is known by the owner or holder of the device, and is provisioned on the TLS s
erver by the TLS server operator. In order to establish trust and mutually authe
nticate, the TLS server proves to the device that it knows the public part of th
e 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> n
etwork access, or could for example be an Enrollment over Secure Transport (EST)
<xref target="RFC7030"/> server. In the case of authentication against an EAP s
erver, the EAP server <bcp14>SHOULD</bcp14> provision the device with a credenti
al that it uses for subsequent EAP authentication.</t>
</section>
<section anchor="eap-network-access"><name>EAP Network Access</name>
<t>Enterprise deployments typically require an <xref target="IEEE802.1X"></xref>
/EAP-based authentication to obtain network access. Protocols like Enrollment ov
er 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.
This creates a problem for bootstrapping devices where a certificate is needed f
or EAP authentication and 802.1X network access is needed to obtain a certificat
e.</t>
<t>Devices whose BSK public key can be obtained in an out-of-band fashion and pr
ovisioned on the EAP server can perform a TLS-based EAP exchange, for instance T
unnel Extensible Authentication Protocol (TEAP) <xref target="RFC7170"/>, and au
thenticate 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"/>)
to obtain a credential for subsequent EAP authentication. Certificate lifecycle
management may also be performed in subsequent TEAP transactions..</t>
</section>
<section 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 authenticatio
n. Therefore, an EAP method supporting the provisioning of a certificate on a de
vice is required. The only EAP method that currently supports provisioning of a
certificate on a device is TEAP, therefore this document assumes that TEAP is th
e only supported EAP method. Section <xref target="using-tls-bootstrapping-in-ea
p"/> describes how TLS-POK is used with TEAP, including defining a suitable Netw
ork Access Identifier (NAI).</t>
<t>If future EAP methods are defined supporting certificate provisioning, then T
LS-POK could potentially be used with those methods. Defining how this would wor
k is out of scope of this document.</t>
</section>
</section>
<section anchor="bootstrap-key"><name>Bootstrap Key</name>
<t>The mechanism for device on-boarding defined in this document relies on an el
liptic curve (EC) bootstrap key (BSK). This BSK <bcp14>MUST</bcp14> be from a cr
yptosystem suitable for doing ECDSA. A bootstrapping client device has an associ
ated EC BSK. The BSK may be static and baked into device firmware at manufacturi
ng time, or may be dynamic and generated at on-boarding time by the device. The
BSK public key <bcp14>MUST</bcp14> be encoded as the DER representation of an AS
N.1 SEQUENCE SubjectPublicKeyInfo from <xref target="RFC5480"/>. The subjectPubl
icKey <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 AlgorithmIdent
ifier in addition to the subjectPublicKey. If the BSK public key can be shared i
n a trustworthy manner with a TLS server, a form of "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 scan
ning 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 includes
this information. More information on QR encoding is given in <xref target="alig
nment-with-wi-fi-alliance-device-provisioning-profile"/>. If the QR code is phys
ically 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 t
o multiple devices, and existing TLS mechanisms are leveraged that enable the se
rver to identify a specific bootstrap public key corresponding to a specific dev
ice.</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 wh
ich the server obtained the BSK public key is trustworthy, a commensurate amount
of authenticity of the resulting connection can be obtained. The server also pr
oves that it knows the client's BSK public key which, if the client does not gra
tuitously 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>
<section anchor="alignment-with-wi-fi-alliance-device-provisioning-profile"><nam
e>Alignment with Wi-Fi Alliance Device Provisioning Profile</name>
<t>The definition of the BSK public key aligns with <xref target="DPP"></xref>.
This, for example, enables the QR code format as defined in <xref target="DPP"><
/xref> to be reused for TLS-POK. Therefore, a device that supports both wired LA
N and Wi-Fi LAN connections can have a single QR code printed on its label, or d
ynamically display a single QR code on a display, and the bootstrap key can be u
sed for DPP if the device bootstraps against a Wi-Fi 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 conne
cting over both wired and Wi-Fi networks.</t>
<t><xref target="DPP"></xref>, and therefore TLS-POK, does not support the use o
f RSA or post-quantum crypto systems due to the size of public key and its unsui
tableness to be represented in a QR code. If <xref target="DPP"></xref> is modif
ied in the future to support post-quantum crypto systems, this memo will be upda
ted to track support.</t>
<t>Any bootstrapping method defined for, or used by, <xref target="DPP"></xref>
is compatible with TLS-POK.</t>
</section>
</section>
<section 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 with an External Pre-Shared Key. The External PSK (EPSK) is deri
ved from the BSK public key as described in <xref target="external-psk-derivatio
n"/>, and the EPSK is imported using <xref target="RFC9258"/> Importing External
Pre-Shared Keys (PSKs) for TLS 1.3. As the BSK public key is an ASN.1 SEQUENCE
SubjectPublicKeyInfo from <xref target="RFC5480"/>, and not a full PKI Certifica
te, the client must present the BSK as a raw public key as described in <xref ta
rget="RFC7250"/> and use ECDSA as defined in <xref target="NIST.FIPS.186-5"/> fo
r authentication.</t>
<t>The TLS PSK handshake gives the client proof that the TLS server knows the BS
K 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="introduc
tion"/>.</t>
<section anchor="external-psk-derivation"><name>External PSK Derivation</name> <t>The following terminology is used throughout this document.</t>
<dl spacing="compact">
<dt>802.1X:</dt><dd>IEEE Port-Based Network Access Control <xref targe
t="IEEE8802.1x"/></dd>
<t>An <xref target="RFC9258"/> EPSK is made up of the tuple of (Base Key, Extern <dt>BSK:</dt><dd>Bootstrap Key, which is an elliptic curve public/pr
al Identity, Hash). The Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo r ivate key pair from a cryptosystem suitable for doing ECDSA</dd>
epresentation of the BSK public key. Zero byte padding <bcp14>MUST NOT</bcp14> b <dt>DPP:</dt><dd>Device Provisioning Profile <xref target="DPP"/></d
e added to the DER-encoded representation of the BSK public key.</t> d>
<dt>EAP:</dt><dd>Extensible Authentication Protocol <xref target="RF
C3748"/></dd>
<dt>EC:</dt><dd>Elliptic Curve</dd>
<dt>ECDSA:</dt><dd>Elliptic Curve Digital Signature Algorithm</dd>
<dt>EPSK:</dt><dd>External Pre-Shared Key</dd>
<dt>EST:</dt><dd>Enrollment over Secure Transport <xref target="RFC7
030"/></dd>
<dt>NAI:</dt><dd>Network Access Identifier</dd>
<dt>PSK:</dt><dd>Pre-Shared Key</dd>
<dt>TEAP:</dt><dd>Tunnel Extensible Authentication Protocol <xref ta
rget="RFC9930"/></dd>
</dl>
</section>
<section anchor="bootstrapping-overview">
<name>Bootstrapping Overview</name>
<t>A bootstrapping device holds a public/private Elliptic Curve (EC) key
pair, which this document refers to as a "Bootstrap Key" (or "BSK"). The privat
e key of the BSK is known only by the device. The public key of the BSK is:</t>
<ul spacing="compact">
<li>known by the device,</li>
<li>known by the owner or holder of the device, and</li>
<li>provisioned on the TLS server by the TLS server 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 pr
oves to the TLS server that it knows the private part of the BSK. More details o
n the BSK are given in <xref target="bootstrap-key"/>.</t>
<t>The TLS server could be an EAP server for 802.1X network access or co
uld, for example, be an Enrollment over Secure Transport (EST) <xref target="RFC
7030"/> server. In the case of authentication against an EAP server, the EAP ser
ver <bcp14>SHOULD</bcp14> provision the device with a credential that it uses fo
r subsequent EAP authentication.</t>
</section>
<section anchor="eap-network-access">
<name>EAP Network Access</name>
<t>Enterprise deployments typically require an 802.1X / EAP-based authen
tication to obtain network access. Protocols like Enrollment over Secure Transpo
rt (EST) <xref target="RFC7030"/> can be used to enroll devices with a Certifica
tion Authority to allow them to authenticate using 802.1X / EAP. This creates a
problem for bootstrapping devices where a certificate is needed for EAP authenti
cation and 802.1X network access is needed to obtain a certificate.</t>
<t>The External Identity is derived from the DER-encoded representation of the B <t>Devices whose BSK public key can be obtained in an out-of-band fashio
SK public key using <xref target="RFC5869"/> with the SHA-256 hash algorithm <xr n and provisioned on the EAP server can authenticate with the EAP server using t
ef target="sha2"></xref> as follows:</t> he mechanism defined in Sections <xref target="bootstrapping-in-tls-13" format="
counter"/> and <xref target="using-tls-bootstrapping-in-eap" format="counter"/>.
This network connectivity can then be used to perform an enrollment protocol (s
uch as provided by <xref target="RFC9930"/>) to obtain a credential for subseque
nt EAP authentication. Certificate lifecycle management may also be performed in
subsequent TEAP transactions.</t>
</section>
<section anchor="supported-eap-methods">
<name>Supported EAP Methods</name>
<t>This document defines a bootstrapping mechanism that results in a cer
tificate being provisioned on a device that can be used for subsequent EAP authe
ntication. Therefore, an EAP method supporting the provisioning of a certificate
on a device is required. The only EAP method that currently supports provisioni
ng of a certificate on a device is TEAP; therefore, this document assumes that T
EAP is the only supported EAP method. <xref target="using-tls-bootstrapping-in-e
ap"/> describes how TLS-POK is used with TEAP, including defining a suitable 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 w
ould work is out of scope of this document.</t>
</section>
</section>
<section anchor="bootstrap-key">
<name>Bootstrap Key</name>
<t>The mechanism for device onboarding defined in this document relies on
an EC BSK. This BSK <bcp14>MUST</bcp14> be from a cryptosystem suitable for doin
g ECDSA. A bootstrapping client device has an associated EC BSK. The BSK may be
static and baked into device firmware at manufacturing time or may be dynamic an
d generated at onboarding time by the device. The BSK public key <bcp14>MUST</bc
p14> be encoded as the DER representation of an ASN.1 SEQUENCE SubjectPublicKeyI
nfo from <xref target="RFC5480"/>. The subjectPublicKey <bcp14>MUST</bcp14> be t
he compressed format of the public key. Note that the BSK public key encoding <b
cp14>MUST</bcp14> include the ASN.1 AlgorithmIdentifier in addition to the subje
ctPublicKey. If the BSK public key can be shared in a trustworthy manner with a
TLS server, a form of 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 includ
e scanning a QR code to obtain a base64 encoding of the DER representation of th
e ASN.1 SubjectPublicKeyInfo or uploading of a Bill of Materials (BOM) that incl
udes 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 dev
ice, the assumption is that the BSK public key obtained in this bootstrapping me
thod belongs to the client. In this model, physical possession of the device imp
lies legitimate ownership of the device.</t>
<t>The TLS server may have knowledge of multiple BSK public keys correspon
ding to multiple devices, and existing TLS mechanisms are leveraged that enable
the server to identify a specific BSK public key corresponding to a specific dev
ice.</t>
<t>Using the process defined herein, the client proves to the TLS server t
hat 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 a
lso proves that it knows the client's BSK public key, which, if the client does
not gratuitously expose its public key, can be used to obtain a modicum of corre
ctness, that the client is connecting to the correct server (see <xref target="D
UCKLING"/>).</t>
<section anchor="alignment-with-wi-fi-alliance-device-provisioning-profile
">
<name>Alignment with Wi-Fi Alliance Device Provisioning Profile</name>
<figure><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" ver <t>The definition of the BSK public key aligns with <xref target="DPP"/>
sion="1.1" height="160" width="480" viewBox="0 0 480 160" class="diagram" text-a . This, for example, enables the QR code format as defined in <xref target="DPP"
nchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> /> to be reused for TLS-POK. Therefore, a device that supports both wired LAN an
<g class="text"> d Wi-Fi LAN connections can have a single QR code printed on its label, or dynam
<text x="28" y="36">epskid</text> ically display a single QR code on a display, and the BSK can be used for DPP if
<text x="64" y="36">=</text> the device bootstraps against a Wi-Fi network or TLS-POK if the device bootstra
<text x="188" y="36">HKDF-Expand(HKDF-Extract(&lt;&gt;,</text> ps against a wired network. Similarly, a common BSK public key format could be i
<text x="324" y="36">Base</text> mported into a BOM into a server that handles devices connecting over both wired
<text x="368" y="36">Key),</text> and Wi-Fi networks.</t>
<text x="280" y="52">&quot;tls13-bspsk-identity&quot;,</text> <t><xref target="DPP"/>, and therefore TLS-POK, does not support the use
<text x="388" y="52">L)</text> of RSA or postquantum crypto systems due to the size of public key and its unsu
<text x="28" y="68">where:</text> itableness to be represented in a QR code. If <xref target="DPP"/> is modified i
<text x="24" y="84">-</text> n the future to support postquantum crypto systems, this document will be update
<text x="60" y="84">epskid</text> d to track support.</t>
<text x="100" y="84">is</text> <t>Any bootstrapping method defined for, or used by, <xref target="DPP"/
<text x="128" y="84">the</text> > is compatible with TLS-POK.</t>
<text x="164" y="84">EPSK</text> </section>
<text x="220" y="84">External</text> </section>
<text x="292" y="84">Identity</text> <section anchor="bootstrapping-in-tls-13">
<text x="24" y="100">-</text> <name>Bootstrapping in TLS 1.3</name>
<text x="52" y="100">Base</text> <t>Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication (as
<text x="88" y="100">Key</text> per <xref target="RFC8773"/>) with an EPSK. The EPSK is derived from the BSK pu
<text x="116" y="100">is</text> blic key as described in <xref target="external-psk-derivation"/>, and the EPSK
<text x="144" y="100">the</text> is imported using "Importing External Pre-Shared Keys (PSKs) for TLS 1.3" <xref
<text x="208" y="100">DER-encoded</text> target="RFC9258"/>. As the BSK public key is an ASN.1 SEQUENCE SubjectPublicKeyI
<text x="280" y="100">ASN.1</text> nfo from <xref target="RFC5480"/>, and not a full PKI Certificate. The client mu
<text x="388" y="100">subjectPublicKeyInfo</text> st present the BSK as a raw public key as described in <xref target="RFC7250"/>
<text x="92" y="116">representation</text> and use ECDSA as defined in <xref target="NIST.FIPS.186-5"/> for authentication.
<text x="164" y="116">of</text> </t>
<text x="192" y="116">the</text> <t>The TLS PSK handshake gives the client proof that the TLS server knows
<text x="224" y="116">BSK</text> the BSK public key. Certificate-based authentication of the client to the server
<text x="268" y="116">public</text> using the BSK gives the server proof that the client knows the BSK private key.
<text x="312" y="116">key</text> This satisfies the proof of ownership requirements outlined in <xref target="in
<text x="24" y="132">-</text> troduction"/>.</t>
<text x="40" y="132">L</text> <section anchor="external-psk-derivation">
<text x="76" y="132">equals</text> <name>EPSK Derivation</name>
<text x="120" y="132">32,</text> <t>An EPSK <xref target="RFC9258"/> is made up of the tuple of (Base Key
<text x="152" y="132">the</text> , External Identity, Hash). The Base Key is the DER-encoded ASN.1 subjectPublicK
<text x="196" y="132">length</text> eyInfo representation of the BSK public key. Zero-byte padding <bcp14>MUST NOT</
<text x="236" y="132">in</text> bcp14> be added to the DER-encoded representation of the BSK public key.</t>
<text x="276" y="132">octets</text> <t>The External Identity is derived from the DER-encoded representation
<text x="316" y="132">of</text> of the BSK public key using <xref target="RFC5869"/> with the SHA-256 hash algor
<text x="344" y="132">the</text> ithm <xref target="SHA2"/> as follows:</t>
<text x="392" y="132">SHA-256</text> <artset>
<text x="452" y="132">output</text> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1
<text x="24" y="148">-</text> .1" height="160" width="480" viewBox="0 0 480 160" class="diagram" text-anchor="
<text x="44" y="148">&lt;&gt;</text> middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<text x="68" y="148">is</text> <g class="text">
<text x="88" y="148">a</text> <text x="28" y="36">epskid</text>
<text x="116" y="148">NULL</text> <text x="64" y="36">=</text>
<text x="156" y="148">salt</text> <text x="188" y="36">HKDF-Expand(HKDF-Extract(&lt;&gt;,</text>
<text x="200" y="148">which</text> <text x="324" y="36">Base</text>
<text x="236" y="148">is</text> <text x="368" y="36">Key),</text>
<text x="256" y="148">a</text> <text x="280" y="52">"tls13-bspsk-identity",</text>
<text x="292" y="148">string</text> <text x="388" y="52">L)</text>
<text x="332" y="148">of</text> <text x="28" y="68">where:</text>
<text x="352" y="148">L</text> <text x="24" y="84">-</text>
<text x="384" y="148">zeros</text> <text x="60" y="84">epskid</text>
</g> <text x="100" y="84">is</text>
</svg> <text x="128" y="84">the</text>
</artwork><artwork type="ascii-art"><![CDATA[ <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 type="ascii-art"><![CDATA[
epskid = HKDF-Expand(HKDF-Extract(<>, Base Key), epskid = HKDF-Expand(HKDF-Extract(<>, Base Key),
"tls13-bspsk-identity", L) "tls13-bspsk-identity", L)
where: where:
- epskid is the EPSK External Identity - epskid is the EPSK External Identity
- Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo - Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo
representation of the BSK public key representation of the BSK public key
- L equals 32, the length in octets of the SHA-256 output - L equals 32, the length in octets of the SHA-256 output
- <> is a NULL salt which is a string of L zeros - <> is a NULL 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=" <t>SHA-256 <bcp14>MUST</bcp14> be used when deriving epskid using <xref
RFC5869"/>.</t> target="RFC5869"/>.</t>
<t>The ImportedIdentity structure <xref target="RFC9258"/> is defined as
<t>The <xref target="RFC9258"/> ImportedIdentity structure is defined as:</t> :</t>
<artset>
<figure><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" ver <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1
sion="1.1" height="128" width="328" viewBox="0 0 328 128" class="diagram" text-a .1" height="128" width="328" viewBox="0 0 328 128" class="diagram" text-anchor="
nchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<g class="text"> <g class="text">
<text x="28" y="36">struct</text> <text x="28" y="36">struct</text>
<text x="64" y="36">{</text> <text x="64" y="36">{</text>
<text x="52" y="52">opaque</text> <text x="52" y="52">opaque</text>
<text x="204" y="52">external_identity&lt;1...2^16-1&gt;;</text> <text x="204" y="52">external_identity&lt;1...2^16-1&gt;;</text>
<text x="52" y="68">opaque</text> <text x="52" y="68">opaque</text>
<text x="160" y="68">context&lt;0..2^16-1&gt;;</text> <text x="160" y="68">context&lt;0..2^16-1&gt;;</text>
<text x="52" y="84">uint16</text> <text x="52" y="84">uint16</text>
<text x="148" y="84">target_protocol;</text> <text x="148" y="84">target_protocol;</text>
<text x="52" y="100">uint16</text> <text x="52" y="100">uint16</text>
<text x="128" y="100">target_kdf;</text> <text x="128" y="100">target_kdf;</text>
<text x="8" y="116">}</text> <text x="8" y="116">}</text>
<text x="88" y="116">ImportedIdentity;</text> <text x="88" y="116">ImportedIdentity;</text>
</g> </g>
</svg> </svg>
</artwork><artwork type="ascii-art"><![CDATA[ </artwork>
<artwork type="ascii-art"><![CDATA[
struct { struct {
opaque external_identity<1...2^16-1>; opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>; opaque context<0..2^16-1>;
uint16 target_protocol; uint16 target_protocol;
uint16 target_kdf; uint16 target_kdf;
} ImportedIdentity; } ImportedIdentity;
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>and is created using the following values:</t> <!--[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.
<figure><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" ver Original:
sion="1.1" height="96" width="264" viewBox="0 0 264 96" class="diagram" text-anc target_kdf = <as per RFC9258>
hor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<g class="text"> Perhaps:
<text x="72" y="36">external_identity</text> target_kdf = <as per RFC 9258>
<text x="152" y="36">=</text> -->
<text x="188" y="36">epskid</text> <t>and is created using the following values:</t>
<text x="32" y="52">context</text> <artset>
<text x="72" y="52">=</text> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1
<text x="128" y="52">&quot;tls13-bsk&quot;</text> .1" height="96" width="264" viewBox="0 0 264 96" class="diagram" text-anchor="mi
<text x="64" y="68">target_protocol</text> ddle" font-family="monospace" font-size="13px" stroke-linecap="round">
<text x="136" y="68">=</text> <g class="text">
<text x="204" y="68">TLS1.3(0x0304)</text> <text x="72" y="36">external_identity</text>
<text x="44" y="84">target_kdf</text> <text x="152" y="36">=</text>
<text x="96" y="84">=</text> <text x="188" y="36">epskid</text>
<text x="120" y="84">&lt;as</text> <text x="32" y="52">context</text>
<text x="152" y="84">per</text> <text x="72" y="52">=</text>
<text x="204" y="84">RFC9258&gt;</text> <text x="128" y="52">"tls13-bsk"</text>
</g> <text x="64" y="68">target_protocol</text>
</svg> <text x="136" y="68">=</text>
</artwork><artwork type="ascii-art"><![CDATA[ <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">RFC 9258&gt;</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
external_identity = epskid external_identity = epskid
context = "tls13-bsk" context = "tls13-bsk"
target_protocol = TLS1.3(0x0304) target_protocol = TLS1.3(0x0304)
target_kdf = <as per RFC9258> target_kdf = <as per RFC 9258>
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>The ImportedIdentity context value <bcp14>MUST</bcp14> be "tls13-bsk". This i <t>The ImportedIdentity context value <bcp14>MUST</bcp14> be "tls13-bsk"
nforms the server that the mechanisms specified in this document for deriving th . This informs the server that the mechanisms specified in this document for der
e EPSK and executing the TLS handshake <bcp14>MUST</bcp14> be used. The EPSK and iving the EPSK and executing the TLS handshake <bcp14>MUST</bcp14> be used. The
ImportedIdentity are used in the TLS handshake as specified in <xref target="RF EPSK and ImportedIdentity are used in the TLS handshake as specified in <xref ta
C9258"/>. Multiple ImportedIdentity values may be imported as per <xref target=" rget="RFC9258"/>. Multiple ImportedIdentity values may be imported as per <xref
RFC9258"/> section 5.1. The target_kdf follows <xref target="RFC9258"/> and alig target="RFC9258" section="5.1"/>. The target_kdf follows <xref target="RFC9258"/
ns with the cipher suite hash algorithms advertised in the TLS 1.3 handshake bet > and aligns with the cipher suite hash algorithms advertised in the TLS 1.3 han
ween the device and the server.</t> dshake between the device and the server.</t>
<t>A server can choose a trade-off between performance and storage by pr
<t>A server can choose a tradeoff between performance and storage by precomputin ecomputing the identity of every bootstrapped key with every hash algorithm that
g the identity of every bootstrapped key with every hash algorithm that it uses it uses in TLS and use that to quickly lookup the bootstrap key and generate th
in TLS and use that to quickly lookup the bootstrap key and generate the PSK. Se e PSK. Servers that choose not to employ this optimization will have to do a run
rvers that choose not to employ this optimization will have to do a runtime chec time check with every bootstrap key it holds against the identity the client pro
k with every bootstrap key it holds against the identity the client provides.</t vides.</t>
> <t>Test vectors for derivation of an EPSK External Identity from a BSK a
re given in the appendix.</t>
<t>Test vectors for derivation of an EPSK External Identity from a BSK are given </section>
in the appendix.</t> <section anchor="tls-13-handshake-details">
<name>TLS 1.3 Handshake Details</name>
</section> <t>The client includes the "tls_cert_with_extern_psk" extension in the C
<section anchor="tls-13-handshake-details"><name>TLS 1.3 Handshake Details</name lientHello, per <xref target="RFC8773"/>. The client identifies the BSK public k
> ey by inserting the serialized content of ImportedIdentity into the PskIdentity.
identity in the PSK extension, per <xref target="RFC9258"/>. The client <bcp14>M
<t>The client includes the "tls_cert_with_extern_psk" extension in the ClientHel UST</bcp14> also include the "client_certificate_type" extension per <xref targe
lo, per <xref target="RFC8773"/>. The client identifies the BSK public key by in t="RFC7250"/> in the ClientHello and <bcp14>MUST</bcp14> specify type of RawPubl
serting the serialized content of ImportedIdentity into the PskIdentity.identity icKey.</t>
in the PSK extension, per <xref target="RFC9258"/>. The client <bcp14>MUST</bcp <t>Upon receipt of the ClientHello, the server looks up the client's EPS
14> also include the <xref target="RFC7250"/> "client_certificate_type" extensio K in its database using the mechanisms documented in <xref target="RFC9258"/>. I
n in the ClientHello and <bcp14>MUST</bcp14> specify type of RawPublicKey.</t> f 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
<t>Upon receipt of the ClientHello, the server looks up the client's EPSK key in "tls_cert_with_extern_psk" extension in the ServerHello message and the correspo
its database using the mechanisms documented in <xref target="RFC9258"/>. If no nding EPSK identity in the "pre_shared_key" extension. When these extensions hav
match is found, the server <bcp14>MUST</bcp14> terminate the TLS handshake with e been successfully negotiated, the TLS 1.3 key schedule <bcp14>MUST</bcp14> inc
an alert. If the server finds the matching BSK public key, it includes the "tls lude both the EPSK in the Early Secret derivation and a Diffie-Hellman Ephemeral
_cert_with_extern_psk" extension in the ServerHello message, and the correspondi (DHE) or ECDHE shared secret value in the Handshake Secret derivation.</t>
ng EPSK identity in the "pre_shared_key" extension. When these extensions have b <t>After successful negotiation of these extensions, the full TLS 1.3 ha
een successfully negotiated, the TLS 1.3 key schedule <bcp14>MUST</bcp14> includ ndshake is performed with the additional caveat that the server <bcp14>MUST</bcp
e both the EPSK in the Early Secret derivation and an (EC)DHE shared secret valu 14> send a CertificateRequest message and the client <bcp14>MUST</bcp14> authent
e in the Handshake Secret derivation.</t> icate with a raw public key (its BSK) per <xref target="RFC7250"/>. The BSK is a
lways an EC key pair; therefore, the type of the client's Certificate <bcp14>MUS
<t>After successful negotiation of these extensions, the full TLS 1.3 handshake T</bcp14> be ECDSA and <bcp14>MUST</bcp14> contain the client's BSK public key a
is performed with the additional caveat that the server <bcp14>MUST</bcp14> send s a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE.</t>
a CertificateRequest message and the client <bcp14>MUST</bcp14> authenticate wi <t>Note that the client <bcp14>MUST NOT</bcp14> share its BSK public key
th a raw public key (its BSK) per <xref target="RFC7250"/>. The BSK is always an with the server until after the client has completed processing of the ServerHe
elliptic curve key pair, therefore the type of the client's Certificate <bcp14> llo and verified the TLS key schedule. The PSK proof is completed at this stage,
MUST</bcp14> be ECDSA and <bcp14>MUST</bcp14> contain the client's BSK public ke and the server has proven to the client that it knows the BSK public key, and i
y as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE.</t> t is therefore safe for the client to send the BSK public key to the server in t
he Certificate message. If the PSK verification step fails when processing the S
<t>Note that the client <bcp14>MUST NOT</bcp14> share its BSK public key with th erverHello, the client terminates the TLS handshake and the BSK public key <bcp1
e server until after the client has completed processing of the ServerHello and 4>MUST NOT</bcp14> be shared with the server.</t>
verified the TLS key schedule. The PSK proof is completed at this stage, and the <t>When the server processes the client's Certificate, it <bcp14>MUST</b
server has proven to the client that it knows the BSK public key, and it is the cp14> ensure that it is identical to the BSK public key that it used to generate
refore safe for the client to send the BSK public key to the server in the Certi the EPSK and ImportedIdentity for this handshake.</t>
ficate message. If the PSK verification step fails when processing the ServerHel <t>When clients are configured to trust the first network that proves po
lo, the client terminates the TLS handshake and the BSK public key <bcp14>MUST N ssession of their public key (as in <xref target="DUCKLING"/>), they <bcp14>MAY<
OT</bcp14> be shared with the server.</t> /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
<t>When the server processes the client's Certificate, it <bcp14>MUST</bcp14> en key in order to validate trust in the authenticated TLS connection.</t>
sure that it is identical to the BSK public key that it used to generate the EPS <t>The handshake is shown in <xref target="arch-one"/>.</t>
K and ImportedIdentity for this handshake.</t>
<t>When clients are configured to trust the first network which proves possessio
n of their public key (as in <xref target="duckling"></xref>), they <bcp14>MAY</
bcp14> forgo the checking of the server's certificate in the CertificateVerify a
nd 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 1.3 TLS-POK Handshake" anchor="arch-one"><artset><artwork ty <figure anchor="arch-one">
pe="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" widt <name>TLS 1.3 TLS-POK Handshake</name>
h="472" viewBox="0 0 472 368" class="diagram" text-anchor="middle" font-family=" <artset>
monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version=
<path d="M 8,80 L 8,128" fill="none" stroke="black"/> "1.1" height="368" width="472" viewBox="0 0 472 368" class="diagram" text-anchor
<path d="M 8,48 L 64,48" fill="none" stroke="black"/> ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 408,48 L 464,48" fill="none" stroke="black"/> <path d="M 8,80 L 8,128" fill="none" stroke="black"/>
<path d="M 224,128 L 288,128" fill="none" stroke="black"/> <path d="M 8,48 L 64,48" fill="none" stroke="black"/>
<path d="M 224,288 L 288,288" fill="none" stroke="black"/> <path d="M 408,48 L 464,48" fill="none" stroke="black"/>
<path d="M 224,336 L 288,336" fill="none" stroke="black"/> <path d="M 224,128 L 288,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="296,336 284,330.4 284,341.6" fill="black" tra <path d="M 224,288 L 288,288" fill="none" stroke="black"/>
nsform="rotate(0,288,336)"/> <path d="M 224,336 L 288,336" fill="none" stroke="black"/>
<polygon class="arrowhead" points="296,128 284,122.4 284,133.6" fill="black" tra <polygon class="arrowhead" points="296,336 284,330.4 284,341.6"
nsform="rotate(0,288,128)"/> fill="black" transform="rotate(0,288,336)"/>
<polygon class="arrowhead" points="232,288 220,282.4 220,293.6" fill="black" tra <polygon class="arrowhead" points="296,128 284,122.4 284,133.6"
nsform="rotate(180,224,288)"/> fill="black" transform="rotate(0,288,128)"/>
<g class="text"> <polygon class="arrowhead" points="232,288 220,282.4 220,293.6"
<text x="28" y="36">Client</text> fill="black" transform="rotate(180,224,288)"/>
<text x="428" y="36">Server</text> <g class="text">
<text x="48" y="68">ClientHello</text> <text x="28" y="36">Client</text>
<text x="100" y="84">cert_with_extern_psk</text> <text x="428" y="36">Server</text>
<text x="136" y="100">client_cert_type=RawPublicKey</text> <text x="48" y="68">ClientHello</text>
<text x="56" y="116">key_share</text> <text x="100" y="84">cert_with_extern_psk</text>
<text x="76" y="132">pre_shared_key</text> <text x="136" y="100">client_cert_type=RawPublicKey</text>
<text x="424" y="148">ServerHello</text> <text x="56" y="116">key_share</text>
<text x="296" y="164">+</text> <text x="76" y="132">pre_shared_key</text>
<text x="388" y="164">cert_with_extern_psk</text> <text x="424" y="148">ServerHello</text>
<text x="224" y="180">+</text> <text x="296" y="164">+</text>
<text x="352" y="180">client_cert_type=RawPublicKey</text> <text x="388" y="164">cert_with_extern_psk</text>
<text x="384" y="196">+</text> <text x="224" y="180">+</text>
<text x="432" y="196">key_share</text> <text x="352" y="180">client_cert_type=RawPublicKey</text>
<text x="344" y="212">+</text> <text x="384" y="196">+</text>
<text x="412" y="212">pre_shared_key</text> <text x="432" y="196">key_share</text>
<text x="384" y="228">{EncryptedExtensions}</text> <text x="344" y="212">+</text>
<text x="388" y="244">{CertificateRequest}</text> <text x="412" y="212">pre_shared_key</text>
<text x="416" y="260">{Certificate}</text> <text x="384" y="228">{EncryptedExtensions}</text>
<text x="392" y="276">{CertificateVerify}</text> <text x="388" y="244">{CertificateRequest}</text>
<text x="428" y="292">{Finished}</text> <text x="416" y="260">{Certificate}</text>
<text x="56" y="308">{Certificate}</text> <text x="392" y="276">{CertificateVerify}</text>
<text x="80" y="324">{CertificateVerify}</text> <text x="428" y="292">{Finished}</text>
<text x="44" y="340">{Finished}</text> <text x="56" y="308">{Certificate}</text>
</g> <text x="80" y="324">{CertificateVerify}</text>
</svg> <text x="44" y="340">{Finished}</text>
</artwork><artwork type="ascii-art"><![CDATA[ </g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
Client Server Client Server
-------- -------- -------- --------
ClientHello ClientHello
+ cert_with_extern_psk + cert_with_extern_psk
+ client_cert_type=RawPublicKey + client_cert_type=RawPublicKey
+ key_share + key_share
+ pre_shared_key --------> + pre_shared_key -------->
ServerHello ServerHello
+ cert_with_extern_psk + cert_with_extern_psk
+ client_cert_type=RawPublicKey + client_cert_type=RawPublicKey
+ key_share + key_share
+ pre_shared_key + pre_shared_key
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest} {CertificateRequest}
{Certificate} {Certificate}
{CertificateVerify} {CertificateVerify}
<-------- {Finished} <-------- {Finished}
{Certificate} {Certificate}
{CertificateVerify} {CertificateVerify}
{Finished} --------> {Finished} -------->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</section> </figure>
</section> </section>
<section anchor="using-tls-bootstrapping-in-eap"><name>Using TLS Bootstrapping i </section>
n EAP</name> <section 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 EA <t>Upon "link up", an Authenticator on an 802.1X-protected port will issue
P Identity request to the newly connected peer. For unprovisioned devices that d an EAP Identity request to the newly connected peer. For unprovisioned devices
esire to take advantage of TLS-POK, there is no initial realm in which to constr that desire to take advantage of TLS-POK, there is no initial realm in which to
uct an NAI (see <xref target="RFC7542"/>). This document uses the NAI mechanisms construct an NAI (see <xref target="RFC7542"/>). This document uses the NAI mech
defined in <xref target="I-D.ietf-emu-eap-arpa"/> and defines the EAP username anisms defined in <xref target="RFC9965"/> and defines the EAP username "tls-pok
"tls-pok-dpp" for use with the TEAP realm "teap.eap.arpa". The username "tls-pok -dpp" for use with the TEAP realm "teap.eap.arpa". The username "tls-pok-dpp" <b
-dpp" <bcp14>MUST</bcp14> be included yielding an initial identity of "tls-pok-d cp14>MUST</bcp14> be included, yielding an initial identity of "tls-pok-dpp@teap
pp@teap.eap.arpa". This identifier <bcp14>MUST</bcp14> be included in the EAP Id .eap.arpa". This identifier <bcp14>MUST</bcp14> be included in the EAP Identity
entity response in order to indicate to the Authenticator that TEAP is the desir response in order to indicate to the Authenticator that TEAP is the desired EAP
ed EAP method. <xref target="I-D.ietf-emu-eap-arpa"/> recommends how the device method. <xref target="RFC9965"/> recommends how the device should behave if the
should behave if the Authenticator does not support TEAP or TLS-POK.</t> Authenticator does not support TEAP or TLS-POK.</t>
<figure><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" ver <figure anchor="fig2">
sion="1.1" height="400" width="320" viewBox="0 0 320 400" class="diagram" text-a <name>EAP Exchange Using TLS-POK</name>
nchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artset>
<path d="M 8,48 L 64,48" fill="none" stroke="black"/> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1
<path d="M 200,48 L 272,48" fill="none" stroke="black"/> " height="400" width="320" viewBox="0 0 320 400" class="diagram" text-anchor="mi
<g class="text"> ddle" font-family="monospace" font-size="13px" stroke-linecap="round">
<text x="16" y="36">EAP</text> <path d="M 8,48 L 64,48" fill="none" stroke="black"/>
<text x="52" y="36">Peer</text> <path d="M 200,48 L 272,48" fill="none" stroke="black"/>
<text x="208" y="36">EAP</text> <g class="text">
<text x="252" y="36">Server</text> <text x="16" y="36">EAP</text>
<text x="204" y="68">&lt;-</text> <text x="52" y="36">Peer</text>
<text x="268" y="68">EAP-Request/</text> <text x="208" y="36">EAP</text>
<text x="228" y="84">Identity</text> <text x="252" y="36">Server</text>
<text x="56" y="116">EAP-Response/</text> <text x="204" y="68">&lt;-</text>
<text x="36" y="132">Identity</text> <text x="268" y="68">EAP-Request/</text>
<text x="112" y="148">(tls-pok-dpp@teap.eap.arpa)</text> <text x="228" y="84">Identity</text>
<text x="236" y="148">-&gt;</text> <text x="56" y="116">EAP-Response/</text>
<text x="204" y="180">&lt;-</text> <text x="36" y="132">Identity</text>
<text x="268" y="180">EAP-Request/</text> <text x="112" y="148">(tls-pok-dpp@teap.eap.arpa)</text>
<text x="248" y="196">EAP-Type=TEAP</text> <text x="236" y="148">-&gt;</text>
<text x="204" y="212">(TLS</text> <text x="204" y="180">&lt;-</text>
<text x="252" y="212">Start)</text> <text x="268" y="180">EAP-Request/</text>
<text x="56" y="244">EAP-Response/</text> <text x="248" y="196">EAP-Type=TEAP</text>
<text x="56" y="260">EAP-Type=TEAP</text> <text x="204" y="212">(TLS</text>
<text x="20" y="276">(TLS</text> <text x="252" y="212">Start)</text>
<text x="92" y="276">client_hello</text> <text x="56" y="244">EAP-Response/</text>
<text x="164" y="276">with</text> <text x="56" y="260">EAP-Type=TEAP</text>
<text x="108" y="292">tls_cert_with_extern_psk</text> <text x="20" y="276">(TLS</text>
<text x="24" y="308">and</text> <text x="92" y="276">client_hello</text>
<text x="104" y="308">pre_shared_key)</text> <text x="164" y="276">with</text>
<text x="180" y="308">-&gt;</text> <text x="108" y="292">tls_cert_with_extern_psk</text>
<text x="160" y="340">.</text> <text x="24" y="308">and</text>
<text x="160" y="356">.</text> <text x="104" y="308">pre_shared_key)</text>
<text x="160" y="372">.</text> <text x="180" y="308">-&gt;</text>
</g> <text x="160" y="340">.</text>
</svg> <text x="160" y="356">.</text>
</artwork><artwork type="ascii-art"><![CDATA[ <text x="160" y="372">.</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
EAP Peer EAP Server EAP Peer EAP Server
-------- ---------- -------- ----------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity Identity
(tls-pok-dpp@teap.eap.arpa) -> (tls-pok-dpp@teap.eap.arpa) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at line 409 skipping to change at line 406
EAP-Response/ EAP-Response/
EAP-Type=TEAP EAP-Type=TEAP
(TLS client_hello with (TLS client_hello with
tls_cert_with_extern_psk tls_cert_with_extern_psk
and pre_shared_key) -> and pre_shared_key) ->
. .
. .
. .
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>Both client and server have derived the EPSK and associated <xref target="RFC </figure>
9258"/> ImportedIdentity from the BSK public key as described in <xref target="e <t>Both client and server have derived the EPSK and associated ImportedId
xternal-psk-derivation"/>. When the client starts the TLS exchange in the EAP tr entity <xref target="RFC9258"/> from the BSK public key as described in <xref ta
ansaction, it includes the ImportedIdentity structure in the pre_shared_key exte rget="external-psk-derivation"/>. When the client starts the TLS exchange in the
nsion in the ClientHello. When the server receives the ClientHello, it extracts EAP transaction, it includes the ImportedIdentity structure in the pre_shared_k
the ImportedIdentity and looks up the EPSK and BSK public key. As previously men ey extension in the ClientHello. When the server receives the ClientHello, it ex
tioned in <xref target="bootstrap-key"/>, the exact mechanism by which the serve tracts the ImportedIdentity and looks up the EPSK and BSK public key. As previou
r has gained knowledge of or been provisioned with the BSK public key is outside sly mentioned in <xref target="bootstrap-key"/>, the exact mechanism by which th
the scope of this document.</t> e 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 i <t>The server continues with the TLS handshake and uses the EPSK to prove
t knows the BSK public key. When the client replies with its Certificate, Certif that it knows the BSK public key. When the client replies with its Certificate,
icateVerify and Finished messages, the server <bcp14>MUST</bcp14> ensure that th CertificateVerify, and Finished messages, the server <bcp14>MUST</bcp14> ensure
e public key in the Certificate message matches the BSK public key.</t> 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 establishe
<t>Once the TLS handshake completes, the client and server have established mutu d mutual trust. The server can then proceed to provision a credential onto the c
al trust. The server can then proceed to provision a credential onto the client lient using, for example, the mechanisms outlined in <xref target="RFC9930"/>.</
using, for example, the mechanisms outlined in <xref target="RFC7170"/>.</t> t>
<t>The client can then use this provisioned credential for subsequent EAP
<t>The client can then use this provisioned credential for subsequent EAP authen authentication. The BSK is only used during bootstrap and is not used for any su
tication. The BSK is only used during bootstrap, and is not used for any subsequ bsequent EAP authentication.</t>
ent EAP authentication.</t> </section>
<section anchor="iana-considerations">
</section> <name>IANA Considerations</name>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document adds the following to the "EAP Provisioning Identifiers" regist
ry in the "Extensible Authentication Protocol (EAP) Registry" group.</t>
<t>NAI: tls-pok-dpp@teap.eap.arpa
Method Type: TEAP
Reference: THIS DOCUMENT</t>
</section>
<section anchor="implementation-considerations"><name>Implementation Considerati
ons</name>
<t>Three key points are documented above, and are repeated here.</t>
<t><list style="symbols">
<t>The subjectPublicKey contained in the ASN.1 SEQUENCE SubjectPublicKeyInfo <
bcp14>MUST</bcp14> be the compressed format of the public key.</t>
<t>When deriving the External PSK from the BSK, zero byte padding <bcp14>MUST
NOT</bcp14> be added to the DER-encoded representation of the BSK public key.</t
>
<t>SHA-256 <bcp14>MUST</bcp14> be used when using <xref target="RFC5869"/> to
derive the External PSK from the BSK.</t>
<t>The BSK public key <bcp14>MUST NOT</bcp14> be freely available on the netwo
rk.</t>
</list></t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>Bootstrap and trust establishment by the TLS server is based on proof of know
ledge of the client's bootstrap public key, a non-public datum. The TLS server o
btains proof that the client knows its bootstrap public key and, in addition, al
so 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 tha
t the server knows its BSK public key. In addition, the client assumes that know
ledge of its BSK public key is not widely disseminated and 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"/>. <xref targe
t="duckling"></xref> describes a security model for this type of "imprinting".</
t>
<t>An attack on the bootstrapping method which substitutes the public key of a r
ogue device for the public key of an honest device can result in the TLS server
on-boarding 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 exampl
e, 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 t
he TLS-POK handshake with the client and the client will connect to the adversar
y's server. Since physical possession implies ownership, there is nothing to pre
vent a stolen device from being on-boarded.</t>
<t>The BSK keypair used for ECDSA <bcp14>MUST</bcp14> be generated and validated
according to 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, and cannot ensure that only specifi
c authorized devices are allowed connect to their networks.</t>
</section> <t>This document adds the following entry to the "EAP Provisioning Identif iers" registry in the "Extensible Authentication Protocol (EAP) Registry" regist ry group.</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 Considerations</name>
<t>Three key points are documented above and are repeated here.</t>
<ul spacing="normal">
<li>
<t>The subjectPublicKey contained in the ASN.1 SEQUENCE SubjectPublicK
eyInfo <bcp14>MUST</bcp14> be the compressed format of the public key.</t>
</li>
<li>
<t>When deriving the EPSK from the BSK, 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 following <xref target="RF
C5869"/> to derive the EPSK from the BSK.</t>
</li>
<li>
<t>The BSK public key <bcp14>MUST NOT</bcp14> be freely available on t
he network.</t>
</li>
</ul>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>Bootstrap and trust establishment by the TLS server are based on proof
of knowledge of the client's BSK public key, a non-public datum. The TLS server
obtains proof that the client knows its BSK public key and also possesses its co
rresponding private key.</t>
<t>Trust on the part of the client is based on successful completion of th
e TLS 1.3 handshake using the EPSK derived from the BSK. This proves to the clie
nt that the server knows its BSK public key. In addition, the client assumes tha
t knowledge of its BSK public key is not widely disseminated; therefore, any ser
ver that proves knowledge of its BSK public key is the appropriate server from w
hich to receive provisioning, for instance via <xref target="RFC9930"/>. <xref t
arget="DUCKLING"/> describes a security model for this type of "imprinting".</t>
<t>An attack on the bootstrapping method, which substitutes the public key
of a rogue device for the public key of an honest device, can result in the TLS
server onboarding and trusting the rogue device.</t>
<t>If an adversary has knowledge of the BSK public key, the adversary may
be able to make the client bootstrap against the adversary's network. For exampl
e, 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 t
he TLS-POK handshake with the client and the client will connect to the adversar
y's server. Since physical possession implies ownership, there is nothing to pre
vent a stolen device from being onboarded.</t>
<t>The BSK key pair used for ECDSA <bcp14>MUST</bcp14> be generated and va
lidated according to Section 6.2 of <xref target="NIST.FIPS.186-5"/>.</t>
<t>Manufacturers <bcp14>SHOULD</bcp14> use a unique BSK for every single d
evice they manufacture. If multiple devices share the same BSK, then network ope
rators cannot differentiate between these devices and cannot ensure that only sp
ecific authorized devices are allowed connect to their networks.</t>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references">
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="NIST.FIPS.186-5" target="https://nvlpubs.nist.gov/nis
tpubs/FIPS/NIST.FIPS.186-5.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization abbrev="NIST">National Institute of Standards and Te
chnology</organization>
</author>
<date month="February" year="2023"/>
</front>
<seriesInfo name="NIST 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.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
773.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
258.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
250.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
869.xml"/>
<references title='References' anchor="sec-combined-references"> <!-- [RFC9965]
draft-ietf-emu-eap-arpa-10
<references title='Normative References' anchor="sec-normative-references"> companion doc RFC9965
in EDIT as of 12/12/25
<reference anchor="NIST.FIPS.186-5" target="https://nvlpubs.nist.gov/nistpubs/FI -->
PS/NIST.FIPS.186-5.pdf"> <reference anchor="RFC9965" target="https://www.rfc-editor.org/info/rfc9
<front> 965">
<title>Digital Signature Standard (DSS)</title> <front>
<author fullname="Dustin Moody" surname="Moody"> <title>The eap.arpa. Domain and Extensible Authentication Protocol (
<organization>Information Technology Laboratory</organization> EAP) Provisioning</title>
</author> <author initials="A." surname="DeKok" fullname="Alan DeKok">
<author> <organization>InkBridge Networks</organization>
<organization>National Institute of Standards and Technology</organization </author>
> <date month='May' year='2026'/>
<address> </front>
<postal> <seriesInfo name="RFC" value="9965"/>
<country>US</country> <seriesInfo name="DOI" value="10.17487/RFC9965"/>
<city>Gaithersburg</city> </reference>
</postal>
</address>
</author>
<date year="2023"/>
</front>
<seriesInfo name="NIST Federal Information Processing Standards Publications"
value="186-5"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<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 docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase 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 that may be used in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE usage 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>
<reference anchor="RFC5480">
<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 for the Internet X.509 Public Key Infrastructure Certificate an
d Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5480"/>
<seriesInfo name="DOI" value="10.17487/RFC5480"/>
</reference>
<reference anchor="RFC8773">
<front>
<title>TLS 1.3 Extension for Certificate-Based Authentication with an Extern
al Pre-Shared Key</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="March" year="2020"/>
<abstract>
<t>This document specifies a TLS 1.3 extension that allows a server to aut
henticate with a combination of a certificate and an external pre-shared key (PS
K).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8773"/>
<seriesInfo name="DOI" value="10.17487/RFC8773"/>
</reference>
<reference anchor="RFC9258">
<front>
<title>Importing External Pre-Shared Keys (PSKs) 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 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>
<reference anchor="RFC7250">
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) 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="Tschof
enig"/>
<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 f
or exchanging raw public keys in Transport Layer Security (TLS) and Datagram Tra
nsport Layer Security (DTLS). The new certificate type allows raw public keys to
be used for authentication.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7250"/>
<seriesInfo name="DOI" value="10.17487/RFC7250"/>
</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 (HM
AC)-based key derivation function (HKDF), which can be used as a building block
in various protocols and applications. The key derivation function (KDF) is inte
nded to support a wide range of applications and requirements, and is conservati
ve 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 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 that they wish to
obtain limited, and unauthenticated, network access. EAP peers
signal which kind of access is required via certain predefined
identifiers which use the Network Access Identifier (NAI) format of
RFC 7542. A table of identifiers and meanings is defined, which
includes entries for RFC 9140.
This document updates RFC5216 and RFC9190 to define an
unauthenticated provisioning method. Those specifications suggested
that such a method has possible, but they did not define 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>
<references anchor="sec-informative-references">
<name>Informative References</name>
<references title='Informative References' anchor="sec-informative-reference <reference anchor="IEEE8802.1x" target="https://ieeexplore.ieee.org/docu
s"> ment/9650828">
<front>
<title>IEEE/ISO/IEC International
Standard-Telecommunications and exchange between information
technology systems--Requirements for local and metropolitan area
networks-/-Part 1X:Port-based network access control</title>
<author>
<organization>IEEE/ISO/IEC</organization>
</author>
<date year="2021"/>
</front>
<seriesInfo name='ISO/IEC/IEEE' value='8802-1X:2021' />
<seriesInfo name='DOI' value='10.1109/IEEESTD.2021.9650828' />
</reference>
<reference anchor="IEEE802.1X" > <reference anchor="DPP" target="https://www.wi-fi.org/system/files/Wi-Fi
<front> _Easy_Connect_Specification_v3.0.pdf">
<title>Port-Based Network Access Control</title> <front>
<author initials="" surname="IEEE" fullname="IEEE"> <title>Wi-Fi Easy Connect(TM) Specification</title>
<organization>IEEE</organization> <author>
</author> <organization>Wi-Fi Alliance</organization>
<date year="2010"/> </author>
</front> <date year="2022"/>
</reference> </front>
<reference anchor="DPP" > <refcontent>Version 3.0</refcontent>
<front> </reference>
<title>Device Provisioning Profile</title>
<author >
<organization>Wi-Fi Alliance</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference 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 Networ
ks</title>
<author initials="F." surname="Stajano" fullname="Frank Stajano">
<organization></organization>
</author>
<author initials="R." surname="Anderson" fullname="Ross Anderson">
<organization></organization>
</author>
<date year="1999"/>
</front>
</reference>
<reference anchor="sha2" target="https://doi.org/10.6028/NIST.FIPS.180-4">
<front>
<title>FIPS 180-4 Secure Hash Standard (SHS)</title>
<author >
<organization>National Institute of Standards and Technology</organization
>
</author>
<date year="2015" month="August"/>
</front>
</reference>
<reference anchor="RFC3748"> <reference anchor="DUCKLING" target="https://www.cl.cam.ac.uk/~fms27/pap
<front> ers/1999-StajanoAnd-duckling.pdf">
<title>Extensible Authentication Protocol (EAP)</title> <front>
<author fullname="B. Aboba" initials="B." surname="Aboba"/> <title>The Resurrecting Duckling: Security Issues for Ad-Hoc Wireles
<author fullname="L. Blunk" initials="L." surname="Blunk"/> s Networks</title>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/> <author initials="F." surname="Stajano" fullname="Frank Stajano">
<author fullname="J. Carlson" initials="J." surname="Carlson"/> <organization/>
<author fullname="H. Levkowetz" initials="H." role="editor" surname="Levkowe </author>
tz"/> <author initials="R." surname="Anderson" fullname="Ross Anderson">
<date month="June" year="2004"/> <organization/>
<abstract> </author>
<t>This document defines the Extensible Authentication Protocol (EAP), an <date year="1999"/>
authentication framework which supports multiple authentication methods. EAP typ </front>
ically runs directly over data link layers such as Point-to-Point Protocol (PPP) <refcontent>Security Protocols, 7th International Workshop Proceedings
or IEEE 802, without requiring IP. EAP provides its own support for duplicate e , Lecture Notes in Computer Science, vol. 1796,
limination and retransmission, but is reliant on lower layer ordering guarantees pp. 172-182</refcontent>
. Fragmentation is not supported within EAP itself; however, individual EAP meth <seriesInfo name="DOI" value="10.1007/10720107_24"/>
ods may support this. This document obsoletes RFC 2284. A summary of the changes </reference>
between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK <reference anchor="SHA2" target="https://nvlpubs.nist.gov/nistpubs/FIPS/
]</t> NIST.FIPS.180-4.pdf">
</abstract> <front>
</front> <title>Secure Hash Standard</title>
<seriesInfo name="RFC" value="3748"/> <author>
<seriesInfo name="DOI" value="10.17487/RFC3748"/> <organization abbrev="NIST">National Institute of Standards and Te
</reference> chnology</organization>
<reference anchor="RFC7030"> </author>
<front> <date month="August" year="2015"/>
<title>Enrollment over Secure Transport</title> </front>
<author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin <seriesInfo name="NIST FIPS" value="180-4"/>
"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
<author fullname="P. Yee" initials="P." role="editor" surname="Yee"/> </reference>
<author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
> 748.xml"/>
<date month="October" year="2013"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 030.xml"/>
<t>This document profiles certificate enrollment for clients using Certifi
cate Management over CMS (CMC) messages over a secure transport. This profile, c
alled Enrollment over Secure Transport (EST), describes a simple, yet functional
, certificate management protocol targeting Public Key Infrastructure (PKI) clie
nts that need to acquire client certificates and associated Certification Author
ity (CA) certificates. It also supports client-generated public/private key pair
s as well as key pairs generated by the CA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7030"/>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
</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 (TE
AP) version 1. TEAP is a tunnel-based EAP method that enables secure communicati
on between a peer and a server by using the Transport Layer Security (TLS) proto
col to establish a mutually authenticated tunnel. Within the tunnel, TLV objects
are used to convey authentication-related data between the EAP peer and 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 necessa
ry to have a standardized method that domains can use to identify each other's u
sers. This document defines the syntax for the Network Access Identifier (NAI),
the user identifier submitted by the client prior to accessing resources. This d
ocument is a revised version of RFC 4282. It addresses issues with international
character sets and makes a number of other corrections to RFC 4282.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7542"/>
<seriesInfo name="DOI" value="10.17487/RFC7542"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
930.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
542.xml"/>
</references>
</references> </references>
</references> <!--[rfced] We see that the test vectors that exist in the appendices
are not formatted in the XML as <sourcecode>. Additionally, as
<?line 332?> they currently exist, the portion in <tt> extends beyond the 72
character line limit. We suggest reformatting these as
<section anchor="test-vectors"><name>Test Vectors</name> <sourcecode> with a type set to test-vectors (or maybe base64?).
<section anchor="test-vector-1-prime256v1"><name>Test Vector 1: prime256v1</name
>
<t>Base64 encoding of BSK:</t>
<t><spanx style="verb">MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzaf
uVEvM+kNYCxpEC6KITLb9g=</spanx></t>
<t>Base64 encoding of epskid:</t>
<t><spanx style="verb">Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=</spanx></t>
</section>
<section anchor="test-vector-2-secp384r1"><name>Test Vector 2: secp384r1</name>
<t>Base64 encoding of BSK:</t>
<t><spanx style="verb">MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0R
JnijJG1em8ZKilryZRDfNioq7+EPquT6l9laRvw</spanx></t>
<t>Base64 encoding of epskid:</t>
<t><spanx style="verb">yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=</spanx></t>
</section>
<section anchor="test-vector-3-secp521r1"><name>Test Vector 3: secp521r1</name>
<t>Base64 encoding of BSK:</t>
<t><spanx style="verb">MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j5
3rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CA
QYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz
4XngXUeFyDXliEo3eF6vhqD</spanx></t>
<t>Base64 encoding of epskid:</t>
<t><spanx style="verb">D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=</spanx></t>
</section>
<section anchor="test-vector-4-brainpoolp256r1"><name>Test Vector 4: brainpoolP2
56r1</name>
<t>Base64 encoding of BSK:</t>
<t><spanx style="verb">MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88Jzm
VqnoT/reuCvq8lHowtwWNOZ</spanx></t>
<t>Base64 encoding of epskid:</t>
<t><spanx style="verb">j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=</spanx></t> See https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
for more information on <sourcecode> types.
</section> -->
</section>
<section anchor="test-vectors">
<name>Test Vectors</name>
<section anchor="test-vector-1-prime256v1">
<name>Test Vector 1: prime256v1</name>
<t>Base64 encoding of BSK:</t>
<sourcecode type="test-vectors">MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLy
oOykj8sFJxSoZfzafuVEvM+kNYCxpEC6KITLb9g=</sourcecode>
<t>Base64 encoding of epskid:</t>
<t><tt>Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=</tt></t>
</section>
<section anchor="test-vector-2-secp384r1">
<name>Test Vector 2: secp384r1</name>
<t>Base64 encoding of BSK:</t>
<sourcecode type="test-vectors">MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1py
tcR1WbfqPaNGaXQ0RJnijJG1em8ZKilryZRDfNioq7+EPquT6l9laRvw</sourcecode>
<t>Base64 encoding of epskid:</t>
<sourcecode type="test-vectors">yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL
+8w=</sourcecode>
</section>
<section anchor="test-vector-3-secp521r1">
<name>Test Vector 3: secp521r1</name>
<t>Base64 encoding of BSK:</t>
<sourcecode type="test-vectors">MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOX
dPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD
MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW
5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD</sourcecode>
<t>Base64 encoding of epskid:</t>
<t><tt>D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=</tt></t>
</section>
<section anchor="test-vector-4-brainpoolp256r1">
<name>Test Vector 4: brainpoolP256r1</name>
<t>Base64 encoding of BSK:</t>
<sourcecode type="test-vectors">MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fy
UWqiV8NC9DAC88JzmVqnoT/reuCvq8lHowtwWNOZ</sourcecode>
<t>Base64 encoding of epskid:</t>
<sourcecode type="test-vectors">j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR9
3EY=</sourcecode>
</section>
</section>
</back> </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
</rfc> </rfc>
 End of changes. 40 change blocks. 
1161 lines changed or deleted 767 lines changed or added

This html diff was produced by rfcdiff 1.48.