rfc9966.original   rfc9966.txt 
Network Working Group O. Friel Internet Engineering Task Force (IETF) O. Friel
Internet-Draft Cisco Request for Comments: 9966 Cisco
Intended status: Standards Track D. Harkins Category: Standards Track D. Harkins
Expires: 4 April 2026 Hewlett-Packard Enterprise ISSN: 2070-1721 Hewlett-Packard Enterprise
1 October 2025 April 2026
Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)
draft-ietf-emu-bootstrapped-tls-11
Abstract Abstract
This document defines a mechanism that enables a bootstrapping device This document defines a mechanism that enables a bootstrapping device
to establish trust and mutually authenticate against a TLS server. to establish trust and mutually authenticate against a TLS server.
Bootstrapping devices have a public/private key pair, and this Bootstrapping devices have a public/private key pair; this mechanism
mechanism enables a TLS server to prove to the device that it knows enables a TLS server to prove to the device that it knows the public
the public key, and the device to prove to the TLS server that it key and enables the device to prove to the TLS server that it knows
knows the private key. The mechanism leverages existing Device the private key. The mechanism leverages existing Device
Provisioning Protocol (DPP) and TLS standards and can be used in an Provisioning Protocol (DPP) and TLS standards and can be used in an
Extensible Authentication Protocol (EAP) exchange with an EAP server. Extensible Authentication Protocol (EAP) exchange with an EAP server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 April 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9966.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.2. Bootstrapping Overview . . . . . . . . . . . . . . . . . 4 1.2. Bootstrapping Overview
1.3. EAP Network Access . . . . . . . . . . . . . . . . . . . 4 1.3. EAP Network Access
1.4. Supported EAP Methods . . . . . . . . . . . . . . . . . . 5 1.4. Supported EAP Methods
2. Bootstrap Key . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Bootstrap Key
2.1. Alignment with Wi-Fi Alliance Device Provisioning 2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile
Profile . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Bootstrapping in TLS 1.3
3. Bootstrapping in TLS 1.3 . . . . . . . . . . . . . . . . . . 6 3.1. EPSK Derivation
3.1. External PSK Derivation . . . . . . . . . . . . . . . . . 7 3.2. TLS 1.3 Handshake Details
3.2. TLS 1.3 Handshake Details . . . . . . . . . . . . . . . . 8 4. Using TLS Bootstrapping in EAP
4. Using TLS Bootstrapping in EAP . . . . . . . . . . . . . . . 10 5. IANA Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Considerations
6. Implementation Considerations . . . . . . . . . . . . . . . . 11 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Test Vectors
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 14 A.1. Test Vector 1: prime256v1
A.1. Test Vector 1: prime256v1 . . . . . . . . . . . . . . . . 14 A.2. Test Vector 2: secp384r1
A.2. Test Vector 2: secp384r1 . . . . . . . . . . . . . . . . 15 A.3. Test Vector 3: secp521r1
A.3. Test Vector 3: secp521r1 . . . . . . . . . . . . . . . . 15 A.4. Test Vector 4: brainpoolP256r1
A.4. Test Vector 4: brainpoolP256r1 . . . . . . . . . . . . . 15 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
On-boarding devices with no, or limited, user interface can be Onboarding devices with no, or limited, user interface can be
difficult. Sometimes a credential is needed to access an difficult. Sometimes a credential is needed to access a network
[IEEE802.1X]/EAP-based network, and network connectivity is needed to based on [IEEE802.1X] or EAP, and network connectivity is needed to
obtain a credential. This poses a challenge for on-boarding devices. obtain a credential. This poses a challenge for onboarding devices.
If a device has a public / private keypair, and trust in the If a device has a public/private key pair, and trust in the integrity
integrity of a device's public key can be obtained in an out-of-band of a device's public key can be obtained in an out-of-band fashion, a
fashion, a device can be authenticated and provisioned with a usable device can be authenticated and provisioned with a usable credential
credential for [IEEE802.1X]/EAP-based network access. While this for [IEEE802.1X] / EAP-based network access. While this
authentication can be strong, the device's authentication of the authentication can be strong, the device's authentication of the
network is somewhat weaker. [duckling] presents a functional network is somewhat weaker. [DUCKLING] presents a functional
security model to address this asymmetry. security model to address this asymmetry.
Device on-boarding protocols such as the Device Provisioning Profile Device onboarding protocols such as the Device Provisioning Profile
[DPP], also referred to as Wi-Fi Easy Connect, address this use case [DPP], also referred to as Wi-Fi Easy Connect, address this use case,
but they have drawbacks. [DPP] for instance does not support wired but they have drawbacks. For instance, [DPP] does not support wired
network access, and does not specify how the device's DPP keypair can network access and does not specify how the device's DPP key pair can
be used in a TLS handshake. This document describes an an be used in a TLS handshake. This document describes an
authentication mechanism that a device can use to mutually authentication mechanism that a device can use to mutually
authenticate against a TLS server, and describes how that authenticate against a TLS server and describes how that
authentication protocol can be used in an EAP exchange for authentication protocol can be used in an EAP exchange for wired
[IEEE802.1X] wired network access. This protocol is called TLS Proof network access as described in [IEEE802.1X]. This protocol is called
of Knowledge or TLS-POK. "TLS Proof of Knowledge" or "TLS-POK".
This document does not address the problem of wireless network This document does not address the problem of wireless network
discovery, where a bootstrapping device detects multiple different discovery, where a bootstrapping device detects multiple different
wireless networks and needs a more robust and scalable mechanism than wireless networks and needs a more robust and scalable mechanism than
simple round-robin to determine the correct network to attach to. simple round-robin to determine the correct network to attach to.
DPP addresses this issue for Wi-Fi but DPP's discovery will not work DPP addresses this issue for Wi-Fi, but DPP's discovery will not work
on a wired 802.1X ethernet port, but TLS-POK will. Therefore, TLS- on a wired [IEEE802.1X] ethernet port, but TLS-POK will. Therefore,
POK SHOULD NOT be used for bootstrapping against wireless networks, TLS-POK SHOULD NOT be used for bootstrapping against wireless
and SHOULD be used for bootstrapping against wired networks. networks and SHOULD be used for bootstrapping against wired networks.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terminology is used throughout this document. The following terminology is used throughout this document.
* 802.1X: IEEE Port-Based Network Access Control 802.1X: IEEE Port-Based Network Access Control [IEEE802.1X]
BSK: Bootstrap Key, which is an elliptic curve public/private key
* BSK: Bootstrap Key which is an elliptic curve public/private key
pair from a cryptosystem suitable for doing ECDSA pair from a cryptosystem suitable for doing ECDSA
DPP: Device Provisioning Protocol [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]
* DPP: Device Provisioning Protocol [DPP] 1.2. Bootstrapping Overview
* 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 [RFC7170] A bootstrapping device holds a public/private Elliptic Curve (EC) key
pair, which this document refers to as a "Bootstrap Key" (or "BSK").
The private key of the BSK is known only by the device. The public
key of the BSK is:
1.2. Bootstrapping Overview * known by the device,
* known by the owner or holder of the device, and
* provisioned on the TLS server by the TLS server operator.
A bootstrapping device holds a public / private elliptic curve (EC) In order to establish trust and mutually authenticate, the TLS server
key pair which this document refers to as a Bootstrap Key (BSK). The proves to the device that it knows the public part of the BSK, and
private key of the BSK is known only by the device. The public key the device proves to the TLS server that it knows the private part of
of the BSK is known by the device, is known by the owner or holder of the BSK. More details on the BSK are given in Section 2.
the device, and is provisioned on the TLS server by the TLS server
operator. In order to establish trust and mutually authenticate, the
TLS server proves to the device that it knows the public part of the
BSK, and the device proves to the TLS server that it knows the
private part of the BSK. More details on the BSK are given in
Section 2.
The TLS server could be an EAP server for [IEEE802.1X] network The TLS server could be an EAP server for [IEEE802.1X] network access
access, or could for example be an Enrollment over Secure Transport or could, for example, be an Enrollment over Secure Transport (EST)
(EST) [RFC7030] server. In the case of authentication against an EAP [RFC7030] server. In the case of authentication against an EAP
server, the EAP server SHOULD provision the device with a credential server, the EAP server SHOULD provision the device with a credential
that it uses for subsequent EAP authentication. that it uses for subsequent EAP authentication.
1.3. EAP Network Access 1.3. EAP Network Access
Enterprise deployments typically require an [IEEE802.1X]/EAP-based Enterprise deployments typically require an [IEEE802.1X] / EAP-based
authentication to obtain network access. Protocols like Enrollment authentication to obtain network access. Protocols like Enrollment
over Secure Transport (EST) [RFC7030] can be used to enroll devices over Secure Transport (EST) [RFC7030] can be used to enroll devices
with a Certification Authority to allow them to authenticate using with a Certification Authority to allow them to authenticate using
802.1X/EAP. This creates a problem for bootstrapping devices where a IEEE 802.1X / EAP. This creates a problem for bootstrapping devices
certificate is needed for EAP authentication and 802.1X network where a certificate is needed for EAP authentication and 802.1X
access is needed to obtain a certificate. network access is needed to obtain a certificate.
Devices whose BSK public key can be obtained in an out-of-band Devices whose BSK public key can be obtained in an out-of-band
fashion and provisioned on the EAP server can perform a TLS-based EAP fashion and provisioned on the EAP server can perform a TLS-based EAP
exchange, for instance Tunnel Extensible Authentication Protocol exchange, for instance Tunnel Extensible Authentication Protocol
(TEAP) [RFC7170], and authenticate the TLS exchange using the (TEAP) [RFC9930], and authenticate the TLS exchange using the
authentication mechanisms defined in Section 3. This network authentication mechanisms defined in Section 3. This network
connectivity can then be used to perform an enrollment protocol (such connectivity can then be used to perform an enrollment protocol (such
as provided by [RFC7170]) to obtain a credential for subsequent EAP as provided by [RFC9930]) to obtain a credential for subsequent EAP
authentication. Certificate lifecycle management may also be authentication. Certificate lifecycle management may also be
performed in subsequent TEAP transactions.. performed in subsequent TEAP transactions.
1.4. Supported EAP Methods 1.4. Supported EAP Methods
This document defines a bootstrapping mechanism that results in a This document defines a bootstrapping mechanism that results in a
certificate being provisioned on a device that can be used for certificate being provisioned on a device that can be used for
subsequent EAP authentication. Therefore, an EAP method supporting subsequent EAP authentication. Therefore, an EAP method supporting
the provisioning of a certificate on a device is required. The only the provisioning of a certificate on a device is required. The only
EAP method that currently supports provisioning of a certificate on a EAP method that currently supports provisioning of a certificate on a
device is TEAP, therefore this document assumes that TEAP is the only device is TEAP; therefore, this document assumes that TEAP is the
supported EAP method. Section Section 4 describes how TLS-POK is only supported EAP method. Section 4 describes how TLS-POK is used
used with TEAP, including defining a suitable Network Access with TEAP, including defining a suitable NAI.
Identifier (NAI).
If future EAP methods are defined supporting certificate If future EAP methods are defined supporting certificate
provisioning, then TLS-POK could potentially be used with those provisioning, then TLS-POK could potentially be used with those
methods. Defining how this would work is out of scope of this methods. Defining how this would work is out of scope of this
document. document.
2. Bootstrap Key 2. Bootstrap Key
The mechanism for device on-boarding defined in this document relies The mechanism for device onboarding defined in this document relies
on an elliptic curve (EC) bootstrap key (BSK). This BSK MUST be from on an EC BSK. This BSK MUST be from a cryptosystem suitable for
a cryptosystem suitable for doing ECDSA. A bootstrapping client doing ECDSA. A bootstrapping client device has an associated EC BSK.
device has an associated EC BSK. The BSK may be static and baked The BSK may be static and baked into device firmware at manufacturing
into device firmware at manufacturing time, or may be dynamic and time or may be dynamic and generated at onboarding time by the
generated at on-boarding time by the device. The BSK public key MUST device. The BSK public key MUST be encoded as the DER representation
be encoded as the DER representation of an ASN.1 SEQUENCE of an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480]. The
SubjectPublicKeyInfo from [RFC5480]. The subjectPublicKey MUST be subjectPublicKey MUST be the compressed format of the public key.
the compressed format of the public key. Note that the BSK public Note that the BSK public key encoding MUST include the ASN.1
key encoding MUST include the ASN.1 AlgorithmIdentifier in addition AlgorithmIdentifier in addition to the subjectPublicKey. If the BSK
to the subjectPublicKey. If the BSK public key can be shared in a public key can be shared in a trustworthy manner with a TLS server, a
trustworthy manner with a TLS server, a form of "entity form of entity authentication (the step from which all subsequent
authentication" (the step from which all subsequent authentication authentication proceeds) can be obtained.
proceeds) can be obtained.
The exact mechanism by which the TLS server gains knowledge of the The exact mechanism by which the TLS server gains knowledge of the
BSK public key is out of scope of this specification, but possible BSK public key is out of scope of this specification, but possible
mechanisms include scanning a QR code to obtain a base64 encoding of mechanisms include scanning a QR code to obtain a base64 encoding of
the DER representation of the ASN.1 SubjectPublicKeyInfo or uploading the DER representation of the ASN.1 SubjectPublicKeyInfo or uploading
of a Bill of Materials (BOM) which includes this information. More of a Bill of Materials (BOM) that includes this information. More
information on QR encoding is given in Section 2.1. If the QR code information on QR encoding is given in Section 2.1. If the QR code
is physically attached to the client device, or the BOM is associated is physically attached to the client device, or the BOM is associated
with the device, the assumption is that the BSK public key obtained with the device, the assumption is that the BSK public key obtained
in this bootstrapping method belongs to the client. In this model, in this bootstrapping method belongs to the client. In this model,
physical possession of the device implies legitimate ownership of the physical possession of the device implies legitimate ownership of the
device. device.
The TLS server may have knowledge of multiple BSK public keys The TLS server may have knowledge of multiple BSK public keys
corresponding to multiple devices, and existing TLS mechanisms are corresponding to multiple devices, and existing TLS mechanisms are
leveraged that enable the server to identify a specific bootstrap leveraged that enable the server to identify a specific bootstrap
public key corresponding to a specific device. public key corresponding to a specific device.
Using the process defined herein, the client proves to the TLS server 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 that it has possession of the private key of its BSK. Provided that
the mechanism in which the server obtained the BSK public key is the mechanism in which the server obtained the BSK public key is
trustworthy, a commensurate amount of authenticity of the resulting trustworthy, a commensurate amount of authenticity of the resulting
connection can be obtained. The server also proves that it knows the connection can be obtained. The server also proves that it knows the
client's BSK public key which, if the client does not gratuitously client's BSK public key, which, if the client does not gratuitously
expose its public key, can be used to obtain a modicum of expose its public key, can be used to obtain a modicum of
correctness, that the client is connecting to the correct server (see correctness, that the client is connecting to the correct server (see
[duckling]). [DUCKLING]).
2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile 2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile
The definition of the BSK public key aligns with [DPP]. This, for The definition of the BSK public key aligns with [DPP]. This, for
example, enables the QR code format as defined in [DPP] to be reused example, enables the QR code format as defined in [DPP] to be reused
for TLS-POK. Therefore, a device that supports both wired LAN and for TLS-POK. Therefore, a device that supports both wired LAN and
Wi-Fi LAN connections can have a single QR code printed on its label, Wi-Fi LAN connections can have a single QR code printed on its label,
or dynamically display a single QR code on a display, and the or dynamically display a single QR code on a display, and the BSK can
bootstrap key can be used for DPP if the device bootstraps against a be used for DPP if the device bootstraps against a Wi-Fi network or
Wi-Fi network, or TLS-POK if the device bootstraps against a wired TLS-POK if the device bootstraps against a wired network. Similarly,
network. Similarly, a common bootstrap public key format could be a common bootstrap public key format could be imported into a BOM
imported into a BOM into a server that handles devices connecting into a server that handles devices connecting over both wired and Wi-
over both wired and Wi-Fi networks. Fi networks.
[DPP], and therefore TLS-POK, does not support the use of RSA or [DPP], and therefore TLS-POK, does not support the use of RSA or
post-quantum crypto systems due to the size of public key and its postquantum crypto systems due to the size of public key and its
unsuitableness to be represented in a QR code. If [DPP] is modified unsuitableness to be represented in a QR code. If [DPP] is modified
in the future to support post-quantum crypto systems, this memo will in the future to support postquantum crypto systems, this document
be updated to track support. will be updated to track support.
Any bootstrapping method defined for, or used by, [DPP] is compatible Any bootstrapping method defined for, or used by, [DPP] is compatible
with TLS-POK. with TLS-POK.
3. Bootstrapping in TLS 1.3 3. Bootstrapping in TLS 1.3
Bootstrapping in TLS 1.3 leverages [RFC8773] Certificate-Based Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication
Authentication with an External Pre-Shared Key. The External PSK (as per [RFC8773]) with an EPSK. The EPSK is derived from the BSK
(EPSK) is derived from the BSK public key as described in public key as described in Section 3.1, and the EPSK is imported
Section 3.1, and the EPSK is imported using [RFC9258] Importing using "Importing External Pre-Shared Keys (PSKs) for TLS 1.3"
External Pre-Shared Keys (PSKs) for TLS 1.3. As the BSK public key [RFC9258]. As the BSK public key is an ASN.1 SEQUENCE
is an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480], and not a SubjectPublicKeyInfo from [RFC5480], and not a full PKI Certificate.
full PKI Certificate, the client must present the BSK as a raw public The client must present the BSK as a raw public key as described in
key as described in [RFC7250] and use ECDSA as defined in [RFC7250] and use ECDSA as defined in [NIST.FIPS.186-5] for
[NIST.FIPS.186-5] for authentication. authentication.
The TLS PSK handshake gives the client proof that the TLS server The TLS PSK handshake gives the client proof that the TLS server
knows the BSK public key. Certificate-based authentication of the knows the BSK public key. Certificate-based authentication of the
client to the server using the BSK gives the server proof that 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 client knows the BSK private key. This satisfies the proof of
ownership requirements outlined in Section 1. ownership requirements outlined in Section 1.
3.1. External PSK Derivation 3.1. EPSK Derivation
An [RFC9258] EPSK is made up of the tuple of (Base Key, External An EPSK [RFC9258] is made up of the tuple of (Base Key, External
Identity, Hash). The Base Key is the DER-encoded ASN.1 Identity, Hash). The Base Key is the DER-encoded ASN.1
subjectPublicKeyInfo representation of the BSK public key. Zero byte subjectPublicKeyInfo representation of the BSK public key. Zero-byte
padding MUST NOT be added to the DER-encoded representation of the padding MUST NOT be added to the DER-encoded representation of the
BSK public key. BSK public key.
The External Identity is derived from the DER-encoded representation The External Identity is derived from the DER-encoded representation
of the BSK public key using [RFC5869] with the SHA-256 hash algorithm of the BSK public key using [RFC5869] with the SHA-256 hash algorithm
[sha2] as follows: [SHA2] as follows:
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
SHA-256 MUST be used when deriving epskid using [RFC5869]. SHA-256 MUST be used when deriving epskid using [RFC5869].
The [RFC9258] ImportedIdentity structure is defined as: The ImportedIdentity structure [RFC9258] is defined as:
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;
and is created using the following values: and is created using the following values:
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 RFC9258>
The ImportedIdentity context value MUST be "tls13-bsk". This informs The ImportedIdentity context value MUST be "tls13-bsk". This informs
the server that the mechanisms specified in this document for the server that the mechanisms specified in this document for
deriving the EPSK and executing the TLS handshake MUST be used. The deriving the EPSK and executing the TLS handshake MUST be used. The
EPSK and ImportedIdentity are used in the TLS handshake as specified EPSK and ImportedIdentity are used in the TLS handshake as specified
in [RFC9258]. Multiple ImportedIdentity values may be imported as in [RFC9258]. Multiple ImportedIdentity values may be imported as
per [RFC9258] section 5.1. The target_kdf follows [RFC9258] and per Section 5.1 of [RFC9258]. The target_kdf follows [RFC9258] and
aligns with the cipher suite hash algorithms advertised in the TLS aligns with the cipher suite hash algorithms advertised in the TLS
1.3 handshake between the device and the server. 1.3 handshake between the device and the server.
A server can choose a tradeoff between performance and storage by A server can choose a trade-off between performance and storage by
precomputing the identity of every bootstrapped key with every hash precomputing the identity of every bootstrapped key with every hash
algorithm that it uses in TLS and use that to quickly lookup the algorithm that it uses in TLS and use that to quickly lookup the
bootstrap key and generate the PSK. Servers that choose not to bootstrap key and generate the PSK. Servers that choose not to
employ this optimization will have to do a runtime check with every employ this optimization will have to do a runtime check with every
bootstrap key it holds against the identity the client provides. bootstrap key it holds against the identity the client provides.
Test vectors for derivation of an EPSK External Identity from a BSK Test vectors for derivation of an EPSK External Identity from a BSK
are given in the appendix. are given in the appendix.
3.2. TLS 1.3 Handshake Details 3.2. TLS 1.3 Handshake Details
The client includes the "tls_cert_with_extern_psk" extension in the The client includes the "tls_cert_with_extern_psk" extension in the
ClientHello, per [RFC8773]. The client identifies the BSK public key ClientHello, per [RFC8773]. The client identifies the BSK public key
by inserting the serialized content of ImportedIdentity into the by inserting the serialized content of ImportedIdentity into the
PskIdentity.identity in the PSK extension, per [RFC9258]. The client PskIdentity.identity in the PSK extension, per [RFC9258]. The client
MUST also include the [RFC7250] "client_certificate_type" extension MUST also include the "client_certificate_type" extension per
in the ClientHello and MUST specify type of RawPublicKey. [RFC7250] in the ClientHello and MUST specify type of RawPublicKey.
Upon receipt of the ClientHello, the server looks up the client's Upon receipt of the ClientHello, the server looks up the client's
EPSK key in its database using the mechanisms documented in EPSK key in its database using the mechanisms documented in
[RFC9258]. If no match is found, the server MUST terminate the TLS [RFC9258]. If no match is found, the server MUST terminate the TLS
handshake with an alert. If the server finds the matching BSK public handshake with an alert. If the server finds the matching BSK public
key, it includes the "tls_cert_with_extern_psk" extension in the key, it includes the "tls_cert_with_extern_psk" extension in the
ServerHello message, and the corresponding EPSK identity in the ServerHello message and the corresponding EPSK identity in the
"pre_shared_key" extension. When these extensions have been "pre_shared_key" extension. When these extensions have been
successfully negotiated, the TLS 1.3 key schedule MUST include both successfully negotiated, the TLS 1.3 key schedule MUST include both
the EPSK in the Early Secret derivation and an (EC)DHE shared secret the EPSK in the Early Secret derivation and a Diffie-Hellman
value in the Handshake Secret derivation. Ephemeral (DHE) or ECDHE shared secret value in the Handshake Secret
derivation.
After successful negotiation of these extensions, the full TLS 1.3 After successful negotiation of these extensions, the full TLS 1.3
handshake is performed with the additional caveat that the server handshake is performed with the additional caveat that the server
MUST send a CertificateRequest message and the client MUST MUST send a CertificateRequest message and the client MUST
authenticate with a raw public key (its BSK) per [RFC7250]. The BSK authenticate with a raw public key (its BSK) per [RFC7250]. The BSK
is always an elliptic curve key pair, therefore the type of the is always an EC key pair; therefore, the type of the client's
client's Certificate MUST be ECDSA and MUST contain the client's BSK Certificate MUST be ECDSA and MUST contain the client's BSK public
public key as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE. key as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE.
Note that the client MUST NOT share its BSK public key with the Note that the client MUST NOT share its BSK public key with the
server until after the client has completed processing of the server until after the client has completed processing of the
ServerHello and verified the TLS key schedule. The PSK proof is ServerHello and verified the TLS key schedule. The PSK proof is
completed at this stage, and the server has proven to the client that completed at this stage, and the server has proven to the client that
it knows the BSK public key, and it is therefore safe for the client it knows the BSK public key, and it is therefore safe for the client
to send the BSK public key to the server in the Certificate message. to send the BSK public key to the server in the Certificate message.
If the PSK verification step fails when processing the ServerHello, If the PSK verification step fails when processing the ServerHello,
the client terminates the TLS handshake and the BSK public key MUST the client terminates the TLS handshake and the BSK public key MUST
NOT be shared with the server. NOT be shared with the server.
When the server processes the client's Certificate, it MUST ensure When the server processes the client's Certificate, it MUST ensure
that it is identical to the BSK public key that it used to generate that it is identical to the BSK public key that it used to generate
the EPSK and ImportedIdentity for this handshake. the EPSK and ImportedIdentity for this handshake.
When clients are configured to trust the first network which proves When clients are configured to trust the first network that proves
possession of their public key (as in [duckling]), they MAY forgo the possession of their public key (as in [DUCKLING]), they MAY forgo the
checking of the server's certificate in the CertificateVerify and checking of the server's certificate in the CertificateVerify and
rely on the integrity of the bootstrapping method employed to rely on the integrity of the bootstrapping method employed to
distribute its key in order to validate trust in the authenticated distribute its key in order to validate trust in the authenticated
TLS connection. TLS connection.
The handshake is shown in Figure 1. The handshake is shown in Figure 1.
Client Server Client Server
-------- -------- -------- --------
ClientHello ClientHello
skipping to change at page 10, line 11 skipping to change at line 414
{Finished} --------> {Finished} -------->
Figure 1: TLS 1.3 TLS-POK Handshake Figure 1: TLS 1.3 TLS-POK Handshake
4. Using TLS Bootstrapping in EAP 4. Using TLS Bootstrapping in EAP
Upon "link up", an Authenticator on an 802.1X-protected port will Upon "link up", an Authenticator on an 802.1X-protected port will
issue an EAP Identity request to the newly connected peer. For issue an EAP Identity request to the newly connected peer. For
unprovisioned devices that desire to take advantage of TLS-POK, there unprovisioned devices that desire to take advantage of TLS-POK, there
is no initial realm in which to construct an NAI (see [RFC7542]). is no initial realm in which to construct an NAI (see [RFC7542]).
This document uses the NAI mechanisms defined in This document uses the NAI mechanisms defined in [RFC9965] and
[I-D.ietf-emu-eap-arpa] and defines the EAP username "tls-pok-dpp" defines the EAP username "tls-pok-dpp" for use with the TEAP realm
for use with the TEAP realm "teap.eap.arpa". The username "tls-pok- "teap.eap.arpa". The username "tls-pok-dpp" MUST be included,
dpp" MUST be included yielding an initial identity of "tls-pok- yielding an initial identity of "tls-pok-dpp@teap.eap.arpa". This
dpp@teap.eap.arpa". This identifier MUST be included in the EAP identifier MUST be included in the EAP Identity response in order to
Identity response in order to indicate to the Authenticator that TEAP indicate to the Authenticator that TEAP is the desired EAP method.
is the desired EAP method. [I-D.ietf-emu-eap-arpa] recommends how [RFC9965] recommends how the device should behave if the
the device should behave if the Authenticator does not support TEAP Authenticator does not support TEAP or TLS-POK.
or TLS-POK.
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) ->
skipping to change at page 11, line 5 skipping to change at line 446
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) ->
. .
. .
. .
Both client and server have derived the EPSK and associated [RFC9258] Figure 2: EAP Exchange Using TLS-POK
ImportedIdentity from the BSK public key as described in Section 3.1.
When the client starts the TLS exchange in the EAP transaction, it Both client and server have derived the EPSK and associated
includes the ImportedIdentity structure in the pre_shared_key ImportedIdentity [RFC9258] from the BSK public key as described in
extension in the ClientHello. When the server receives the Section 3.1. When the client starts the TLS exchange in the EAP
ClientHello, it extracts the ImportedIdentity and looks up the EPSK transaction, it includes the ImportedIdentity structure in the
and BSK public key. As previously mentioned in Section 2, the exact pre_shared_key extension in the ClientHello. When the server
mechanism by which the server has gained knowledge of or been receives the ClientHello, it extracts the ImportedIdentity and looks
provisioned with the BSK public key is outside the scope of this up the EPSK and BSK public key. As previously mentioned in
document. Section 2, the exact mechanism by which the server has gained
knowledge of or been provisioned with the BSK public key is outside
the scope of this document.
The server continues with the TLS handshake and uses the EPSK to The server continues with the TLS handshake and uses the EPSK to
prove that it knows the BSK public key. When the client replies with prove that it knows the BSK public key. When the client replies with
its Certificate, CertificateVerify and Finished messages, the server its Certificate, CertificateVerify, and Finished messages, the server
MUST ensure that the public key in the Certificate message matches MUST ensure that the public key in the Certificate message matches
the BSK public key. the BSK public key.
Once the TLS handshake completes, the client and server have Once the TLS handshake completes, the client and server have
established mutual trust. The server can then proceed to provision a established mutual trust. The server can then proceed to provision a
credential onto the client using, for example, the mechanisms credential onto the client using, for example, the mechanisms
outlined in [RFC7170]. outlined in [RFC9930].
The client can then use this provisioned credential for subsequent The client can then use this provisioned credential for subsequent
EAP authentication. The BSK is only used during bootstrap, and is EAP authentication. The BSK is only used during bootstrap and is not
not used for any subsequent EAP authentication. used for any subsequent EAP authentication.
5. IANA Considerations 5. IANA Considerations
This document adds the following to the "EAP Provisioning This document adds the following entry to the "EAP Provisioning
Identifiers" registry in the "Extensible Authentication Protocol Identifiers" registry in the "Extensible Authentication Protocol
(EAP) Registry" group. (EAP) Registry" registry group.
NAI: tls-pok-dpp@teap.eap.arpa Method Type: TEAP Reference: THIS NAI: tls-pok-dpp@teap.eap.arpa
DOCUMENT
Method-Type: TEAP
Reference: RFC 9966
6. Implementation Considerations 6. Implementation Considerations
Three key points are documented above, and are repeated here. Three key points are documented above and are repeated here.
* The subjectPublicKey contained in the ASN.1 SEQUENCE * The subjectPublicKey contained in the ASN.1 SEQUENCE
SubjectPublicKeyInfo MUST be the compressed format of the public SubjectPublicKeyInfo MUST be the compressed format of the public
key. key.
* When deriving the External PSK from the BSK, zero byte padding * When deriving the EPSK from the BSK, zero-byte padding MUST NOT be
MUST NOT be added to the DER-encoded representation of the BSK added to the DER-encoded representation of the BSK public key.
public key.
* SHA-256 MUST be used when using [RFC5869] to derive the External * SHA-256 MUST be used when following [RFC5869] to derive the EPSK
PSK from the BSK. from the BSK.
* The BSK public key MUST NOT be freely available on the network. * The BSK public key MUST NOT be freely available on the network.
7. Security Considerations 7. Security Considerations
Bootstrap and trust establishment by the TLS server is based on proof Bootstrap and trust establishment by the TLS server are based on
of knowledge of the client's bootstrap public key, a non-public proof of knowledge of the client's bootstrap public key, a non-public
datum. The TLS server obtains proof that the client knows its datum. The TLS server obtains proof that the client knows its
bootstrap public key and, in addition, also possesses its bootstrap public key and also possesses its corresponding private
corresponding private key. key.
Trust on the part of the client is based on successful completion of 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 the TLS 1.3 handshake using the EPSK derived from the BSK. This
proves to the client that the server knows its BSK public key. In proves to the client that the server knows its BSK public key. In
addition, the client assumes that knowledge of its BSK public key is addition, the client assumes that knowledge of its BSK public key is
not widely disseminated and therefore any server that proves not widely disseminated; therefore, any server that proves knowledge
knowledge of its BSK public key is the appropriate server from which of its BSK public key is the appropriate server from which to receive
to receive provisioning, for instance via [RFC7170]. [duckling] provisioning, for instance via [RFC9930]. [DUCKLING] describes a
describes a security model for this type of "imprinting". security model for this type of "imprinting".
An attack on the bootstrapping method which substitutes the public An attack on the bootstrapping method, which substitutes the public
key of a rogue device for the public key of an honest device can key of a rogue device for the public key of an honest device, can
result in the TLS server on-boarding and trusting the rogue device. result in the TLS server onboarding and trusting the rogue device.
If an adversary has knowledge of the bootstrap public key, the If an adversary has knowledge of the bootstrap public key, the
adversary may be able to make the client bootstrap against the adversary may be able to make the client bootstrap against the
adversary's network. For example, if an adversary intercepts and adversary's network. For example, if an adversary intercepts and
scans QR labels on clients, and the adversary can force the client to scans QR labels on clients, and the adversary can force the client to
connect to its server, then the adversary can complete the TLS-POK connect to its server, then the adversary can complete the TLS-POK
handshake with the client and the client will connect to the handshake with the client and the client will connect to the
adversary's server. Since physical possession implies ownership, adversary's server. Since physical possession implies ownership,
there is nothing to prevent a stolen device from being on-boarded. there is nothing to prevent a stolen device from being onboarded.
The BSK keypair used for ECDSA MUST be generated and validated The BSK key pair used for ECDSA MUST be generated and validated
according to section 6.2 of [NIST.FIPS.186-5]. according to Section 6.2 of [NIST.FIPS.186-5].
Manufacturers SHOULD use a unique BSK for every single device they Manufacturers SHOULD use a unique BSK for every single device they
manufacture. If multiple devices share the same BSK, then network manufacture. If multiple devices share the same BSK, then network
operators cannot differentiate between these devices, and cannot operators cannot differentiate between these devices and cannot
ensure that only specific authorized devices are allowed connect to ensure that only specific authorized devices are allowed connect to
their networks. their networks.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-emu-eap-arpa]
DeKok, A., "The eap.arpa. domain and EAP provisioning",
Work in Progress, Internet-Draft, draft-ietf-emu-eap-arpa-
10, 4 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
arpa-10>.
[NIST.FIPS.186-5] [NIST.FIPS.186-5]
Moody, D. and National Institute of Standards and NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
Technology, "Digital Signature Standard (DSS)", NIST DOI 10.6028/NIST.FIPS.186-5, February 2023,
Federal Information Processing Standards
Publications 186-5, DOI 10.6028/NIST.FIPS.186-5, 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-5.pdf>. NIST.FIPS.186-5.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/rfc/rfc5480>. <https://www.rfc-editor.org/info/rfc5480>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773, Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020, DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/rfc/rfc8773>. <https://www.rfc-editor.org/info/rfc8773>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre- [RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258, Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022, DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/rfc/rfc9258>. <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, April 2026,
<https://www.rfc-editor.org/info/rfc9965>.
8.2. Informative References 8.2. Informative References
[DPP] Wi-Fi Alliance, "Device Provisioning Profile", 2020. [DPP] Wi-Fi Alliance, "Device Provisioning Profile", 2020.
[duckling] Stajano, F. and R. Anderson, "The Resurrecting Duckling: [DUCKLING] Stajano, F. and R. Anderson, "The Resurrecting Duckling:
Security Issues for Ad-Hoc Wireless Networks", 1999, 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- <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
duckling.pdf>. duckling.pdf>.
[IEEE802.1X] [IEEE802.1X]
IEEE, "Port-Based Network Access Control", 2010. IEEE, "IEEE Standard for Local and metropolitan area
networks--Port-Based Network Access Control", IEEE Std
802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, 2010,
<https://ieeexplore.ieee.org/document/5409813>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/rfc/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/rfc/rfc7170>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/rfc/rfc7542>. <https://www.rfc-editor.org/info/rfc7542>.
[sha2] National Institute of Standards and Technology, "FIPS [RFC9930] DeKok, A., Ed., "Tunnel Extensible Authentication Protocol
180-4 Secure Hash Standard (SHS)", August 2015, (TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930,
<https://doi.org/10.6028/NIST.FIPS.180-4>. 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 Appendix A. Test Vectors
A.1. Test Vector 1: prime256v1 A.1. Test Vector 1: prime256v1
Base64 encoding of BSK: Base64 encoding of BSK:
MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxp MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxpEC6KITLb9g=
EC6KITLb9g=
Base64 encoding of epskid: Base64 encoding of epskid:
Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA= Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=
A.2. Test Vector 2: secp384r1 A.2. Test Vector 2: secp384r1
Base64 encoding of BSK: Base64 encoding of BSK:
MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZK MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZKilryZRDfNioq7+EPquT6l9laRvw
ilryZRDfNioq7+EPquT6l9laRvw
Base64 encoding of epskid: Base64 encoding of epskid:
yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w= yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=
A.3. Test Vector 3: secp521r1 A.3. Test Vector 3: secp521r1
Base64 encoding of BSK: Base64 encoding of BSK:
MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZ MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD
UvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQ
YFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HD
QfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD
Base64 encoding of epskid: Base64 encoding of epskid:
D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8= D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=
A.4. Test Vector 4: brainpoolP256r1 A.4. Test Vector 4: brainpoolP256r1
Base64 encoding of BSK: Base64 encoding of BSK:
MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/ MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/
 End of changes. 85 change blocks. 
260 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48.