< draft-ietf-netconf-sztp-csr-11.txt   draft-ietf-netconf-sztp-csr-12.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: 12 May 2022 S. Turner Expires: 6 June 2022 S. Turner
sn3rd sn3rd
8 November 2021 3 December 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-11 draft-ietf-netconf-sztp-csr-12
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)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document. Editor instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
* 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-types * AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-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-11-08 --> the publication date of this draft * 2021-12-03 --> 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 12 May 2022. This Internet-Draft will expire on 6 June 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14
3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17
3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 28
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 . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . 30
4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30
4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30
4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30
4.2.3. Supporting SZTP-Clients that don't trust the 4.2.3. Supporting SZTP-Clients that don't trust the
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31
4.3. Security Considerations for the "ietf-sztp-csr" YANG 4.3. Security Considerations for the "ietf-sztp-csr" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Security Considerations for the "ietf-ztp-types" YANG 4.4. Security Considerations for the "ietf-ztp-types" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . 32
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Normative References . . . . . . . . . . . . . . . . . . 32 6.1. Normative References . . . . . . . . . . . . . . . . . . 32
6.2. Informative References . . . . . . . . . . . . . . . . . 33 6.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This draft extends the "get-bootstrapping-data" RPC defined in This draft extends the "get-bootstrapping-data" RPC defined in
[RFC8572] to include an optional certificate signing request (CSR) [RFC8572] to include an optional certificate signing request (CSR)
[RFC2986], enabling a bootstrapping device to additionally obtain an [RFC2986], enabling a bootstrapping device to additionally obtain an
identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of
the "onboarding information" response provided in the RPC-reply. the "onboarding information" response provided in the RPC-reply.
The ability to provision an identity certificate that is purpose- The ability to provision an identity certificate that is purpose-
built for a production environment during the bootstrapping process built for a production environment during the bootstrapping process
removes reliance on the manufacturer CA, and it also enables the removes reliance on the manufacturer CA, and it also enables the
bootstraped device to join the production environment with an bootstrapped device to join the production environment with an
appropriate identity and other attributes in its LDevID certificate. appropriate identity and other attributes in its identity certificate
(e.g., an LDevID).
Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module
defines three YANG groupings for the various messages defined in this defines three YANG groupings for the various messages defined in this
document. The "ietf-sztp-csr" module augments two groupings into the document. The "ietf-sztp-csr" module augments two groupings into the
"get-bootstrapping-data" RPC and defines a YANG Data Structure "get-bootstrapping-data" RPC and defines a YANG Data Structure
[RFC8791] around the third grouping. [RFC8791] around the third grouping.
1.2. Terminology 1.2. Terminology
This document uses the following terms from [RFC8572]: This document uses the following terms from [RFC8572]:
skipping to change at page 8, line 30 skipping to change at page 8, line 30
| +--ro format-identifier identityref | +--ro format-identifier identityref
+--ro cert-req-info? ct:csr-info +--ro cert-req-info? ct:csr-info
2.2. Example Usage 2.2. Example Usage
| The examples below are encoded using JSON, but they could | The examples below are encoded using JSON, but they could
| equally well be encoded using XML, as is supported by SZTP. | equally well be encoded using XML, as is supported by SZTP.
An SZTP-client implementing this specification would signal to the An SZTP-client implementing this specification would signal to the
bootstrap server its willingness to generate a CSR by including the bootstrap server its willingness to generate a CSR by including the
"csr-support" node in its "get-bootstrapping-data" RPC, as "csr-support" node in its "get-bootstrapping-data" RPC. In the
illustrated below. example below, the SZTP-client additionally indicates that it is able
to generate keys and provides a list of key algorithms it supports,
as well as provide a list of certificate formats it supports.
REQUEST REQUEST
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1 ng-data HTTP/1.1
HOST: example.com HOST: example.com
Content-Type: application/yang.data+json Content-Type: application/yang.data+json
{ {
skipping to change at page 9, line 41 skipping to change at page 9, line 41
"ietf-ztp-types:cmc-csr", "ietf-ztp-types:cmc-csr",
"ietf-ztp-types:cmp-csr" "ietf-ztp-types:cmp-csr"
] ]
} }
} }
} }
} }
} }
Assuming the SZTP-server wishes to prompt the SZTP-client to provide Assuming the SZTP-server wishes to prompt the SZTP-client to provide
a CSR, then it would respond with an HTTP 400 Bad Request error code: a CSR, then it would respond with an HTTP 400 Bad Request error code.
In the example below, the SZTP-server specifies that it wishes the
SZTP-client to generate a key using a specific algorithm and generate
a P10-based CSR containing specific content.
RESPONSE RESPONSE
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
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-restconf:errors" : { "ietf-restconf:errors" : {
"error" : [ "error" : [
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-11-08.yang" <CODE BEGINS> file "ietf-sztp-csr@2021-12-03.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-11-08 { revision 2021-12-03 {
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-11-08.yang" <CODE BEGINS> file "ietf-ztp-types@2021-12-03.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 18, line 41 skipping to change at page 18, line 41
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Russ Housley <mailto:housley@vigilsec.com> Russ Housley <mailto:housley@vigilsec.com>
Sean Turner <mailto:sean@sn3rd.com>"; Sean Turner <mailto:sean@sn3rd.com>";
description description
"This module defines three groupings that enable "This module defines three groupings that enable
bootstrapping devices to 1) indicate if and how they bootstrapping devices to 1) indicate if and how they
support generating CSRs, 2) obtain a request to support generating CSRs, 2) obtain a request to
generate a CSR, and 3) communicate the requested CSR. generate a CSR, and 3) communicate the requested CSR.
The terms 'IDevID' and 'LDevID' are used herein to
mean 'initial device identifier' and 'local device
identifer'. These terms are defined consistent with
the IEEE 802.1AR specification, though there is no
requirement that a ZTP-client's identity certificate
conform to IEEE 802.1AR.
Copyright (c) 2021 IETF Trust and the persons identified Copyright (c) 2021 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
skipping to change at page 19, line 20 skipping to change at page 19, line 13
(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-11-08 { revision 2021-12-03 {
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 23, line 4 skipping to change at page 22, line 44
leaf format-identifier { leaf format-identifier {
type identityref { type identityref {
base zt:certificate-request-format; base zt:certificate-request-format;
} }
mandatory true; mandatory true;
description description
"A certificate request format to be used by the "A certificate request format to be used by the
ZTP-client."; ZTP-client.";
} }
} }
} }
leaf cert-req-info { leaf cert-req-info {
type ct:csr-info; type ct:csr-info;
description description
"A CertificationRequestInfo structure, as defined in "A CertificationRequestInfo structure, as defined in
RFC 2986, and modeled via a 'typedef' statement by RFC 2986, and modeled via a 'typedef' statement by
RFC AAAA. RFC AAAA.
Enables the ZTP-server to provide a fully-populated Enables the ZTP-server to provide a fully-populated
CertificationRequestInfo structure that the ZTP-client CertificationRequestInfo structure that the ZTP-client
only needs to sign in order to generate the complete only needs to sign in order to generate the complete
'CertificationRequest' structure to send to ZTP-server 'CertificationRequest' structure to send to ZTP-server
in its next 'get-bootstrapping-data' request message. in its next 'get-bootstrapping-data' request message.
When provided, the ZTP-client SHOULD use this When provided, the ZTP-client SHOULD use this structure
structure to generate its CSR; failure to do so MAY to generate its CSR; failure to do so MAY result in a
result in a 400 Bad Request response containing 400 Bad Request response containing another 'csr-request'
another 'csr-request' structure. structure.
When not provided, the ZTP-client SHOULD generate a When not provided, the ZTP-client SHOULD generate a CSR
CSR using the same structure defined in its existing using the same structure defined in its existing identity
identity certificate (e.g., IDevID). certificate (e.g., an IDevID from IEEE 802.1AR).
If the 'AlgorithmIdentifier' field contained inside the
certificate 'SubjectPublicKeyInfo' field does not match
the algorithm identified by the 'selected-algorithm' node,
then the client MUST reject the certificate and raise an
error.";
It is an error if the 'AlgorithmIdentifier' field
contained inside the 'SubjectPublicKeyInfo' field
does not match the algorithm identified by the
'selected-algorithm' node.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
RFC AAAA: RFC AAAA:
YANG Data Types and Groupings for Cryptography"; YANG Data Types and Groupings for Cryptography";
} }
} }
grouping csr-grouping { grouping csr-grouping {
description description
skipping to change at page 24, line 9 skipping to change at page 23, line 52
mandatory true; mandatory true;
description description
"A choice amongst certificate signing request formats. "A choice amongst certificate signing request formats.
Additional formats MAY be augmented into this 'choice' Additional formats MAY be augmented into this 'choice'
statement by future efforts."; statement by future efforts.";
case p10-csr { case p10-csr {
leaf p10-csr { leaf p10-csr {
type ct:csr; type ct:csr;
description description
"A CertificationRequest structure, per RFC 2986."; "A CertificationRequest structure, per RFC 2986.
Encoding details are defined in the 'ct:csr'
typedef defined in RFC AAAA.
A raw P10 does not support origin authentication in
the CSR structure. External origin authentication
may be provided via the ZTP-client's authentication
to the ZTP-server at the transport layer (e.g., TLS).";
reference reference
"RFC 2986: PKCS #10: Certification "RFC 2986: PKCS #10: Certification Request Syntax
Request Syntax Specification"; Specification
RFC AAAA: YANG Data Types and Groupings for
Cryptography";
} }
} }
case cmc-csr { case cmc-csr {
leaf cmc-csr { leaf cmc-csr {
type binary; type binary;
description description
"A constrained version of the 'Full PKI Request' "A constrained version of the 'Full PKI Request'
message defined in RFC 5272, encoded using ASN.1 message defined in RFC 5272, encoded using ASN.1
distinguished encoding rules (DER), as specified distinguished encoding rules (DER), as specified
in ITU-T X.690. in ITU-T X.690.
For asymmetric key-based origin authentication of For asymmetric key-based origin authentication of a
a CSR based on the IDevID's private key for the CSR based on the initial device identity certificate's
associated IDevID's public key, the PKIData private key for the associated identity certificate's
contains one reqSequence element and no cmsSequence public key, the PKIData contains one reqSequence
or otherMsgSequence elements. The reqSequence is element and no cmsSequence or otherMsgSequence
the TaggedRequest and it is the tcr CHOICE. The elements. The reqSequence is the TaggedRequest and it
tcr is the TaggedCertificationRequest and it a is the tcr CHOICE. The tcr is the
bodyPartId and the certificateRequest elements. TaggedCertificationRequest and it a bodyPartId and the
The certificateRequest is signed with the IDevID's certificateRequest elements. The certificateRequest
private key. The IDevID certificate and optionally is signed with the initial device identity
its certificate chain is included in the SignedData certificate's private key. The initial device identity
certificates that encapsulates the PKIData. certificate and optionally its certificate chain is
included in the SignedData certificates that
encapsulates the PKIData.
For asymmetric key-based origin authentication For asymmetric key-based origin authentication based on
based on the IDevID's private key that signs the the initial device identity certificate's private key
encapsulated CSR signed by the LDevID's private key, that signs the encapsulated CSR signed by the local
the PKIData contains one cmsSequence element and no device identity certificate's private key, the PKIData
contains one cmsSequence element and no
otherMsgSequence element. The cmsSequence is the otherMsgSequence element. The cmsSequence is the
TaggedContentInfo and it includes a bodyPartID TaggedContentInfo and it includes a bodyPartID element
element and a contentInfo. The contentInfo is and a contentInfo. The contentInfo is a SignedData
a SignedData encapsulating a PKIData with one encapsulating a PKIData with one reqSequence element
reqSequence element and no cmsSequence or and no cmsSequence or otherMsgSequence elements. The
otherMsgSequence elements. The reqSequence is reqSequence is the TaggedRequest and it is the tcr
the TaggedRequest and it is the tcr CHOICE. The CHOICE. The tcr is the TaggedCertificationRequest and
tcr is the TaggedCertificationRequest and it a it a bodyPartId and the certificateRequest elements.
bodyPartId and the certificateRequest elements. The certificateRequest is signed with the local device
The certificateRequest is signed with the LDevID's identity certificate's private key. The initial device
private key. The IDevID certificate and optionally identity certificate and optionally its certificate
its certificate chain is included in the SignedData chain is included in the SignedData certificates that
certificates that encapsulates the PKIData. encapsulates the PKIData.
For shared secret-based origin authentication of a For shared secret-based origin authentication of a
CSR signed by the LDevID's private key, the PKIData CSR signed by the local device identity certificate's
contains one cmsSequence element and no reqSequence private key, the PKIData contains one cmsSequence
or otherMsgSequence elements. The cmsSequence is element and no reqSequence or otherMsgSequence
the TaggedContentInfo and it includes a bodyPartID elements. The cmsSequence is the TaggedContentInfo
element and a contentInfo. The contentInfo is an and it includes a bodyPartID element and a contentInfo.
AuthenticatedData encapsulating a PKIData with one The contentInfo is an AuthenticatedData encapsulating
reqSequence element and no cmsSequences or a PKIData with one reqSequence element and no
otherMsgSequence elements. The reqSequence is the cmsSequences or otherMsgSequence elements. The
TaggedRequest and it is the tcr CHOICE. The tcr is reqSequence is the TaggedRequest and it is the tcr
the TaggedCertificationRequest and it a bodyPartId CHOICE. The tcr is the TaggedCertificationRequest and
and the certificateRequest elements. The it a bodyPartId and the certificateRequest elements.
certificateRequest is signed with the LDevID's The certificateRequest is signed with the local device
private key. The IDevID certificate and optionally identity certificate's private key. The initial device
its certificate chain is included in the SignedData identity certificate and optionally its certificate
certificates that encapsulates the PKIData."; chain is included in the SignedData certificates that
encapsulates the PKIData.";
reference reference
"RFC 5272: Certificate Management over CMS (CMC) "RFC 5272: Certificate Management over CMS (CMC)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER).";
} }
} }
case cmp-csr { case cmp-csr {
leaf cmp-csr { leaf cmp-csr {
type binary; type binary;
description description
"A PKIMessage structure, as defined in RFC 4210, "A PKIMessage structure, as defined in RFC 4210,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 distinguished encoding rules
(DER), as specified in ITU-T X.690. (DER), as specified in ITU-T X.690.
For asymmetric key-based origin authentication of For asymmetric key-based origin authentication of a
a CSR based on the IDevID's private key for the CSR based on the initial device identity certificate's
associated IDevID's public key, PKIMessages private key for the associated initial device identity
contains one PKIMessage with the header and body certificate's public key, PKIMessages contains one
elements, no protection element, and should contain PKIMessage with the header and body elements, no
the extraCerts element. The header element contains protection element, and should contain the extraCerts
the pvno, sender, and recipient elements. The pvno element. The header element contains the pvno, sender,
contains cmp2000, and the sender contains the and recipient elements. The pvno contains cmp2000, and
subject of the IDevID certificate. The body element the sender contains the subject of the initial device
contains a p10cr CHOICE of type CertificationRequet. identity certificate. The body element contains a p10cr
It is signed with the IDevID's private key. The CHOICE of type CertificationRequest. It is signed with
extraCerts element contains the IDevID certificate, the initial device identity certificate's private key.
optionally followed by its certificate chain The extraCerts element contains the initial device
excluding the trust anchor. identity certificate, optionally followed by its
certificate chain excluding the trust anchor.
For asymmetric key-based origin authentication For asymmetric key-based origin authentication based on
based on the IDevID's private key that signs the the initial device identity certificate's private key
encapsulated CSR signed by the LDevID's private that signs the encapsulated CSR signed by the local
key, PKIMessages contains one PKIMessage with the device identity certificate's private key, PKIMessages
header, body, and protection elements, and should contains one PKIMessage with the header, body, and
contain the extraCerts element. The header element protection elements, and should contain the extraCerts
contains the pvno, sender, recipient, protectionAlg, element. The header element contains the pvno, sender,
and optionally senderKID elements. The pvno contains recipient, protectionAlg, and optionally senderKID
cmp2000, the sender contains the subject of the elements. The pvno contains cmp2000, the sender
IDevID certificate, the protectionAlg contains the contains the subject of the initial device identity
certificate, the protectionAlg contains the
AlgorithmIdentifier of the used signature algorithm, AlgorithmIdentifier of the used signature algorithm,
and the senderKID contains the subject key and the senderKID contains the subject key identifier
identifier of the IDevID certificate. The body of the initial device identity certificate. The body
element contains a p10cr CHOICE of type element contains a p10cr CHOICE of type
CertificationRequet. It is signed with the LDevID's CertificationRequest. It is signed with the local device
private key. The protection element contains the identity certificate's private key. The protection
digital signature generated with the IDevID's element contains the digital signature generated with
private key. The extraCerts element contains the the initial device identity certificate's private key.
IDevID certificate, optionally followed by its The extraCerts element contains the initial device
identity certificate, optionally followed by its
certificate chain excluding the trust anchor. certificate chain excluding the trust anchor.
For shared secret-based origin authentication of a For shared secret-based origin authentication of a
CSR signed by the LDevID's private key, PKIMessages CSR signed by the local device identity certificate's
contains one PKIMessage with the header, body, and private key, PKIMessages contains one PKIMessage with
protection element, and no extraCerts element. The the header, body, and protection element, and no
header element contains the pvno, sender, recipient, extraCerts element. The header element contains the
protectionAlg, and senderKID elements. The pvno pvno, sender, recipient, protectionAlg, and senderKID
contains cmp2000, the protectionAlg contains the elements. The pvno contains cmp2000, the protectionAlg
AlgorithmIdentifier of the used MAC algorithm, and contains the AlgorithmIdentifier of the used MAC
the senderKID contains a reference the recipient algorithm, and the senderKID contains a reference
can use to identify the shared secret. The body the recipient can use to identify the shared secret.
element contains a p10cr CHOICE of type The body element contains a p10cr CHOICE of type
CertificationRequet. It is signed with the LDevID's CertificationRequest. It is signed with the local
private key. The protection element contains the device identity certificate's private key. The
MAC value generated with the shared secret."; protection element contains the MAC value generated
with the shared secret.";
reference reference
"RFC 4210: "RFC 4210:
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP) Certificate Management Protocol (CMP)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER).";
} }
skipping to change at page 27, line 36 skipping to change at page 27, line 46
The security of this private key is essential in order to ensure the The security of this private key is essential in order to ensure the
associated identity certificate can be used as a root of trust. associated identity certificate can be used as a root of trust.
It is RECOMMENDED that devices are manufactured with an HSM (hardware It is RECOMMENDED that devices are manufactured with an HSM (hardware
security module), such as a TPM (trusted platform module), to security module), such as a TPM (trusted platform module), to
generate and forever contain the private key within the security generate and forever contain the private key within the security
perimeter of the HSM. In such cases, the private key, and its perimeter of the HSM. In such cases, the private key, and its
associated certificates, MAY have long validity periods. associated certificates, MAY have long validity periods.
In cases where the SZTP-client does not possess an HSM, or otherwise In cases where the SZTP-client does not possess an HSM, or is unable
is unable to use an HSM for the private key, it is RECOMMENDED to to use an HSM to protect the private key, it is RECOMMENDED to
regenerate the private key (and associated identity certificates) periodically reset the private key (and associated identity
periodically. Details for how to generate a new private key and certificates) in order to minimize the lifetime of unprotected
associate a new identity certificate are outside the scope of this private keys. For instance, an NMS controller/orchestrator
document. application could periodically prompt the SZTP-client to generate a
new private key and provide a certificate signing request (CSR) or,
alternatively, push both the key and an identity certificate to the
SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example,
the SZTP-client could be configured to periodically reset the
configuration to its factory default, thus causing removal of the
private key and associated identity certificates and reexecution of
the SZTP protocol.
4.1.2. Reuse of a Manufacturer-generated Private Key 4.1.2. Reuse of a Manufacturer-generated Private Key
It is RECOMMENDED that a new private key is generated for each CSR It is RECOMMENDED that a new private key is generated for each CSR
described in this document. described in this document.
Implementations must randomly generate nonces and private keys. The
use of inadequate pseudo-random number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space.
As an example of predictable random numbers see CVE-2008-0166
[CVE-2008-0166], and some consequences of low-entropy random numbers
are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation
of quality random numbers is difficult. [ISO.20543-2019],
[NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and
others offer valuable guidance in this area.
This private key SHOULD be protected as well as the built-in private This private key SHOULD be protected as well as the built-in private
key associated with the SZTP-client's initial device identity key associated with the SZTP-client's initial device identity
certificate (e.g., the IDevID, from [Std-802.1AR-2018]). certificate (e.g., the IDevID, from [Std-802.1AR-2018]).
In cases where it is not possible to generate a new private key that In cases where it is not possible to generate a new private key that
is protected as well as the built-in private key, it is RECOMMENDED is protected as well as the built-in private key, it is RECOMMENDED
to reuse the built-in private key rather than generate a new private to reuse the built-in private key rather than generate a new private
key that is not as well protected. key that is not as well protected.
4.1.3. Replay Attack Protection 4.1.3. Replay Attack Protection
skipping to change at page 33, line 28 skipping to change at page 34, line 5
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
6.2. Informative References 6.2. Informative References
[AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI),
"Application Notes and Interpretation of the Scheme (AIS)
31 - Functionality Classes and Evaluation Methodology for
Physical Random Number Generators", 25 September 2001.
[CVE-2008-0166]
National Institute of Science and Technology (NIST),
"National Vulnerability Database - CVE-2008-0166", 13 May
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", Work in Watsen, K., "A YANG Data Model for a Keystore", Work in
Progress, Internet-Draft, draft-ietf-netconf-keystore-22, Progress, Internet-Draft, draft-ietf-netconf-keystore-22,
18 May 2021, <https://datatracker.ietf.org/doc/html/draft- 18 May 2021, <https://datatracker.ietf.org/doc/html/draft-
ietf-netconf-keystore-22>. ietf-netconf-keystore-22>.
[I-D.ietf-netconf-trust-anchors] [I-D.ietf-netconf-trust-anchors]
Watsen, K., "A YANG Data Model for a Truststore", Work in Watsen, K., "A YANG Data Model for a Truststore", Work in
Progress, Internet-Draft, draft-ietf-netconf-trust- Progress, Internet-Draft, draft-ietf-netconf-trust-
anchors-15, 18 May 2021, anchors-15, 18 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
trust-anchors-15>. trust-anchors-15>.
[I-D.ietf-netmod-factory-default] [I-D.ietf-netmod-factory-default]
Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", Work in Progress, Internet- Factory Default Settings", Work in Progress, Internet-
Draft, draft-ietf-netmod-factory-default-15, 25 April Draft, draft-ietf-netmod-factory-default-15, 25 April
2020, <https://datatracker.ietf.org/doc/html/draft-ietf- 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-
netmod-factory-default-15>. netmod-factory-default-15>.
[ISO.20543-2019]
International Organization for Standardization (ISO),
"Information technology -- Security techniques -- Test and
analysis methods for random bit generators within ISO/IEC
19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,
October 2019.
[MiningPsQs]
Security'12: Proceedings of the 21st USENIX conference on
Security symposium, Heninger, N., Durumeric, Z., Wustrow,
E., and J. A. Halderman, "Mining Your Ps and Qs: Detection
of Widespread Weak Keys in Network Devices", August 2012,
<https://www.usenix.org/conference/usenixsecurity12/
technical-sessions/presentation/heninger>.
[NIST.SP.800-90Ar1]
Barker, Elaine B. and John M. Kelsey, "Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP
800-90Ar1, June 2015,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<https://www.rfc-editor.org/info/rfc7292>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
[Std-802.1AR-2018] [Std-802.1AR-2018]
 End of changes. 41 change blocks. 
144 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/