draft-ietf-netconf-sztp-csr-07.txt		draft-ietf-netconf-sztp-csr-08.txt
	NETCONF Working Group K. Watsen		NETCONF Working Group K. Watsen
	Internet-Draft Watsen Networks		Internet-Draft Watsen Networks
	Updates: 8572 (if approved) R. Housley		Updates: 8572 (if approved) R. Housley
	Intended status: Standards Track Vigil Security, LLC		Intended status: Standards Track Vigil Security, LLC
	Expires: 16 February 2022 S. Turner		Expires: 25 February 2022 S. Turner
	sn3rd		sn3rd
	15 August 2021		24 August 2021
	Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch		Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch
	Provisioning (SZTP) Bootstrapping Request		Provisioning (SZTP) Bootstrapping Request
	draft-ietf-netconf-sztp-csr-07		draft-ietf-netconf-sztp-csr-08
	Abstract		Abstract
	This draft extends the "get-bootstrapping-data" RPC defined in RFC		This draft extends the "get-bootstrapping-data" RPC defined in RFC
	8572 to include an optional certificate signing request (CSR),		8572 to include an optional certificate signing request (CSR),
	enabling a bootstrapping device to additionally obtain an identity		enabling a bootstrapping device to additionally obtain an identity
	certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the		certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
	"onboarding information" response provided in the RPC-reply.		"onboarding information" response provided in the RPC-reply.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	* "XXXX" --> the assigned numerical RFC value for this draft		* "XXXX" --> the assigned numerical RFC value for this draft
	* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto-		* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto-
	types		types
	Artwork in this document contains a placeholder value for the		Artwork in this document contains a placeholder value for the
	publication date of this draft. Please apply the following		publication date of this draft. Please apply the following
	replacement:		replacement:
	* "2021-08-15" --> the publication date of this draft		* "2021-08-24" --> the publication date of this draft
	This document contains references to other drafts in progress, both		This document contains references to other drafts in progress, both
	in the Normative References section, as well as in body text		in the Normative References section, as well as in body text
	throughout. Please update the following references to reflect their		throughout. Please update the following references to reflect their
	final RFC assignments:		final RFC assignments:
	* I-D.ietf-netconf-crypto-types		* I-D.ietf-netconf-crypto-types
	* I-D.ietf-netconf-keystore		* I-D.ietf-netconf-keystore
	* I-D.ietf-netconf-trust-anchors		* I-D.ietf-netconf-trust-anchors
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 16 February 2022.		This Internet-Draft will expire on 25 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 27		4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27		4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27
	4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27		4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27
	4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27		4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27
	4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28		4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28
	4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28		4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28
	4.1.5. Selecting the Best Origin Authentication Mechanism . 29		4.1.5. Selecting the Best Origin Authentication Mechanism . 29
	4.1.6. Clearing the Private Key and Associated		4.1.6. Clearing the Private Key and Associated
	Certificate . . . . . . . . . . . . . . . . . . . . . 29		Certificate . . . . . . . . . . . . . . . . . . . . . 29
	4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29		4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29
	4.2.1. Conveying Proof of Possession to a CA . . . . . . . . 29		4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 29
	4.2.2. Supporting SZTP-Clients that don't trust the		4.2.2. Supporting SZTP-Clients that don't trust the
	SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30		SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30
	4.3. Security Considerations for the "ietf-sztp-csr" YANG		4.3. Security Considerations for the "ietf-sztp-csr" YANG
	Module . . . . . . . . . . . . . . . . . . . . . . . . . 30		Module . . . . . . . . . . . . . . . . . . . . . . . . . 30
	4.4. Security Considerations for the "ietf-ztp-types" YANG		4.4. Security Considerations for the "ietf-ztp-types" YANG
	Module . . . . . . . . . . . . . . . . . . . . . . . . . 30		Module . . . . . . . . . . . . . . . . . . . . . . . . . 30
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31		5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31
	5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31		5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 21 ¶
	{		{
	"ietf-sztp-bootstrap-server:input" : {		"ietf-sztp-bootstrap-server:input" : {
	"hw-model": "model-x",		"hw-model": "model-x",
	"os-name": "vendor-os",		"os-name": "vendor-os",
	"os-version": "17.3R2.1",		"os-version": "17.3R2.1",
	"nonce": "extralongbase64encodedvalue=",		"nonce": "extralongbase64encodedvalue=",
	"ietf-sztp-csr:p10-csr": "BASE64VALUE="		"ietf-sztp-csr:p10-csr": "BASE64VALUE="
	}		}
	}		}
			At this point, it is expected that the SZTP-server, perhaps in
			conjunction with other systems, such as a backend CA or RA, will
			validate the CSR's origin and proof-of-possession and, assuming the
			CSR is approved, issue a signed certificate for the bootstrapping
			device.
	The SZTP-server responds with "onboarding-information" (encoded		The SZTP-server responds with "onboarding-information" (encoded
	inside the "conveyed-information" node) containing a signed identity		inside the "conveyed-information" node, shown below) containing a
	certificate for the CSR provided by the SZTP-client:		signed identity certificate for the CSR provided by the SZTP-client:
	RESPONSE		RESPONSE
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Sat, 31 Oct 2015 17:02:40 GMT		Date: Sat, 31 Oct 2015 17:02:40 GMT
	Server: example-server		Server: example-server
	Content-Type: application/yang.data+json		Content-Type: application/yang.data+json
	{		{
	"ietf-sztp-bootstrap-server:output" : {		"ietf-sztp-bootstrap-server:output" : {
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	[I-D.ietf-netconf-trust-anchors].		[I-D.ietf-netconf-trust-anchors].
	2.3. YANG Module		2.3. YANG Module
	This module augments an RPC defined in [RFC8572]. The module uses a		This module augments an RPC defined in [RFC8572]. The module uses a
	data types and groupings defined in [RFC8572], [RFC8791], and		data types and groupings defined in [RFC8572], [RFC8791], and
	[I-D.ietf-netconf-crypto-types]. The module has additional normative		[I-D.ietf-netconf-crypto-types]. The module has additional normative
	references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015],		references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015],
	and an informative reference to [Std-802.1AR-2018].		and an informative reference to [Std-802.1AR-2018].
	<CODE BEGINS> file "ietf-sztp-csr@2021-08-15.yang"		<CODE BEGINS> file "ietf-sztp-csr@2021-08-24.yang"
	module ietf-sztp-csr {		module ietf-sztp-csr {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";		namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";
	prefix sztp-csr;		prefix sztp-csr;
	import ietf-sztp-bootstrap-server {		import ietf-sztp-bootstrap-server {
	prefix sztp-svr;		prefix sztp-svr;
	reference		reference
	"RFC 8572: Secure Zero Touch Provisioning (SZTP)";		"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
	itself for full legal notices.		itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
	'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',		'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
	'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this		'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	document are to be interpreted as described in BCP 14		document are to be interpreted as described in BCP 14
	(RFC 2119) (RFC 8174) when, and only when, they appear		(RFC 2119) (RFC 8174) when, and only when, they appear
	in all capitals, as shown here.";		in all capitals, as shown here.";
	revision 2021-08-15 {		revision 2021-08-24 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"RFC XXXX: Conveying a Certificate Signing Request (CSR)		"RFC XXXX: Conveying a Certificate Signing Request (CSR)
	in a Secure Zero Touch Provisioning (SZTP)		in a Secure Zero Touch Provisioning (SZTP)
	Bootstrapping Request";		Bootstrapping Request";
	}		}
	// Protocol-accessible nodes		// Protocol-accessible nodes
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 12 ¶
	+--:(cmp-csr)		+--:(cmp-csr)
	+-- cmp-csr? binary		+-- cmp-csr? binary
	3.2. YANG Module		3.2. YANG Module
	This module uses a data types and groupings [RFC8791] and		This module uses a data types and groupings [RFC8791] and
	[I-D.ietf-netconf-crypto-types]. The module has additional normative		[I-D.ietf-netconf-crypto-types]. The module has additional normative
	references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015],		references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015],
	and an informative reference to [Std-802.1AR-2018].		and an informative reference to [Std-802.1AR-2018].
	<CODE BEGINS> file "ietf-ztp-types@2021-08-15.yang"		<CODE BEGINS> file "ietf-ztp-types@2021-08-24.yang"
	module ietf-ztp-types {		module ietf-ztp-types {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";		namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";
	prefix zt;		prefix zt;
	import ietf-crypto-types {		import ietf-crypto-types {
	prefix ct;		prefix ct;
	reference		reference
	"RFC AAAA: YANG Data Types and Groupings for Cryptography";		"RFC AAAA: YANG Data Types and Groupings for Cryptography";
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 20 ¶
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
	itself for full legal notices.		itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
	'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',		'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
	'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this		'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	document are to be interpreted as described in BCP 14		document are to be interpreted as described in BCP 14
	(RFC 2119) (RFC 8174) when, and only when, they appear		(RFC 2119) (RFC 8174) when, and only when, they appear
	in all capitals, as shown here.";		in all capitals, as shown here.";
	revision 2021-08-15 {		revision 2021-08-24 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"RFC XXXX: Conveying a Certificate Signing Request (CSR)		"RFC XXXX: Conveying a Certificate Signing Request (CSR)
	in a Secure Zero Touch Provisioning (SZTP)		in a Secure Zero Touch Provisioning (SZTP)
	Bootstrapping Request";		Bootstrapping Request";
	}		}
	identity certificate-request-format {		identity certificate-request-format {
	description		description
	skipping to change at page 29, line 13 ¶		skipping to change at page 29, line 13 ¶
	when the SZTP-client connects to an untrusted SZTP-server.		when the SZTP-client connects to an untrusted SZTP-server.
	Consistent with the recommendation presented in Section 9.6 of		Consistent with the recommendation presented in Section 9.6 of
	[RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input		[RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input
	parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass		parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass
	instead the "signed-data-preferred" input parameter, as discussed in		instead the "signed-data-preferred" input parameter, as discussed in
	Appendix B of [RFC8572].		Appendix B of [RFC8572].
	4.1.5. Selecting the Best Origin Authentication Mechanism		4.1.5. Selecting the Best Origin Authentication Mechanism
	When generating a new key, it is important that the client be able to		A The CSR's origin SHOULD be verified before a certificate is issued.
	provide additional proof to the CA that it was the entity that
			When generating a new key, it is important that the SZTP-client be
			able to provide additional proof that it was the entity that
	generated the key.		generated the key.
	All the certificate request formats defined in this document (e.g.,		The CMP and CMC certificate request formats defined in this document
	CMC, CMP, etc.), not including a raw PKCS#10, support origin		support origin authentication. A raw PKCS#10 does not support origin
	authentication.		authentication.
	These formats support origin authentication using both PKI and shared		The CMP and CMC request formats support origin authentication using
	secret.		both PKI and shared secret.
	Typically, only one possible origin authentication mechanism can		Typically, only one possible origin authentication mechanism can
	possibly be used but, in the case that the SZTP-client authenticates		possibly be used but, in the case that the SZTP-client authenticates
	itself using both TLS-level (e.g., IDevID) and HTTP-level credentials		itself using both TLS-level (e.g., IDevID) and HTTP-level credentials
	(e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the		(e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the
	SZTP-client may need to choose between the two options.		SZTP-client may need to choose between the two options.
	In the case that the SZTP-client must choose between the asymmetric		In the case that the SZTP-client must choose between an asymmetric
	key option versus a shared secret for origin authentication, it is		key option versus a shared secret for origin authentication, it is
	RECOMMENDED that the SZTP-client choose using the asymmetric key		RECOMMENDED that the SZTP-client choose using the asymmetric key.
	option.
	4.1.6. Clearing the Private Key and Associated Certificate		4.1.6. Clearing the Private Key and Associated Certificate
	Unlike a manufacturer-generated identity certificate (e.g., IDevID),		Unlike a manufacturer-generated identity certificate (e.g., IDevID),
	the deployment-generated identity certificate (e.g., LDevID) and the		the deployment-generated identity certificate (e.g., LDevID) and the
	associated private key (assuming a new private key was generated for		associated private key (assuming a new private key was generated for
	the purpose), are considered user data and SHOULD be cleared whenever		the purpose), are considered user data and SHOULD be cleared whenever
	the SZTP-client is reset to its factory default state, such as by the		the SZTP-client is reset to its factory default state, such as by the
	"factory-reset" RPC defined in [I-D.ietf-netmod-factory-default].		"factory-reset" RPC defined in [I-D.ietf-netmod-factory-default].
	4.2. SZTP-Server Considerations		4.2. SZTP-Server Considerations
	4.2.1. Conveying Proof of Possession to a CA		4.2.1. Verifying Proof of Possession
	When the bootstrapping device's manufacturer-generated private key		When the bootstrapping device's manufacturer-generated private key
	(e.g., the IDevID key) is reused, a CA may validate that the CSR was		(e.g., the IDevID key) is reused for the CSR, proof-of-possession is
	signed by that key.		verified by ensuring the CSR was signed by that key.
	Both the CMP and CMC formats entail the bootstrapping device signing		When a new asymmetric key is used, proof-of-possession may be
	the request once with its (e.g., LDevID) key and then again with its		verified, with the CMP or CMC formats, by ensuring the parent ASN.1
	(e.g., IDevID) key, which enables a downstream CA to be assured that		structure containing the CSR is signed by the manufacturer-generated
	the bootstrapping device possesses the public key being signed.		key.
	4.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server		4.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server
	[RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers,		[RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers,
	by blindly authenticating the SZTP-server's TLS end-entity		by blindly authenticating the SZTP-server's TLS end-entity
	certificate.		certificate.
	As is recommended in Section 4.1.4 in this document, in such cases,		As is recommended in Section 4.1.4 in this document, in such cases,
	SZTP-clients SHOULD pass the "signed-data-preferred" input parameter.		SZTP-clients SHOULD pass the "signed-data-preferred" input parameter.
End of changes. 20 change blocks.
	28 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/