RFC 9966

Bootstrapped TLS Authentication with Proof of Knowledge

📅 published May 2026, from ietf

Bootstrapped TLS Authentication with Proof of Knowledge ✨

Okay bestie, so this is RFC 9966, and it's giving serious standards energy 💅. It was written by O. Friel from Cisco and D. Harkins from Hewlett-Packard Enterprise, and it's a Standards Track document (ISSN 2070-1721) dated May 2026. Its header doesn't list anything it obsoletes or updates, so it doesn't replace or change any older RFC 🫶.

Abstract

Okay so this doc defines a mechanism that helps a bootstrapping device establish trust and mutually authenticate against a TLS server 🔐. Bootstrapping devices have a public/private key pair. This mechanism lets the TLS server prove to the device that it knows the public key, and lets the device prove to the TLS server that it knows the private key. It's built on existing Device Provisioning Profile (DPP) and TLS standards, and it can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server 💜.

Status of This Memo

This is an Internet Standards Track document 🎀.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🌸.

Info about the current status of this document, any errata, and how to give feedback on it is at https://www.rfc-editor.org/info/rfc9966 ✨.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License ⚖️.

1.  Introduction
  1.1.  Terminology
  1.2.  Bootstrapping Overview
  1.3.  EAP Network Access
  1.4.  Supported EAP Methods
2.  Bootstrap Key
  2.1.  Alignment with Wi-Fi Alliance Device Provisioning Profile
3.  Bootstrapping in TLS 1.3
  3.1.  EPSK Derivation
  3.2.  TLS 1.3 Handshake Details
4.  Using TLS Bootstrapping in EAP
5.  IANA Considerations
6.  Implementation Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Test Vectors
  A.1.  Test Vector 1: prime256v1
  A.2.  Test Vector 2: secp384r1
  A.3.  Test Vector 3: secp521r1
  A.4.  Test Vector 4: brainpoolP256r1
Authors' Addresses

1. Introduction

Onboarding devices with no (or limited) user interface can be so hard 😭. Sometimes you need a credential to get on a network based on [IEEE8802.1x] or EAP, but you need network connectivity to get that credential in the first place. Major chicken-and-egg energy 🐣, and that's the challenge for onboarding devices.

If a device has a public/private key pair, and you can get trust in the integrity of the device's public key out-of-band, then the device can be authenticated and provisioned with a usable credential for [IEEE8802.1x] / EAP-based network access ✨. This authentication can be strong, but the device's authentication of the network is somewhat weaker. [DUCKLING] presents a functional security model to address this asymmetry 🧚.

Device onboarding protocols like the Device Provisioning Profile [DPP], also called Wi-Fi Easy Connect, address this use case, but they have drawbacks 🙈. For example, [DPP] doesn't support wired network access and doesn't specify how the device's DPP key pair can be used in a TLS handshake. This document describes an authentication mechanism that a device can use to mutually authenticate against a TLS server, and it describes how that authentication protocol can be used in an EAP exchange for wired network access as described in [IEEE8802.1x]. This protocol is called "TLS Proof of Knowledge" or "TLS-POK" 🦋.

This document does not address the problem of wireless network discovery, where a bootstrapping device detects multiple different wireless networks and needs a more robust and scalable mechanism than simple round-robin to figure out which network to attach to. DPP handles this for Wi-Fi, but DPP's discovery won't work on a wired [IEEE8802.1x] ethernet port, and TLS-POK will. So, TLS-POK SHOULD NOT be used for bootstrapping against wireless networks and SHOULD be used for bootstrapping against wired networks. 🍓

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📚.

The following terminology is used throughout this document 💅:

802.1X: IEEE Port-Based Network Access Control [IEEE8802.1x]
BSK: Bootstrap Key, which is an elliptic curve public/private key pair from a cryptosystem suitable for doing ECDSA
DPP: Device Provisioning Profile [DPP]
EAP: Extensible Authentication Protocol [RFC3748]
EC: Elliptic Curve
ECDSA: Elliptic Curve Digital Signature Algorithm
EPSK: External Pre-Shared Key
EST: Enrollment over Secure Transport [RFC7030]
NAI: Network Access Identifier
PSK: Pre-Shared Key
TEAP: Tunnel Extensible Authentication Protocol [RFC9930]

1.2. Bootstrapping Overview

A bootstrapping device holds a public/private Elliptic Curve (EC) key pair, which this document calls a "Bootstrap Key" (or "BSK") 🔑. The private key of the BSK is known only by the device. The public key of the BSK is:

known by the device,
known by the owner or holder of the device, and
provisioned on the TLS server by the TLS server operator.

To establish trust and mutually authenticate, the TLS server proves to the device that it knows the public part of the BSK, and the device proves to the TLS server that it knows the private part of the BSK 🫶. More details on the BSK are in Section 2.

The TLS server could be an EAP server for 802.1X network access, or it could be, for example, an Enrollment over Secure Transport (EST) [RFC7030] server. If you're authenticating against an EAP server, the EAP server SHOULD provision the device with a credential that it uses for subsequent EAP authentication 👑.

1.3. EAP Network Access

Enterprise deployments typically need an 802.1X / EAP-based authentication to get network access. Protocols like Enrollment over Secure Transport (EST) [RFC7030] can enroll devices with a Certification Authority so they can authenticate using 802.1X / EAP. This creates a problem for bootstrapping devices: a certificate is needed for EAP authentication, but 802.1X network access is needed to get a certificate 😩.

Devices whose BSK public key can be obtained out-of-band and provisioned on the EAP server can authenticate with the EAP server using the mechanism defined in Sections 3 and 4 🌈. That network connectivity can then be used to run an enrollment protocol (such as the one provided by [RFC9930]) to get a credential for subsequent EAP authentication. Certificate lifecycle management may also be done in subsequent TEAP transactions 🧁.

1.4. Supported EAP Methods

This document defines a bootstrapping mechanism that results in a certificate being provisioned on a device that can be used for subsequent EAP authentication. So an EAP method that supports provisioning a certificate on a device is required. The only EAP method that currently supports provisioning a certificate on a device is TEAP, so this document assumes that TEAP is the only supported EAP method 🎯. Section 4 describes how TLS-POK is used with TEAP, including defining a suitable NAI.

If future EAP methods get defined that support certificate provisioning, then TLS-POK could potentially be used with those methods. Defining how that would work is out of scope for this document 🌸.

2. Bootstrap Key

The mechanism for device onboarding defined in this document relies on an EC BSK. This BSK MUST be from a cryptosystem suitable for doing ECDSA 🔐. A bootstrapping client device has an associated EC BSK. The BSK may be static and baked into device firmware at manufacturing time, or it may be dynamic and generated at onboarding time by the device ✨. The BSK public key MUST be encoded as the DER representation of an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480]. The subjectPublicKey MUST be the compressed format of the public key. Note that the BSK public key encoding MUST include the ASN.1 AlgorithmIdentifier in addition to the subjectPublicKey. If the BSK public key can be shared in a trustworthy manner with a TLS server, a form of entity authentication (the step from which all subsequent authentication proceeds) can be obtained 🎀.

The exact mechanism by which the TLS server gets the BSK public key is out of scope for this specification 🙅‍♀️, but possible mechanisms include scanning a QR code to get a base64 encoding of the DER representation of the ASN.1 SubjectPublicKeyInfo, or uploading a Bill of Materials (BOM) that includes this information. More info on QR encoding is in Section 2.1. If the QR code is physically attached to the client device, or the BOM is associated with the device, the assumption is that the BSK public key obtained this way belongs to the client. In this model, physical possession of the device implies legitimate ownership of the device 🧚.

The TLS server may know about multiple BSK public keys for multiple devices, and existing TLS mechanisms get leveraged so the server can identify the specific BSK public key for a specific device 💜.

Using the process defined here, the client proves to the TLS server that it has possession of the private key of its BSK. As long as the mechanism the server used to get the BSK public key is trustworthy, a commensurate amount of authenticity of the resulting connection can be obtained. The server also proves that it knows the client's BSK public key, which (if the client doesn't gratuitously expose its public key) can give a modicum of correctness, that the client is connecting to the correct server (see [DUCKLING]) 🦋.

2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile 🎀

okay so the BSK public key is built to line up with [DPP] 💅 which means the QR code format from [DPP] can be reused for TLS-POK ✨ a device with both wired LAN and Wi-Fi LAN can wear ONE QR code on its label (or flash it on a screen) 🙈 then the BSK gets used for DPP if the device bootstraps over Wi-Fi, or TLS-POK if it bootstraps over a wired network. iconic, no notes 🫶 a common BSK public key format could also be imported into a BOM into a server that handles devices on both wired and Wi-Fi networks 🌸

ngl the one limit here: [DPP], and therefore TLS-POK, does NOT support RSA or postquantum crypto systems 💀 the public key is too big to fit in a QR code 😭 if [DPP] ever gets updated to support postquantum crypto systems, this document will be updated to track that 🔮

and anything that's a bootstrapping method for [DPP] (or used by it) is compatible with TLS-POK 🧚 lowkey the best kind of teamwork 💜

3. Bootstrapping in TLS 1.3 ✨

okay this is where the magic happens 🦋 bootstrapping in TLS 1.3 uses Certificate-Based Authentication (as per [RFC8773]) together with an EPSK 💖 the EPSK gets derived from the BSK public key (see Section 3.1) and then imported using "Importing External Pre-Shared Keys (PSKs) for TLS 1.3" [RFC9258]. the BSK public key is an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480], and it is NOT a full PKI Certificate 🙈 the client has to present the BSK as a raw public key as described in [RFC7250] and use ECDSA as defined in [NIST.FIPS.186-5] for authentication 🔐

the TLS PSK handshake gives the client proof that the TLS server knows the BSK public key 🌈 and the certificate-based auth of the client to the server with the BSK gives the server proof that the client knows the BSK private key 🥹 that checks off the proof of ownership requirements from Section 1 💅 slay

3.1. EPSK Derivation 🍓

an EPSK [RFC9258] is basically a tuple of (Base Key, External Identity, Hash) ✨ the Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key. and zero-byte padding MUST NOT be added to that DER-encoded representation 🚫 no sneaky padding, bestie 🙅‍♀️

the External Identity gets derived from the DER-encoded representation of the BSK public key using [RFC5869] with the SHA-256 hash algorithm [SHA2], like this:

epskid = HKDF-Expand(HKDF-Extract(<>, Base Key),
                       "tls13-bspsk-identity", L)

where:

epskid is the EPSK External Identity
Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key
L equals 32, the length in octets of the SHA-256 output
<> is a NULL salt, which is a string of L zeros

SHA-256 MUST be used when deriving epskid using [RFC5869] 🔥 no other hash for this one, periodt

the ImportedIdentity structure [RFC9258] is defined as:

struct {
   opaque external_identity<1...2^16-1>;
   opaque context<0..2^16-1>;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;

and it gets created with these values:

external_identity = epskid
context = "tls13-bsk"
target_protocol = TLS1.3(0x0304)
target_kdf = <as per RFC 9258>

the ImportedIdentity context value MUST be "tls13-bsk" 💜 that tells the server to use the mechanisms in this document for deriving the EPSK and running the TLS handshake, and that part is NOT optional 😤 the EPSK and ImportedIdentity then get used in the TLS handshake as specified in [RFC9258]. Multiple ImportedIdentity values may be imported as per Section 5.1 of [RFC9258] ✨ and the target_kdf follows [RFC9258] and lines up with the cipher suite hash algorithms advertised in the TLS 1.3 handshake between the device and the server 🎀

okay so servers have a choice here 🧁 they can trade performance against storage by precomputing the identity of every bootstrapped key with every hash algorithm they use in TLS, then quickly looking up the bootstrap key and generating the PSK from that 🚀 servers that skip this optimization will have to run a runtime check of every bootstrap key they hold against the identity the client gives them 🐢 slower, but valid vibes

test vectors for deriving an EPSK External Identity from a BSK are in the appendix 🦋

3.2. TLS 1.3 Handshake Details 🌸

the client puts the "tls_cert_with_extern_psk" extension in the ClientHello, per [RFC8773] 💖 it identifies the BSK public key by inserting the serialized content of ImportedIdentity into the PskIdentity.identity in the PSK extension, per [RFC9258] ✨ and the client MUST also include the "client_certificate_type" extension per [RFC7250] in the ClientHello, and MUST specify type of RawPublicKey 🙌

when the ClientHello arrives, the server looks up the client's EPSK in its database using the mechanisms in [RFC9258] 👀 if there's no match, the server MUST terminate the TLS handshake with an alert 🚨 but if the server DOES find the matching BSK public key, it includes the "tls_cert_with_extern_psk" extension in the ServerHello, plus the matching EPSK identity in the "pre_shared_key" extension 🥰 once those extensions are successfully negotiated, the TLS 1.3 key schedule MUST include BOTH the EPSK in the Early Secret derivation AND a Diffie-Hellman Ephemeral (DHE) or ECDHE shared secret value in the Handshake Secret derivation 🫧 two keys, one handshake, zero drama

after these extensions are successfully negotiated, the full TLS 1.3 handshake runs with one extra caveat: the server MUST send a CertificateRequest message, and the client MUST authenticate with a raw public key (its BSK) per [RFC7250] 🔑 the BSK is always an EC key pair, so the type of the client's Certificate MUST be ECDSA, and it MUST contain the client's BSK public key as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE 💅

and now the most important bit 🚨 the client MUST NOT share its BSK public key with the server until AFTER it has finished processing the ServerHello and verified the TLS key schedule 😤 the PSK proof is completed at this stage, so the server has proven to the client that it knows the BSK public key, and it is therefore safe for the client to send the BSK public key in the Certificate message 🥹 but if the PSK verification step fails when processing the ServerHello, the client terminates the TLS handshake, and the BSK public key MUST NOT be shared with the server 🛑 never leak your key to a sus server, bestie

when the server processes the client's Certificate, it MUST ensure that it is identical to the BSK public key it used to generate the EPSK and ImportedIdentity for this handshake 🔍 no swapping keys mid-call

when clients are set up to trust the first network that proves it has their public key (as in [DUCKLING]), they MAY skip checking the server's certificate in the CertificateVerify 🦋 and instead they rely on the integrity of the bootstrapping method used to distribute the key to validate trust in the authenticated TLS connection 🫶

the handshake is shown in Figure 1 ✨

         Client                                            Server
         --------                                          --------
         ClientHello
         + cert_with_extern_psk
         + client_cert_type=RawPublicKey
         + key_share
         + pre_shared_key           -------->
                                                        ServerHello
                                             + cert_with_extern_psk
                                    + client_cert_type=RawPublicKey
                                                        + key_share
                                                   + pre_shared_key
                                              {EncryptedExtensions}
                                               {CertificateRequest}
                                                      {Certificate}
                                                {CertificateVerify}
                                    <--------            {Finished}
         {Certificate}
         {CertificateVerify}
         {Finished}                 -------->

                 Figure 1: TLS 1.3 TLS-POK Handshake

4. Using TLS Bootstrapping in EAP 🧚

okay EAP time 🎀 upon "link up", an Authenticator on an 802.1X-protected port sends an EAP Identity request to the newly connected peer 📡 for unprovisioned devices that want TLS-POK, there's no initial realm to build an NAI from (see [RFC7542]) 😭 so this document uses the NAI mechanisms defined in [RFC9965] and defines the EAP username "tls-pok-dpp" for use with the TEAP realm "teap.eap.arpa" 💖 the username "tls-pok-dpp" MUST be included, giving an initial identity of "tls-pok-dpp@teap.eap.arpa" 🏷️ this identifier MUST be included in the EAP Identity response to tell the Authenticator that TEAP is the EAP method we want 🎯 and [RFC9965] recommends how the device should behave if the Authenticator doesn't support TEAP or TLS-POK 🧠

    EAP Peer                EAP Server
    --------                ----------
                            <- EAP-Request/
                            Identity

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

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

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

                       .
                       .
                       .

                 Figure 2: EAP Exchange Using TLS-POK

both the client and the server have derived the EPSK and the associated ImportedIdentity [RFC9258] from the BSK public key, as described in Section 3.1 🤝 when the client starts the TLS exchange in the EAP transaction, it includes the ImportedIdentity structure in the pre_shared_key extension in the ClientHello 📦 when the server gets the ClientHello, it pulls out the ImportedIdentity and looks up the EPSK and BSK public key 🔎 as mentioned in Section 2, HOW the server gained knowledge of (or was provisioned with) the BSK public key is outside the scope of this document 🙃 not our problem, bestie

the server continues the TLS handshake and uses the EPSK to prove that it knows the BSK public key 🦋 when the client replies with its Certificate, CertificateVerify, and Finished messages, the server MUST ensure that the public key in the Certificate message matches the BSK public key 🛡️

once the TLS handshake finishes, the client and server have established mutual trust ✨ the server can then go ahead and provision a credential onto the client using, for example, the mechanisms outlined in [RFC9930] 🎁

the client can then use this provisioned credential for later EAP authentication 🌈 the BSK is ONLY used during bootstrap, and it is NOT used for any subsequent EAP authentication 🫶 one and done, iykyk

5. IANA Considerations 🌷

this document adds the following entry to the "EAP Provisioning Identifiers" registry in the "Extensible Authentication Protocol (EAP) Registry" registry group 📝

NAI:  tls-pok-dpp@teap.eap.arpa

Method Type:  TEAP

Reference:  RFC 9966

6. Implementation Considerations ✨

okay bestie, the spec repeats three key points from earlier sections, plus one more, so you don't miss them 🫶

The subjectPublicKey inside the ASN.1 SEQUENCE SubjectPublicKeyInfo MUST be the compressed format of the public key. 💅
When you derive the EPSK from the BSK, zero-byte padding MUST NOT be added to the DER-encoded representation of the BSK public key. 🙅‍♀️
SHA-256 MUST be used when following [RFC5869] to derive the EPSK from the BSK. 🔐
The BSK public key MUST NOT be freely available on the network. 🤫

7. Security Considerations 💀

okay this section is serious, so get comfy and pay attention 🙈

Bootstrap and trust establishment by the TLS server are based on proof of knowledge of the client's BSK public key, which is a non-public datum. So the TLS server gets proof that the client knows its BSK public key AND that it has the matching private key. Main character energy for the client, honestly 👑

Trust on the client's side comes from successfully finishing the TLS 1.3 handshake using the EPSK derived from the BSK. That proves to the client that the server knows its BSK public key ✨. The client also assumes the BSK public key isn't widely spread around, so any server that proves it knows that key is the right server to get provisioning from, for example via [RFC9930]. [DUCKLING] describes a security model for this kind of "imprinting" 🦋.

An attack on the bootstrapping method that swaps the public key of a rogue device in for the public key of an honest device can result in the TLS server onboarding and trusting the rogue device. 💀

If an adversary knows the BSK public key, they may be able to make the client bootstrap against the adversary's network 😭. For example, if an adversary intercepts and scans QR labels on clients, and can force the client to connect to its server, then the adversary can complete the TLS-POK handshake with the client, and the client will connect to the adversary's server. Since physical possession implies ownership, nothing stops a stolen device from getting onboarded. It's giving "finders keepers" and that's not it 🙅‍♀️

The BSK key pair used for ECDSA MUST be generated and validated according to Section 6.2 of [NIST.FIPS.186-5]. 🔑

Manufacturers SHOULD use a unique BSK for every single device they make 🏭. If multiple devices share the same BSK, network operators can't tell those devices apart, and they can't make sure that only specific authorized devices are allowed to connect to their networks. Lowkey the most important tip in the whole doc 🍓

8. References 📚

8.1. Normative References

[NIST.FIPS.186-5]
           NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
           DOI 10.6028/NIST.FIPS.186-5, February 2023,
           <https://nvlpubs.nist.gov/nistpubs/FIPS/
           NIST.FIPS.186-5.pdf>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
           "Elliptic Curve Cryptography Subject Public Key
           Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
           <https://www.rfc-editor.org/info/rfc5480>.

[RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
           Key Derivation Function (HKDF)", RFC 5869,
           DOI 10.17487/RFC5869, May 2010,
           <https://www.rfc-editor.org/info/rfc5869>.

[RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
           Weiler, S., and T. Kivinen, "Using Raw Public Keys in
           Transport Layer Security (TLS) and Datagram Transport
           Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
           June 2014, <https://www.rfc-editor.org/info/rfc7250>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8773]  Housley, R., "TLS 1.3 Extension for Certificate-Based
           Authentication with an External Pre-Shared Key", RFC 8773,
           DOI 10.17487/RFC8773, March 2020,
           <https://www.rfc-editor.org/info/rfc8773>.

[RFC9258]  Benjamin, D. and C. A. Wood, "Importing External Pre-
           Shared Keys (PSKs) for TLS 1.3", RFC 9258,
           DOI 10.17487/RFC9258, July 2022,
           <https://www.rfc-editor.org/info/rfc9258>.

[RFC9965]  DeKok, A., "The eap.arpa. Domain and Extensible
           Authentication Protocol (EAP) Provisioning", RFC 9965,
           DOI 10.17487/RFC9965, May 2026,
           <https://www.rfc-editor.org/info/rfc9965>.

8.2. Informative References

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

[DUCKLING] Stajano, F. and R. Anderson, "The Resurrecting Duckling:
           Security Issues for Ad-Hoc Wireless Networks", Security
           Protocols, 7th International Workshop Proceedings, Lecture
           Notes in Computer Science, vol. 1796, pp. 172-182,
           DOI 10.1007/10720107_24, 1999,
           <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
           duckling.pdf>.

[IEEE8802.1x]
           IEEE/ISO/IEC, "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", ISO/IEC/IEEE 8802-1X:2021,
           DOI 10.1109/IEEESTD.2021.9650828, 2021,
           <https://ieeexplore.ieee.org/document/9650828>.

[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
           RFC 3748, DOI 10.17487/RFC3748, June 2004,
           <https://www.rfc-editor.org/info/rfc3748>.

[RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
           "Enrollment over Secure Transport", RFC 7030,
           DOI 10.17487/RFC7030, October 2013,
           <https://www.rfc-editor.org/info/rfc7030>.

[RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
           DOI 10.17487/RFC7542, May 2015,
           <https://www.rfc-editor.org/info/rfc7542>.

[RFC9930]  DeKok, A., Ed., "Tunnel Extensible Authentication Protocol
           (TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930,
           February 2026, <https://www.rfc-editor.org/info/rfc9930>.

[SHA2]     NIST, "Secure Hash Standard", NIST FIPS 180-4,
           DOI 10.6028/NIST.FIPS.180-4, August 2015,
           <https://nvlpubs.nist.gov/nistpubs/FIPS/
           NIST.FIPS.180-4.pdf>.

Appendix A. Test Vectors 🧪

A.1. Test Vector 1: prime256v1

Base64 encoding of BSK:

MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxp
EC6KITLb9g=

Base64 encoding of epskid:

Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=

A.2. Test Vector 2: secp384r1

Base64 encoding of BSK:

MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZK
ilryZRDfNioq7+EPquT6l9laRvw

Base64 encoding of epskid:

yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=

A.3. Test Vector 3: secp521r1

Base64 encoding of BSK:

MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZ
UvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQ
YFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HD
QfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD

Base64 encoding of epskid:

D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=

A.4. Test Vector 4: brainpoolP256r1

Base64 encoding of BSK:

MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/
reuCvq8lHowtwWNOZ

Base64 encoding of epskid:

j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=

Authors' Addresses 🎀

Owen Friel
Cisco
Email: ofriel@cisco.com


Dan Harkins
Hewlett-Packard Enterprise
Email: daniel.harkins@hpe.com

That's the whole spec, bestie! 🌈💖 Go hug your test vectors 🧚

📦 where this page comes from

ietf: rfc9966 2026-05
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms

RFC 9966

Bootstrapped TLS Authentication with Proof of Knowledge ✨

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

1.1. Terminology

1.2. Bootstrapping Overview

1.3. EAP Network Access

1.4. Supported EAP Methods

2. Bootstrap Key

2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile 🎀

3. Bootstrapping in TLS 1.3 ✨

3.1. EPSK Derivation 🍓

3.2. TLS 1.3 Handshake Details 🌸

4. Using TLS Bootstrapping in EAP 🧚

5. IANA Considerations 🌷

6. Implementation Considerations ✨

7. Security Considerations 💀

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. Test Vectors 🧪

A.1. Test Vector 1: prime256v1

A.2. Test Vector 2: secp384r1

A.3. Test Vector 3: secp521r1

A.4. Test Vector 4: brainpoolP256r1

Authors' Addresses 🎀