rfc9966v1.txt		rfc9966.txt
	Internet Engineering Task Force (IETF) O. Friel		Internet Engineering Task Force (IETF) O. Friel
	Request for Comments: 9966 Cisco		Request for Comments: 9966 Cisco
	Category: Standards Track D. Harkins		Category: Standards Track D. Harkins
	ISSN: 2070-1721 Hewlett-Packard Enterprise		ISSN: 2070-1721 Hewlett-Packard Enterprise
	April 2026		May 2026
	Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)		Bootstrapped TLS Authentication with Proof of Knowledge
	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; this mechanism		Bootstrapping devices have a public/private key pair; this mechanism
	enables a TLS server to prove to the device that it knows the public		enables a TLS server to prove to the device that it knows the public
	key and enables the device to prove to the TLS server that it knows		key and enables the device to prove to the TLS server that it 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 Profile (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 is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	skipping to change at line 80 ¶		skipping to change at line 80 ¶
	A.1. Test Vector 1: prime256v1		A.1. Test Vector 1: prime256v1
	A.2. Test Vector 2: secp384r1		A.2. Test Vector 2: secp384r1
	A.3. Test Vector 3: secp521r1		A.3. Test Vector 3: secp521r1
	A.4. Test Vector 4: brainpoolP256r1		A.4. Test Vector 4: brainpoolP256r1
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	Onboarding 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 a network		difficult. Sometimes a credential is needed to access a network
	based on [IEEE802.1X] or EAP, and network connectivity is needed to		based on [IEEE8802.1x] or EAP, and network connectivity is needed to
	obtain a credential. This poses a challenge for onboarding devices.		obtain a credential. This poses a challenge for onboarding devices.
	If a device has a public/private key pair, and trust in the integrity		If a device has a public/private key pair, and trust in the integrity
	of a device's public key can be obtained in an out-of-band fashion, a		of a device's public key can be obtained in an out-of-band fashion, a
	device can be authenticated and provisioned with a usable credential		device can be authenticated and provisioned with a usable credential
	for [IEEE802.1X] / EAP-based network access. While this		for [IEEE8802.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 onboarding 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. For instance, [DPP] 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 key pair 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		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 wired		authentication protocol can be used in an EAP exchange for wired
	network access as described in [IEEE802.1X]. This protocol is called		network access as described in [IEEE8802.1x]. This protocol is
	"TLS Proof of Knowledge" or "TLS-POK".		called "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 [IEEE802.1X] ethernet port, but TLS-POK will. Therefore,		on a wired [IEEE8802.1x] ethernet port, but TLS-POK will. Therefore,
	TLS-POK SHOULD NOT be used for bootstrapping against wireless		TLS-POK SHOULD NOT be used for bootstrapping against wireless
	networks 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 [IEEE802.1X]		802.1X: IEEE Port-Based Network Access Control [IEEE8802.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]		DPP: Device Provisioning Profile [DPP]
	EAP: Extensible Authentication Protocol [RFC3748]		EAP: Extensible Authentication Protocol [RFC3748]
	EC: Elliptic Curve		EC: Elliptic Curve
	ECDSA: Elliptic Curve Digital Signature Algorithm		ECDSA: Elliptic Curve Digital Signature Algorithm
	EPSK: External Pre-Shared Key		EPSK: External Pre-Shared Key
	EST: Enrollment over Secure Transport [RFC7030]		EST: Enrollment over Secure Transport [RFC7030]
	NAI: Network Access Identifier		NAI: Network Access Identifier
	PSK: Pre-Shared Key		PSK: Pre-Shared Key
	TEAP: Tunnel Extensible Authentication Protocol [RFC9930]		TEAP: Tunnel Extensible Authentication Protocol [RFC9930]
	1.2. Bootstrapping Overview		1.2. Bootstrapping Overview
	skipping to change at line 150 ¶		skipping to change at line 150 ¶
	* known by the device,		* known by the device,
	* known by the owner or holder of the device, and		* known by the owner or holder of the device, and
	* provisioned on the TLS server by the TLS server operator.		* provisioned on the TLS server by the TLS server operator.
	In order to establish trust and mutually authenticate, the TLS server		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		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 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 BSK. More details on the BSK are given in Section 2.
	The TLS server could be an EAP server for [IEEE802.1X] network access		The TLS server could be an EAP server for 802.1X network access or
	or could, for example, be an Enrollment over Secure Transport (EST)		could, for example, be an Enrollment over Secure Transport (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 802.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
	IEEE 802.1X / EAP. This creates a problem for bootstrapping devices		802.1X / EAP. This creates a problem for bootstrapping devices where
	where a certificate is needed for EAP authentication and 802.1X		a certificate is needed for EAP authentication and 802.1X network
	network access is needed to obtain a certificate.		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 authenticate with the
	exchange, for instance Tunnel Extensible Authentication Protocol		EAP server using the mechanism defined in Sections 3 and 4. This
	(TEAP) [RFC9930], and authenticate the TLS exchange using the		network connectivity can then be used to perform an enrollment
	authentication mechanisms defined in Section 3. This network		protocol (such as provided by [RFC9930]) to obtain a credential for
	connectivity can then be used to perform an enrollment protocol (such		subsequent EAP authentication. Certificate lifecycle management may
	as provided by [RFC9930]) to obtain a credential for subsequent EAP		also be performed in subsequent TEAP transactions.
	authentication. Certificate lifecycle management may also be
	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		device is TEAP; therefore, this document assumes that TEAP is the
	only supported EAP method. Section 4 describes how TLS-POK is used		only supported EAP method. Section 4 describes how TLS-POK is used
	skipping to change at line 222 ¶		skipping to change at line 220 ¶
	of a Bill of Materials (BOM) that 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 BSK public
	public key corresponding to a specific device.		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 BSK can		or dynamically display a single QR code on a display, and the BSK can
	be used for DPP if the device bootstraps against a Wi-Fi network or		be used for DPP if the device bootstraps against a Wi-Fi network or
	TLS-POK if the device bootstraps against a wired network. Similarly,		TLS-POK if the device bootstraps against a wired network. Similarly,
	a common bootstrap public key format could be imported into a BOM		a common BSK public key format could be imported into a BOM into a
	into a server that handles devices connecting over both wired and Wi-		server that handles devices connecting over both wired and Wi-Fi
	Fi networks.		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
	postquantum 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 postquantum crypto systems, this document		in the future to support postquantum crypto systems, this document
	will 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.
	skipping to change at line 312 ¶		skipping to change at line 310 ¶
	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 RFC 9258>
	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 Section 5.1 of [RFC9258]. 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.
	skipping to change at line 343 ¶		skipping to change at line 341 ¶
	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 "client_certificate_type" extension per		MUST also include the "client_certificate_type" extension per
	[RFC7250] 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 in its database using the mechanisms documented in [RFC9258].
	[RFC9258]. If no match is found, the server MUST terminate the TLS		If no match is found, the server MUST terminate the TLS handshake
	handshake with an alert. If the server finds the matching BSK public		with an alert. If the server finds the matching BSK public key, it
	key, it includes the "tls_cert_with_extern_psk" extension in the		includes the "tls_cert_with_extern_psk" extension in the ServerHello
	ServerHello message and the corresponding EPSK identity in the		message and the corresponding EPSK identity in the "pre_shared_key"
	"pre_shared_key" extension. When these extensions have been		extension. When these extensions have been successfully negotiated,
	successfully negotiated, the TLS 1.3 key schedule MUST include both		the TLS 1.3 key schedule MUST include both the EPSK in the Early
	the EPSK in the Early Secret derivation and a Diffie-Hellman		Secret derivation and a Diffie-Hellman Ephemeral (DHE) or ECDHE
	Ephemeral (DHE) or ECDHE shared secret value in the Handshake Secret		shared secret value in the Handshake Secret derivation.
	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 EC key pair; therefore, the type of the client's		is always an EC key pair; therefore, the type of the client's
	Certificate MUST be ECDSA and MUST contain the client's BSK public		Certificate MUST be ECDSA and MUST contain the client's BSK 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
	skipping to change at line 482 ¶		skipping to change at line 479 ¶
	used for any subsequent EAP authentication.		used for any subsequent EAP authentication.
	5. IANA Considerations		5. IANA Considerations
	This document adds the following entry 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" registry group.		(EAP) Registry" registry group.
	NAI: tls-pok-dpp@teap.eap.arpa		NAI: tls-pok-dpp@teap.eap.arpa
	Method-Type: TEAP		Method Type: TEAP
	Reference: RFC 9966		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.
	skipping to change at line 505 ¶		skipping to change at line 502 ¶
	added to the DER-encoded representation of the BSK public key.		added to the DER-encoded representation of the BSK public key.
	* SHA-256 MUST be used when following [RFC5869] to derive the EPSK		* SHA-256 MUST be used when following [RFC5869] to derive the EPSK
	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 are based on		Bootstrap and trust establishment by the TLS server are based on
	proof of knowledge of the client's bootstrap public key, a non-public		proof of knowledge of the client's BSK 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 BSK
	bootstrap public key and also possesses its corresponding private		public key and also possesses its 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; therefore, any server that proves knowledge		not widely disseminated; therefore, any server that proves knowledge
	of its BSK public key is the appropriate server from which to receive		of its BSK public key is the appropriate server from which to receive
	provisioning, for instance via [RFC9930]. [DUCKLING] describes a		provisioning, for instance via [RFC9930]. [DUCKLING] 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 onboarding 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 BSK public key, the adversary
	adversary may be able to make the client bootstrap against the		may be able to make the client bootstrap against the adversary's
	adversary's network. For example, if an adversary intercepts and		network. For example, if an adversary intercepts and scans QR labels
	scans QR labels on clients, and the adversary can force the client to		on clients, and the adversary can force the client to connect to its
	connect to its server, then the adversary can complete the TLS-POK		server, then the adversary can complete the TLS-POK handshake with
	handshake with the client and the client will connect to the		the client and the client will connect to the adversary's server.
	adversary's server. Since physical possession implies ownership,		Since physical possession implies ownership, there is nothing to
	there is nothing to prevent a stolen device from being onboarded.		prevent a stolen device from being onboarded.
	The BSK key pair 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.
	skipping to change at line 588 ¶		skipping to change at line 584 ¶
	DOI 10.17487/RFC8773, March 2020,		DOI 10.17487/RFC8773, March 2020,
	<https://www.rfc-editor.org/info/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/info/rfc9258>.		<https://www.rfc-editor.org/info/rfc9258>.
	[RFC9965] DeKok, A., "The eap.arpa. Domain and Extensible		[RFC9965] DeKok, A., "The eap.arpa. Domain and Extensible
	Authentication Protocol (EAP) Provisioning", RFC 9965,		Authentication Protocol (EAP) Provisioning", RFC 9965,
	DOI 10.17487/RFC9965, April 2026,		DOI 10.17487/RFC9965, May 2026,
	<https://www.rfc-editor.org/info/rfc9965>.		<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, "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:		[DUCKLING] Stajano, F. and R. Anderson, "The Resurrecting Duckling:
	Security Issues for Ad-Hoc Wireless Networks", Security		Security Issues for Ad-Hoc Wireless Networks", Security
	Protocols, 7th International Workshop Proceedings, Lecture		Protocols, 7th International Workshop Proceedings, Lecture
	Notes in Computer Science, vol. 1796, pp. 172-182,		Notes in Computer Science, vol. 1796, pp. 172-182,
	DOI 10.1007/10720107_24, 1999,		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]		[IEEE8802.1x]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE/ISO/IEC, "IEEE/ISO/IEC International Standard-
	networks--Port-Based Network Access Control", IEEE Std		Telecommunications and exchange between information
	802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, 2010,		technology systems--Requirements for local and
	<https://ieeexplore.ieee.org/document/5409813>.		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.		[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/info/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/info/rfc7030>.		<https://www.rfc-editor.org/info/rfc7030>.
	skipping to change at line 668 ¶		skipping to change at line 669 ¶
	MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD		MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD
	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/reuCvq8lHowtwWNOZ
	reuCvq8lHowtwWNOZ
	Base64 encoding of epskid:		Base64 encoding of epskid:
	j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=		j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=
	Authors' Addresses		Authors' Addresses
	Owen Friel		Owen Friel
	Cisco		Cisco
	Email: ofriel@cisco.com		Email: ofriel@cisco.com
End of changes. 24 change blocks.
	62 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48.