< draft-ietf-netconf-sztp-csr-12.txt   draft-ietf-netconf-sztp-csr-13.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: 6 June 2022 S. Turner Expires: 4 August 2022 S. Turner
sn3rd sn3rd
3 December 2021 31 January 2022
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-12 draft-ietf-netconf-sztp-csr-13
Abstract Abstract
This draft extends the "get-bootstrapping-data" RPC defined in RFC This draft extends the input to the "get-bootstrapping-data" RPC
8572 to include an optional certificate signing request (CSR), defined in RFC 8572 to include an optional certificate signing
enabling a bootstrapping device to additionally obtain an identity request (CSR), enabling a bootstrapping device to additionally obtain
certificate (e.g., an LDevID from IEEE 802.1AR) as part of the an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part
"onboarding information" response provided in the RPC-reply. of the "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-12-03 --> the publication date of this draft * 2022-01-31 --> 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
* I-D.ietf-netmod-factory-default
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 6 June 2022. This Internet-Draft will expire on 4 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as extracted from this document must include Revised BSD License text 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 Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 3, line 4 skipping to change at page 2, line 50
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 . . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . 28 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 28
4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 29
4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 29 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 . 30
4.1.6. Clearing the Private Key and Associated 4.1.6. Clearing the Private Key and Associated
Certificate . . . . . . . . . . . . . . . . . . . . . 30 Certificate . . . . . . . . . . . . . . . . . . . . . 30
4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . 31
4.2.3. Supporting SZTP-Clients that don't trust the 4.2.3. Supporting SZTP-Clients that don't trust the
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31
4.3. Security Considerations for the "ietf-sztp-csr" YANG 4.3. Security Considerations for the "ietf-sztp-csr" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 32
5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Normative References . . . . . . . . . . . . . . . . . . 32 6.1. Normative References . . . . . . . . . . . . . . . . . . 32
6.2. Informative References . . . . . . . . . . . . . . . . . 33 6.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This draft extends the "get-bootstrapping-data" RPC defined in This draft extends the input to the "get-bootstrapping-data" RPC
[RFC8572] to include an optional certificate signing request (CSR) defined in [RFC8572] to include an optional certificate signing
[RFC2986], enabling a bootstrapping device to additionally obtain an request (CSR) [RFC2986], enabling a bootstrapping device to
identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of additionally obtain an identity certificate (e.g., an LDevID
the "onboarding information" response provided in the RPC-reply. [Std-802.1AR-2018]) as part of 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
bootstrapped device to join the production environment with an bootstrapped device to join the production environment with an
appropriate identity and other attributes in its identity certificate appropriate identity and other attributes in its identity certificate
(e.g., an LDevID). (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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
| +---w supported-formats | +---w supported-formats
| +---w format-identifier* identityref | +---w format-identifier* identityref
+--:(csr) +--:(csr)
+---w (csr-type) +---w (csr-type)
+--:(p10-csr) +--:(p10-csr)
| +---w p10-csr? ct:csr | +---w p10-csr? ct:csr
+--:(cmc-csr) +--:(cmc-csr)
| +---w cmc-csr? binary | +---w cmc-csr? binary
+--:(cmp-csr) +--:(cmp-csr)
+---w cmp-csr? binary +---w cmp-csr? binary
module: ietf-sztp-csr
structure: csr-request structure csr-request:
+--ro key-generation! +-- key-generation!
| +--ro selected-algorithm | +-- selected-algorithm
| +--ro algorithm-identifier binary | +-- algorithm-identifier binary
+--ro csr-generation +-- csr-generation
| +--ro selected-format | +-- selected-format
| +--ro format-identifier identityref | +-- format-identifier identityref
+--ro cert-req-info? ct:csr-info +-- cert-req-info? ct:csr-info
augment /sztp-svr:get-bootstrapping-data/sztp-svr:input:
+---w (msg-type)?
+--:(csr-support)
| +---w csr-support
| +---w key-generation!
| | +---w supported-algorithms
| | +---w algorithm-identifier* binary
| +---w csr-generation
| +---w supported-formats
| +---w format-identifier* identityref
+--:(csr)
+---w (csr-type)
+--:(p10-csr)
| +---w p10-csr? ct:csr
+--:(cmc-csr)
| +---w cmc-csr? binary
+--:(cmp-csr)
+---w cmp-csr? binary
The augmentation defines two kinds of parameters that an SZTP-client The augmentation defines two kinds of parameters that an SZTP-client
can send to an SZTP-server. The YANG structure defines one can send to an SZTP-server. The YANG structure defines one
collection of parameters that an SZTP-server can send to an SZTP- collection of parameters that an SZTP-server can send to an SZTP-
client. client.
In the order of their intended use: In the order of their intended use:
* The "csr-support" node is used by the SZTP-client to signal to the * The "csr-support" node is used by the SZTP-client to signal to the
SZTP-server that it supports the ability the generate CSRs. This SZTP-server that it supports the ability to generate CSRs. This
parameter conveys if the SZTP-client is able to generate an new parameter conveys if the SZTP-client is able to generate a new
asymmetric key and, if so, which key algorithms it supports, as asymmetric key and, if so, which key algorithms it supports, as
well as conveys what kinds of CSR structures the SZTP-client is well as conveys what kinds of CSR structures the SZTP-client is
able to generate. able to generate.
* The "csr-request" structure is used by the SZTP-server to request * The "csr-request" structure is used by the SZTP-server to request
the SZTP-client to generate a CSR. This structure is used to the SZTP-client to generate a CSR. This structure is used to
select the key algorithm the SZTP-client should use to generate a select the key algorithm the SZTP-client should use to generate a
new asymmetric key, if supported, the kind of CSR structure the new asymmetric key, if supported, the kind of CSR structure the
SZTP-client should generate and, optionally, the content for the SZTP-client should generate and, optionally, the content for the
CSR itself. CSR itself.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
module: ietf-restconf module: ietf-restconf
+--ro errors +--ro errors
+--ro error* [] +--ro error* []
+--ro error-type enumeration +--ro error-type enumeration
+--ro error-tag string +--ro error-tag string
+--ro error-app-tag? string +--ro error-app-tag? string
+--ro error-path? instance-identifier +--ro error-path? instance-identifier
+--ro error-message? string +--ro error-message? string
+--ro error-info +--ro error-info
+--ro csr-request +--ro sztp-csr:csr-request
+--ro key-generation! +--ro sztp-csr:key-generation!
| +--ro selected-algorithm | +--ro sztp-csr:selected-algorithm
| +--ro algorithm-identifier binary | +--ro sztp-csr:algorithm-identifier binary
+--ro csr-generation +--ro sztp-csr:csr-generation
| +--ro selected-format | +--ro sztp-csr:selected-format
| +--ro format-identifier identityref | +--ro sztp-csr:format-identifier identityref
+--ro cert-req-info? ct:csr-info +--ro sztp-csr: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. In the "csr-support" node in its "get-bootstrapping-data" RPC. In the
example below, the SZTP-client additionally indicates that it is able example below, the SZTP-client additionally indicates that it is able
to generate keys and provides a list of key algorithms it supports, to generate keys and provides a list of key algorithms it supports,
as well as provide a list of certificate formats 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
{ {
"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:csr-support": { "ietf-sztp-csr:csr-support": {
"key-generation": { "key-generation": {
"supported-algorithms": { "supported-algorithms": {
skipping to change at page 9, line 44 skipping to change at page 9, line 44
} }
} }
} }
} }
} }
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 In the example below, the SZTP-server specifies that it wishes the
SZTP-client to generate a key using a specific algorithm and generate SZTP-client to generate a key using a specific algorithm and generate
a P10-based CSR containing specific content. a PKCS#10-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 2021 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" : [
{ {
"error-type": "application", "error-type": "application",
"error-tag": "missing-attribute", "error-tag": "missing-attribute",
"error-message": "Missing input parameter", "error-message": "Missing input parameter",
"error-info": { "error-info": {
"ietf-sztp-csr:csr-request": { "ietf-sztp-csr:csr-request": {
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Upon being prompted to provide a CSR, the SZTP-client would POST Upon being prompted to provide a CSR, the SZTP-client would POST
another "get-bootstrapping-data" request, but this time including one another "get-bootstrapping-data" request, but this time including one
of the "csr" nodes to convey its CSR to the SZTP-server: of the "csr" nodes to convey its CSR to the SZTP-server:
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
{ {
"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="
} }
} }
skipping to change at page 11, line 34 skipping to change at page 11, line 34
CSR is approved, issue a signed certificate for the bootstrapping CSR is approved, issue a signed certificate for the bootstrapping
device. device.
The SZTP-server responds with "onboarding-information" (encoded The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node, shown below) containing a inside the "conveyed-information" node, shown below) containing a
signed identity 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 2021 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" : {
"reporting-level": "verbose", "reporting-level": "verbose",
"conveyed-information": "BASE64VALUE=" "conveyed-information": "BASE64VALUE="
} }
} }
How the signed certificate is conveyed inside the onboarding How the signed certificate is conveyed inside the onboarding
information is outside the scope of this document. Some information is outside the scope of this document. Some
implementations may choose to convey it inside a script (e.g., SZTP's implementations may choose to convey it inside a script (e.g., SZTP's
"pre-configuration-script"), while other implementations may choose "pre-configuration-script"), while other implementations may choose
to convey it inside the SZTP "configuration" node. SZTP onboarding to convey it inside the SZTP "configuration" node. SZTP onboarding
information is described in Section 2.2 of [RFC8572]. information is described in Section 2.2 of [RFC8572].
Following are two examples of conveying the signed certificate inside Below are two examples of conveying the signed certificate inside the
the "configuration" node. Both examples assume that the SZTP-client "configuration" node. Both examples assume that the SZTP-client
understands the "ietf-keystore" module defined in understands the "ietf-keystore" module defined in
[I-D.ietf-netconf-keystore]. [I-D.ietf-netconf-keystore].
This first example illustrates the case where the signed certificate This first example illustrates the case where the signed certificate
is for the same asymmetric key used by the SZTP-client's is for the same asymmetric key used by the SZTP-client's
manufacturer-generated identity certificate (e.g., an IDevID, from manufacturer-generated identity certificate (e.g., an IDevID, from
[Std-802.1AR-2018]). As such, the configuration needs to associate [Std-802.1AR-2018]). As such, the configuration needs to associate
the newly signed certificate with the existing asymmetric key: the newly signed certificate with the existing asymmetric key:
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
skipping to change at page 14, line 9 skipping to change at page 14, line 9
the device (i.e., STZP-client) can authenticate certificates the device (i.e., STZP-client) can authenticate certificates
presented by peer devices signed by the same issuer as its own. presented by peer devices signed by the same issuer as its own.
While outside the scope of this document, one way to do this would be While outside the scope of this document, one way to do this would be
to use the "ietf-truststore" module defined in to use the "ietf-truststore" module defined in
[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 also has an informative
references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], reference to [Std-802.1AR-2018].
and an informative reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2021-12-03.yang" <CODE BEGINS> file "ietf-sztp-csr@2022-01-31.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 14, line 44 skipping to change at page 14, line 43
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";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
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 augments the 'get-bootstrapping-data' RPC, "This module augments the 'get-bootstrapping-data' RPC,
defined in the 'ietf-sztp-bootstrap-server' module from defined in the 'ietf-sztp-bootstrap-server' module from
SZTP (RFC 8572), enabling the SZTP-client to obtain a SZTP (RFC 8572), enabling the SZTP-client to obtain a
signed identity certificate (e.g., an LDevID from IEEE signed identity certificate (e.g., an LDevID from IEEE
802.1AR) as part of the SZTP onboarding information 802.1AR) as part of the SZTP onboarding information
response. response.
Copyright (c) 2021 IETF Trust and the persons identified Copyright (c) 2022 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 Revised
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).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(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-12-03 { revision 2022-01-31 {
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 16, line 37 skipping to change at page 16, line 36
} }
case csr { case csr {
description description
"Provides the CSR generated by the SZTP-client. "Provides the CSR generated by the SZTP-client.
When present, the SZTP-server SHOULD respond with When present, the SZTP-server SHOULD respond with
an SZTP onboarding information message containing an SZTP onboarding information message containing
a signed certificate for the conveyed CSR. The a signed certificate for the conveyed CSR. The
SZTP-server MAY alternatively respond with another SZTP-server MAY alternatively respond with another
HTTP error containing another 'csr-request', in HTTP error containing another 'csr-request', in
which case the SZTP-client MUST invalidate the which case the SZTP-client MUST delete any key
previously generated CSR."; generated for the previously generated CSR.";
uses zt:csr-grouping; uses zt:csr-grouping;
} }
} }
} }
sx:structure csr-request { sx:structure csr-request {
description description
"A YANG data structure, per RFC 8791, that specifies "A YANG data structure, per RFC 8791, that specifies
details for the CSR that the ZTP-client is to generate."; details for the CSR that the ZTP-client is to generate.";
reference reference
skipping to change at page 17, line 6 skipping to change at page 17, line 4
sx:structure csr-request { sx:structure csr-request {
description description
"A YANG data structure, per RFC 8791, that specifies "A YANG data structure, per RFC 8791, that specifies
details for the CSR that the ZTP-client is to generate."; details for the CSR that the ZTP-client is to generate.";
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
uses zt:csr-request-grouping; uses zt:csr-request-grouping;
} }
} }
<CODE ENDS> <CODE ENDS>
3. The "ietf-ztp-types" Module 3. The "ietf-ztp-types" Module
This section defines a YANG 1.1 [RFC7950] module that defines three This section defines a YANG 1.1 [RFC7950] module that defines three
YANG groupings, one each for messages sent between a ZTP-client and YANG groupings, one each for messages sent between a ZTP-client and
ZTP-server. This module is defines independently of the "ietf-sztp- ZTP-server. This module is defined independently of the "ietf-sztp-
csr" module so that it's groupings may be used by bootstrapping csr" module so that it's groupings may be used by bootstrapping
protocols other than SZTP [RFC8572]. protocols other than SZTP [RFC8572].
3.1. Data Model Overview 3.1. Data Model Overview
The following tree diagram [RFC8340] illustrates the three groupings The following tree diagram [RFC8340] illustrates the three groupings
defined in the "ietf-ztp-types" module. defined in the "ietf-ztp-types" module.
module: ietf-ztp-types module: ietf-ztp-types
skipping to change at page 18, line 12 skipping to change at page 18, line 5
+--:(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-12-03.yang" <CODE BEGINS> file "ietf-ztp-types@2022-01-31.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";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
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.
Copyright (c) 2021 IETF Trust and the persons identified Copyright (c) 2022 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 Revised
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).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(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-12-03 { revision 2022-01-31 {
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 19, line 46 skipping to change at page 19, line 39
defined in RFC 2986."; defined in RFC 2986.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7"; Specification Version 1.7";
} }
identity cmp-csr { identity cmp-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
requests using a constrained version of the PKIMessage requests using a profiled version of the PKIMessage
containing a p10cr structure defined in RFC 4210."; that MUST contain a PKIHeader followed by a PKIBody
containing only the p10cr structure defined in
RFC 4210.";
reference reference
"RFC 4210: Internet X.509 Public Key Infrastructure "RFC 4210: Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)"; Certificate Management Protocol (CMP)";
} }
identity cmc-csr { identity cmc-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
requests using a constrained version of the 'Full requests using a profiled version of the 'Full
PKI Request' structure defined in RFC 5272."; PKI Request' structure defined in RFC 5272.";
reference reference
"RFC 5272: Certificate Management over CMS (CMC)"; "RFC 5272: Certificate Management over CMS (CMC)";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
grouping csr-support-grouping { grouping csr-support-grouping {
description description
"A grouping enabling use by other efforts."; "A grouping enabling use by other efforts.";
skipping to change at page 23, line 11 skipping to change at page 23, line 6
"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 structure When provided, the ZTP-client MUST use this structure
to generate its CSR; failure to do so MAY result in a to generate its CSR; failure to do so will result in a
400 Bad Request response containing another 'csr-request' 400 Bad Request response containing another 'csr-request'
structure. structure.
When not provided, the ZTP-client SHOULD generate a CSR When not provided, the ZTP-client SHOULD generate a CSR
using the same structure defined in its existing identity using the same structure defined in its existing identity
certificate (e.g., an IDevID from IEEE 802.1AR). certificate (e.g., an IDevID from IEEE 802.1AR).
If the 'AlgorithmIdentifier' field contained inside the If the 'AlgorithmIdentifier' field contained inside the
certificate 'SubjectPublicKeyInfo' field does not match certificate 'SubjectPublicKeyInfo' field does not match
the algorithm identified by the 'selected-algorithm' node, the algorithm identified by the 'selected-algorithm' node,
skipping to change at page 23, line 39 skipping to change at page 23, line 34
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
"Enables a ZTP-client to convey a certificate signing "Enables a ZTP-client to convey a certificate signing
request, using the encoding format selected by a request, using the encoding format selected by a
ZTP-server's 'csr-request' response to the ZTP-client's ZTP-server's 'csr-request' response to the ZTP-client's
previously sent 'get-bootstrapping-data' request previously sent request containing the 'csr-support'
containing the 'csr-support' node."; node.";
choice csr-type { choice csr-type {
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;
skipping to change at page 24, line 4 skipping to change at page 23, line 48
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' Encoding details are defined in the 'ct:csr'
typedef defined in RFC AAAA. typedef defined in RFC AAAA.
A raw P10 does not support origin authentication in A raw P10 does not support origin authentication in
the CSR structure. External origin authentication the CSR structure. External origin authentication
may be provided via the ZTP-client's authentication may be provided via the ZTP-client's authentication
to the ZTP-server at the transport layer (e.g., TLS)."; to the ZTP-server at the transport layer (e.g., TLS).";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Specification
RFC AAAA: YANG Data Types and Groupings for RFC AAAA: YANG Data Types and Groupings for
Cryptography"; 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 profiled 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 a For asymmetric key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated identity certificate's private key for the associated identity certificate's
public key, the PKIData contains one reqSequence public key, the PKIData contains one reqSequence
element and no cmsSequence or otherMsgSequence element and no cmsSequence or otherMsgSequence
elements. The reqSequence is the TaggedRequest and it elements. The reqSequence is the TaggedRequest
is the tcr CHOICE. The tcr is the and it is the tcr CHOICE branch. The tcr is the
TaggedCertificationRequest and it a bodyPartId and the TaggedCertificationRequest and it is the bodyPartId
certificateRequest elements. The certificateRequest and the certificateRequest elements. The
is signed with the initial device identity certificateRequest is signed with the initial device
certificate's private key. The initial device identity identity certificate's private key. The initial device
certificate and optionally its certificate chain is identity certificate and optionally its certificate
included in the SignedData certificates that chain is included in the SignedData certificates that
encapsulates the PKIData. encapsulates the PKIData.
For asymmetric key-based origin authentication based on For asymmetric key-based origin authentication based on
the initial device identity certificate's private key the initial device identity certificate's private key
that signs the encapsulated CSR signed by the local that signs the encapsulated CSR signed by the local
device identity certificate's private key, the PKIData device identity certificate's private key, the
contains one cmsSequence element and no PKIData contains one cmsSequence element and no
otherMsgSequence element. The cmsSequence is the reqSequence or otherMsgSequence
TaggedContentInfo and it includes a bodyPartID element elements. The cmsSequence is the TaggedContentInfo
and a contentInfo. The contentInfo is a SignedData and it includes a bodyPartID element and a contentInfo.
encapsulating a PKIData with one reqSequence element The contentInfo is a SignedData encapsulating a PKIData
and no cmsSequence or otherMsgSequence elements. The with one reqSequence element and no cmsSequence or
reqSequence is the TaggedRequest and it is the tcr otherMsgSequence elements. The reqSequence is the
CHOICE. The tcr is the TaggedCertificationRequest and TaggedRequest and it is the tcr CHOICE. The tcr is the
it a bodyPartId and the certificateRequest elements. TaggedCertificationRequest and it is the bodyPartId and
The certificateRequest is signed with the local device the certificateRequest elements. PKIData contains one
identity certificate's private key. The initial device cmsSequence element and no controlSequence, reqSequence,
identity certificate and optionally its certificate or otherMsgSequence elements. The certificateRequest
chain is included in the SignedData certificates that is signed with the local device identity certificate's
encapsulates the PKIData. private key. The initial device identity certificate
and optionally its certificate chain is included in the
SignedData certificates that encapsulates the PKIData.
For shared secret-based origin authentication of a For shared secret-based origin authentication of a
CSR signed by the local device identity certificate's CSR signed by the local device identity certificate's
private key, the PKIData contains one cmsSequence private key, the PKIData contains one cmsSequence
element and no reqSequence or otherMsgSequence element and no reqSequence or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo
and it includes a bodyPartID element and a contentInfo. and it includes a bodyPartID element and a contentInfo.
The contentInfo is an AuthenticatedData encapsulating The contentInfo is an AuthenticatedData encapsulating
a PKIData with one reqSequence element and no a PKIData with one reqSequence element and no
cmsSequences or otherMsgSequence elements. The cmsSequences or otherMsgSequence elements. The
reqSequence is the TaggedRequest and it is the tcr reqSequence is the TaggedRequest and it is the tcr
CHOICE. The tcr is the TaggedCertificationRequest and CHOICE. The tcr is the TaggedCertificationRequest
it a bodyPartId and the certificateRequest elements. and it is the bodyPartId and the certificateRequest
The certificateRequest is signed with the local device elements. The certificateRequest is signed with the
identity certificate's private key. The initial device local device identity certificate's private key. The
identity certificate and optionally its certificate initial device identity certificate and optionally its
chain is included in the SignedData certificates that certificate chain is included in the SignedData
encapsulates the PKIData."; 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 {
skipping to change at page 26, line 4 skipping to change at page 25, line 50
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 a For asymmetric key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated initial device identity private key for the associated initial device identity
certificate's public key, PKIMessages contains one certificate's public key, PKIMessages contains one
PKIMessage with the header and body elements, no PKIMessage with the header and body elements, no
protection element, and should contain the extraCerts protection element, and SHOULD contain the extraCerts
element. The header element contains the pvno, sender, element. The header element contains the pvno, sender,
and recipient elements. The pvno contains cmp2000, and and recipient elements. The pvno contains cmp2000, and
the sender contains the subject of the initial device the sender contains the subject of the initial device
identity certificate. The body element contains a p10cr identity certificate. The body element contains a p10cr
CHOICE of type CertificationRequest. It is signed with CHOICE of type CertificationRequest. It is signed with
the initial device identity certificate's private key. the initial device identity certificate's private key.
The extraCerts element contains the initial device The extraCerts element contains the initial device
identity certificate, optionally followed by its identity certificate, optionally followed by its
certificate chain excluding the trust anchor. certificate chain excluding the trust anchor.
For asymmetric key-based origin authentication based on For asymmetric key-based origin authentication based on
the initial device identity certificate's private key the initial device identity certificate's private key
that signs the encapsulated CSR signed by the local that signs the encapsulated CSR signed by the local
device identity certificate's private key, PKIMessages device identity certificate's private key, PKIMessages
contains one PKIMessage with the header, body, and contains one PKIMessage with the header, body, and
protection elements, and should contain the extraCerts protection elements, and SHOULD contain the extraCerts
element. The header element contains the pvno, sender, element. The header element contains the pvno, sender,
recipient, protectionAlg, and optionally senderKID recipient, protectionAlg, and optionally senderKID
elements. The pvno contains cmp2000, the sender elements. The pvno contains cmp2000, the sender
contains the subject of the initial device identity contains the subject of the initial device identity
certificate, the protectionAlg contains the certificate, the protectionAlg contains the
AlgorithmIdentifier of the used signature algorithm, AlgorithmIdentifier of the used signature algorithm,
and the senderKID contains the subject key identifier and the senderKID contains the subject key identifier
of the initial device identity certificate. The body of the initial device identity certificate. The
element contains a p10cr CHOICE of type body element contains a p10cr CHOICE of type
CertificationRequest. It is signed with the local device CertificationRequest. It is signed with the local device
identity certificate's private key. The protection identity certificate's private key. The protection
element contains the digital signature generated with element contains the digital signature generated with
the initial device identity certificate's private key. the initial device identity certificate's private key.
The extraCerts element contains the initial device The extraCerts element contains the initial device
identity certificate, optionally followed by its 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 local device identity certificate's CSR signed by the local device identity certificate's
skipping to change at page 27, line 29 skipping to change at page 27, line 27
} }
<CODE ENDS> <CODE ENDS>
4. Security Considerations 4. Security Considerations
This document builds on top of the solution presented in [RFC8572] This document builds on top of the solution presented in [RFC8572]
and therefore all the Security Considerations discussed in RFC 8572 and therefore all the Security Considerations discussed in RFC 8572
apply here as well. apply here as well.
For the various CSR formats, when using PKCS#10, the security
considerations in [RFC2986] apply, when using CMP, the security
considerations in [RFC4210] apply and, when using CMC, the security
considerations in [RFC5272] apply.
For the various authentication mechanisms, when using TLS-level
authentication, the security considerations in [RFC8446] apply and,
when using HTTP-level authentication, the security considerations in
[RFC7235] apply.
4.1. SZTP-Client Considerations 4.1. SZTP-Client Considerations
4.1.1. Ensuring the Integrity of Asymmetric Private Keys 4.1.1. Ensuring the Integrity of Asymmetric Private Keys
The private key the SZTP-client uses for the dynamically-generated The private key the SZTP-client uses for the dynamically-generated
identity certificate MUST be protected from inadvertent disclosure in identity certificate MUST be protected from inadvertent disclosure in
order to prevent identity fraud. order to prevent identity fraud.
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 to authenticate the
device it is issued to.
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 contain the private key within the security perimeter of
perimeter of the HSM. In such cases, the private key, and its the HSM. In such cases, the private key, and its associated
associated certificates, MAY have long validity periods. certificates, MAY have long validity periods.
In cases where the SZTP-client does not possess an HSM, or is unable In cases where the SZTP-client does not possess an HSM, or is unable
to use an HSM to protect the private key, it is RECOMMENDED to to use an HSM to protect the private key, it is RECOMMENDED to
periodically reset the private key (and associated identity periodically reset the private key (and associated identity
certificates) in order to minimize the lifetime of unprotected certificates) in order to minimize the lifetime of unprotected
private keys. For instance, an NMS controller/orchestrator private keys. For instance, an NMS controller/orchestrator
application could periodically prompt the SZTP-client to generate a application could periodically prompt the SZTP-client to generate a
new private key and provide a certificate signing request (CSR) or, new private key and provide a certificate signing request (CSR) or,
alternatively, push both the key and an identity certificate to the alternatively, push both the key and an identity certificate to the
SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example, SZTP-client using, e.g., a PKCS #12 message [RFC7292]. In another
the SZTP-client could be configured to periodically reset the example, the SZTP-client could be configured to periodically reset
configuration to its factory default, thus causing removal of the the configuration to its factory default, thus causing removal of the
private key and associated identity certificates and reexecution of private key and associated identity certificates and re-execution of
the SZTP protocol. 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 Implementations must randomly generate nonces and private keys. The
use of inadequate pseudo-random number generators (PRNGs) to generate use of inadequate pseudo-random number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker cryptographic keys can result in little or no security. An attacker
skipping to change at page 29, line 15 skipping to change at page 29, line 28
When a fresh public/private key pair is generated for the request, When a fresh public/private key pair is generated for the request,
confirmation to the SZTP-client that the response has not been confirmation to the SZTP-client that the response has not been
replayed is enabled by the SZTP-client's fresh public key appearing replayed is enabled by the SZTP-client's fresh public key appearing
in the signed certificate provided by the SZTP-server. in the signed certificate provided by the SZTP-server.
When a public/private key pair associated with the manufacturer- When a public/private key pair associated with the manufacturer-
generated identity certificate (e.g., IDevID) is used for the generated identity certificate (e.g., IDevID) is used for the
request, there may not be confirmation to the SZTP-client that the request, there may not be confirmation to the SZTP-client that the
response has not been replayed; however, the worst case result is a response has not been replayed; however, the worst case result is a
lost certificate that is associated to the private key known only to lost certificate that is associated to the private key known only to
the SZTP-client. the SZTP-client. Protection of the private-key information is vital
to public-key cryptography. Disclosure of the private-key material
to another entity can lead to masquerades.
4.1.4. Connecting to an Untrusted Bootstrap Server 4.1.4. Connecting to an Untrusted Bootstrap 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 discussed in Section 9.5 of [RFC8572], in such cases the SZTP- As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP-
client MUST assert that the bootstrapping data returned is signed, if client MUST assert that the bootstrapping data returned is signed, if
the SZTP-client is to trust it. the SZTP-client is to trust it.
skipping to change at page 29, line 49 skipping to change at page 30, line 15
4.1.5. Selecting the Best Origin Authentication Mechanism 4.1.5. Selecting the Best Origin Authentication Mechanism
The origin of the CSR must be verified before a certificate is The origin of the CSR must be verified before a certificate is
issued. issued.
When generating a new key, it is important that the SZTP-client be When generating a new key, it is important that the SZTP-client be
able to provide additional proof that it was the entity that able to provide additional proof that it was the entity that
generated the key. generated the key.
The CMP and CMC certificate request formats defined in this document The CMP and CMC certificate request formats defined in this document
support origin authentication. A raw PKCS#10 does not support origin support origin authentication. A raw PKCS#10 CSR does not support
authentication. origin authentication.
The CMP and CMC request formats support origin authentication using The CMP and CMC request formats support origin authentication using
both PKI and shared 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.
skipping to change at page 30, line 25 skipping to change at page 30, line 38
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.
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 [RFC8808].
4.2. SZTP-Server Considerations 4.2. SZTP-Server Considerations
4.2.1. Verifying Proof of Possession 4.2.1. Verifying Proof of Possession
Regardless if using a new asymmetric key or the bootstrapping Regardless if using a new asymmetric key or the bootstrapping
device's manufacturer-generated key (e.g., the IDevID key), the device's manufacturer-generated key (e.g., the IDevID key), the
public key is placed in the CSR and the CSR is signed by that private public key is placed in the CSR and the CSR is signed by that private
key. Proof-of-possession of the private key is verified by ensuring key. Proof-of-possession of the private key is verified by ensuring
the signature over the CSR using the public key placed in the CSR. the signature over the CSR using the public key placed in the CSR.
4.2.2. Verifying Proof of Origin 4.2.2. Verifying Proof of Origin
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 for the CSR, proof-of-origin is (e.g., the IDevID key) is reused for the CSR, proof-of-origin is
verified by validating the IDevID-issuer cert and ensuring that the verified by validating the IDevID-issuer cert and ensuring that the
CSR uses the same key pair. CSR uses the same key pair.
When a new asymmetric key is used, with the CMP or CMC formats, the When the bootstrapping device's manufacturer-generated private key
parent ASN.1 structure of the CSR provides origin authentication (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof-
using either the manufacturer-generated private key or a shared of-origin is verified by validating the IDevID certification path and
secret. In this way the proof-of-possession of the CSR is directly ensuring that the CSR uses the same key pair.
linked to the proof-or-origin provided by the parent ASN.1 structure.
When a fresh asymmetric key is used with the CMP or CMC formats, the
authentication is part of the protocols, which could employ either
the manufacturer-generated private key or a shared secret. In
addition, CMP and CMC support processing by a RA before the request
is passed to the CA, which allows for more robust handling of errors.
4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 4.2.3. 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.
skipping to change at page 33, line 29 skipping to change at page 33, line 49
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
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), [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI),
"Application Notes and Interpretation of the Scheme (AIS) Killmann, W., and W. Schindler, "A proposal for:
31 - Functionality Classes and Evaluation Methodology for Functionality classes for random number generators,
Physical Random Number Generators", 25 September 2001. version 2.0", 18 September 2011,
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
Zertifizierung/Interpretationen/AIS_31_Functionality_class
es_for_random_number_generators_e.pdf>.
[CVE-2008-0166] [CVE-2008-0166]
National Institute of Science and Technology (NIST), National Institute of Science and Technology (NIST),
"National Vulnerability Database - CVE-2008-0166", 13 May "National Vulnerability Database - CVE-2008-0166", 13 May
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>. 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-23,
18 May 2021, <https://datatracker.ietf.org/doc/html/draft- 14 December 2021, <https://datatracker.ietf.org/doc/html/
ietf-netconf-keystore-22>. draft-ietf-netconf-keystore-23>.
[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-16, 14 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
trust-anchors-15>. trust-anchors-16>.
[I-D.ietf-netmod-factory-default]
Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", Work in Progress, Internet-
Draft, draft-ietf-netmod-factory-default-15, 25 April
2020, <https://datatracker.ietf.org/doc/html/draft-ietf-
netmod-factory-default-15>.
[ISO.20543-2019] [ISO.20543-2019]
International Organization for Standardization (ISO), International Organization for Standardization (ISO),
"Information technology -- Security techniques -- Test and "Information technology -- Security techniques -- Test and
analysis methods for random bit generators within ISO/IEC analysis methods for random bit generators within ISO/IEC
19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,
October 2019. October 2019.
[MiningPsQs] [MiningPsQs]
Security'12: Proceedings of the 21st USENIX conference on Security'12: Proceedings of the 21st USENIX conference on
skipping to change at page 35, line 28 skipping to change at page 36, line 5
[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>.
[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808,
August 2020, <https://www.rfc-editor.org/info/rfc8808>.
[Std-802.1AR-2018] [Std-802.1AR-2018]
Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", 14 metropolitan area networks - Secure Device Identity", 14
June 2018, <http://standards.ieee.org/findstds/ June 2018,
standard/802.1AR-2018.html>. <https://standards.ieee.org/standard/802_1AR-2018.html>.
Acknowledgements Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by first name): David von Oheimb, on list and in the halls (ordered by first name): Benjamin Kaduk,
Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Rich Salz, Rob Wilton, David von Oheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy
and Qin Wu. Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz,
Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman
Sarkar.
Contributors Contributors
Special thanks goes to David von Oheimb and Hendrik Brockhaus for Special thanks go to David von Oheimb and Hendrik Brockhaus for
helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
Email: kent+ietf@watsen.net Email: kent+ietf@watsen.net
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
Email: housley@vigilsec.com Email: housley@vigilsec.com
Sean Turner Sean Turner
sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 74 change blocks. 
177 lines changed or deleted 187 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/