< draft-ietf-netconf-sztp-csr-03.txt   draft-ietf-netconf-sztp-csr-04.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: 17 December 2021 S. Turner Expires: 31 December 2021 S. Turner
sn3rd sn3rd
15 June 2021 29 June 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-03 draft-ietf-netconf-sztp-csr-04
Abstract Abstract
This draft extends the "get-bootstrapping-data" RPC defined in RFC This draft extends the "get-bootstrapping-data" RPC defined in RFC
8572 to include an optional certificate signing request (CSR), 8572 to include an optional certificate signing request (CSR),
enabling a bootstrapping device to additionally obtain an identity enabling a bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
"onboarding information" response provided in the RPC-reply. "onboarding information" response provided in the RPC-reply.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
* "XXXX" --> the assigned numerical RFC value for this draft * "XXXX" --> the assigned numerical RFC value for this draft
* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto- * "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto-
types types
Artwork in this document contains a placeholder value for the Artwork in this document contains a placeholder value for the
publication date of this draft. Please apply the following publication date of this draft. Please apply the following
replacement: replacement:
* "2021-06-15" --> the publication date of this draft * "2021-06-29" --> 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 17 December 2021. This Internet-Draft will expire on 31 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 47 skipping to change at page 2, line 47
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4
2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23
3.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 23 3.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 23
3.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 23 3.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 23
3.1.2. Reuse of a Manufacturer-generated Private Key . . . . 23 3.1.2. Reuse of a Manufacturer-generated Private Key . . . . 23
3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 23 3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 24
3.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 24 3.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 24
3.1.5. Selecting the Best Origin Authentication Mechanism . 24 3.1.5. Selecting the Best Origin Authentication Mechanism . 25
3.1.6. Clearing the Private Key and Associated 3.1.6. Clearing the Private Key and Associated
Certificate . . . . . . . . . . . . . . . . . . . . . 25 Certificate . . . . . . . . . . . . . . . . . . . . . 25
3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25 3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25
3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25 3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25
3.2.2. Supporting SZTP-Clients that don't trust the 3.2.2. Supporting SZTP-Clients that don't trust the
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 26
3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26 3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 26 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 26
4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 26 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 27
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Normative References . . . . . . . . . . . . . . . . . . 26 5.1. Normative References . . . . . . . . . . . . . . . . . . 27
5.2. Informative References . . . . . . . . . . . . . . . . . 27 5.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
"bootstrap server" that is symmetric with the "SZTP-client" term. "bootstrap server" that is symmetric with the "SZTP-client" term.
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.4. Conventions
Various examples used in this document use a placeholder value for
binary data that has been base64 encoded (e.g., "BASE64VALUE=").
This placeholder value is used as real base64 encoded structures are
often many lines long and hence distracting to the example being
presented.
2. The "ietf-sztp-csr" Module 2. The "ietf-sztp-csr" Module
This section defines a YANG 1.1 [RFC7950] module that augments the This section defines a YANG 1.1 [RFC7950] module that augments the
"ietf-sztp-bootstrap-server" module defined in [RFC8572] and defines "ietf-sztp-bootstrap-server" module defined in [RFC8572] and defines
a YANG "structure". a YANG "structure".
The augmentation adds two nodes ("csr-support" and "csr") to the The augmentation adds two nodes ("csr-support" and "csr") to the
"input" parameter of the "get-bootstrapping-data" RPC defined in "input" parameter of the "get-bootstrapping-data" RPC defined in
[RFC8572]. [RFC8572].
The YANG structure, "request-info", defines data returned in the The YANG structure, "request-info", defines data returned in the
"error-info" node defined in Section 7.1 of [RFC8040]. "error-info" node defined in Section 7.1 of [RFC8040].
2.1. Data Model Overview 2.1. Data Model Overview
The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr"
module. The diagram shows the definition of an augmentation adding module. The diagram shows the definition of an augmentation adding
descendent nodes "csr-support" and "csr" and the definition of a descendant nodes "csr-support" and "csr" and the definition of a
structure called "request-info". structure called "request-info".
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, per SZTP-server that it supports the ability the generate CSRs, per
this specification. The "csr-support" parameter carries details this specification. The "csr-support" parameter carries details
regarding the SZTP-client's ability to generate CSRs. regarding the SZTP-client's ability to generate CSRs.
* The "request-info" structure is used by the SZTP-server to signal * The "request-info" structure is used by the SZTP-server to signal
skipping to change at page 5, line 8 skipping to change at page 5, line 18
the SZTP-client is to generate. the SZTP-client is to generate.
* The "csr" node is used by the SZTP-client to communicate its CSR * The "csr" node is used by the SZTP-client to communicate its CSR
to the SZTP-server. Not shown is how the SZTP-server communicates to the SZTP-server. Not shown is how the SZTP-server communicates
the signed certificate to the SZTP-client; how to do this is the signed certificate to the SZTP-client; how to do this is
discussed later in this document. discussed later in this document.
module: ietf-sztp-csr module: ietf-sztp-csr
augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: augment /sztp-svr:get-bootstrapping-data/sztp-svr:input:
+---w csr-support! +---w (msg-type)?
| +---w key-generation! +--:(csr-support)
| | +---w supported-algorithms | +---w csr-support!
| | +---w algorithm-identifier* binary | +---w key-generation!
| +---w csr-generation | | +---w supported-algorithms
| +---w supported-formats | | +---w algorithm-identifier* binary
| +---w format-identifier* identityref | +---w csr-generation
+---w csr! | +---w supported-formats
+---w (request-type) | +---w format-identifier* identityref
+--:(p10) +--:(csr)
| +---w p10? ct:csr +---w csr!
+--:(cmc) +---w (request-type)
| +---w cmc? binary +--:(p10)
+--:(cmp) | +---w p10? ct:csr
+---w cmp? binary +--:(cmc)
| +---w cmc? binary
+--:(cmp)
+---w cmp? binary
structure: request-info structure: request-info
+--ro key-generation! +--ro key-generation!
| +--ro selected-algorithm | +--ro selected-algorithm
| +--ro algorithm-identifier binary | +--ro algorithm-identifier binary
+--ro csr-generation +--ro csr-generation
| +--ro selected-format | +--ro selected-format
| +--ro format-identifier identityref | +--ro format-identifier identityref
+--ro cert-req-info? ietf-crypto-types:csr-info +--ro cert-req-info? ietf-crypto-types:csr-info
To further illustrate how the augmentation and structure defined by To further illustrate how the augmentation and structure defined by
the "ietf-sztp-csr" module are used, below are two additional tree the "ietf-sztp-csr" module are used, below are two additional tree
diagrams showing these nodes placed where they are used. diagrams showing these nodes placed where they are used.
The following tree diagram [RFC8340] illustrates SZTP's "get- The following tree diagram [RFC8340] illustrates SZTP's "get-
bootstrapping-data" RPC with the augmentation in place. bootstrapping-data" RPC with the augmentation in place.
=============== NOTE: '\' line wrapping per RFC 8792 ================
module: ietf-sztp-bootstrap-server module: ietf-sztp-bootstrap-server
rpcs: rpcs:
+---x get-bootstrapping-data +---x get-bootstrapping-data
+---w input +---w input
| +---w signed-data-preferred? empty | +---w signed-data-preferred? empty
| +---w hw-model? string | +---w hw-model? string
| +---w os-name? string | +---w os-name? string
| +---w os-version? string | +---w os-version? string
| +---w nonce? binary | +---w nonce? binary
| +---w sztp-csr:csr-support! | +---w (sztp-csr:msg-type)?
| | +---w sztp-csr:key-generation! | +--:(sztp-csr:csr-support)
| | | +---w sztp-csr:supported-algorithms | | +---w sztp-csr:csr-support!
| | | +---w sztp-csr:algorithm-identifier* binary | | +---w sztp-csr:key-generation!
| | +---w sztp-csr:csr-generation | | | +---w sztp-csr:supported-algorithms
| | +---w sztp-csr:supported-formats | | | +---w sztp-csr:algorithm-identifier* bina\
| | +---w sztp-csr:format-identifier* identityref ry
| +---w sztp-csr:csr! | | +---w sztp-csr:csr-generation
| +---w (sztp-csr:request-type) | | +---w sztp-csr:supported-formats
| +--:(sztp-csr:p10) | | +---w sztp-csr:format-identifier* identit\
| | +---w sztp-csr:p10? ct:csr yref
| +--:(sztp-csr:cmc) | +--:(sztp-csr:csr)
| | +---w sztp-csr:cmc? binary | +---w sztp-csr:csr!
| +--:(sztp-csr:cmp) | +---w (sztp-csr:request-type)
| +---w sztp-csr:cmp? binary | +--:(sztp-csr:p10)
| | +---w sztp-csr:p10? ct:csr
| +--:(sztp-csr:cmc)
| | +---w sztp-csr:cmc? binary
| +--:(sztp-csr:cmp)
| +---w sztp-csr:cmp? binary
+--ro output +--ro output
+--ro reporting-level? enumeration {onboarding-server}? +--ro reporting-level? enumeration {onboarding-server}?
+--ro conveyed-information cms +--ro conveyed-information cms
+--ro owner-certificate? cms +--ro owner-certificate? cms
+--ro ownership-voucher? cms +--ro ownership-voucher? cms
The following tree diagram [RFC8340] illustrates RESTCONF's "errors" The following tree diagram [RFC8340] illustrates RESTCONF's "errors"
RPC-reply message with the "request-info" structure in place. RPC-reply message with the "request-info" structure in place.
module: ietf-restconf module: ietf-restconf
skipping to change at page 8, line 21 skipping to change at page 8, line 21
{ {
"ietf-sztp-bootstrap-server:input" : { "ietf-sztp-bootstrap-server:input" : {
"hw-model": "model-x", "hw-model": "model-x",
"os-name": "vendor-os", "os-name": "vendor-os",
"os-version": "17.3R2.1", "os-version": "17.3R2.1",
"nonce": "extralongbase64encodedvalue=", "nonce": "extralongbase64encodedvalue=",
"ietf-sztp-csr:csr-support": { "ietf-sztp-csr:csr-support": {
"key-generation": { "key-generation": {
"supported-algorithms": { "supported-algorithms": {
"algorithm-identifier": [ "algorithm-identifier": [
"base64encodedvalue1=", "BASE64VALUE1",
"base64encodedvalue2=", "BASE64VALUE2",
"base64encodedvalue3=" "BASE64VALUE3"
] ]
} }
}, },
"csr-generation": { "csr-generation": {
"supported-formats": { "supported-formats": {
"format-identifier": [ "format-identifier": [
"ietf-sztp-csr:p10", "ietf-sztp-csr:p10",
"ietf-sztp-csr:cmc", "ietf-sztp-csr:cmc",
"ietf-sztp-csr:cmp" "ietf-sztp-csr:cmp"
] ]
} }
} }
} }
} }
} }
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 a CSR, then it would respond with an HTTP 300 Multiple Choices error
code: code:
RESPONSE RESPONSE
HTTP/1.1 400 Bad Request HTTP/1.1 300 Multiple Choices
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" : [
{ {
"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:request-info": { "ietf-sztp-csr:request-info": {
"key-generation": { "key-generation": {
"selected-algorithm": { "selected-algorithm": {
"algorithm-identifier": "base64EncodedValue==" "algorithm-identifier": "BASE64VALUE="
} }
}, },
"csr-generation": { "csr-generation": {
"selected-format": { "selected-format": {
"format-identifier": "ietf-sztp-csr:cmc" "format-identifier": "ietf-sztp-csr:cmc"
} }
}, },
"cert-req-info": "base64EncodedValue==" "cert-req-info": "BASE64VALUE="
} }
} }
} }
] ]
} }
} }
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 the another "get-bootstrapping-data" request, but this time including the
"csr" node to convey its CSR to the SZTP-server: "csr" node to convey its CSR to the SZTP-server:
skipping to change at page 10, line 18 skipping to change at page 10, line 18
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": { "ietf-sztp-csr:csr": {
"p10": "base64encodedvalue==" "p10": "BASE64VALUE="
} }
} }
} }
The SZTP-server responds with "onboarding-information" (encoded The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client: certificate for the CSR provided by the SZTP-client:
RESPONSE RESPONSE
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server Server: example-server
Content-Type: application/yang.data+json Content-Type: application/yang.data+json
{ {
"ietf-sztp-bootstrap-server:output" : { "ietf-sztp-bootstrap-server:output" : {
"reporting-level": "verbose", "reporting-level": "verbose",
"conveyed-information": "base64encodedvalue==" "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].
skipping to change at page 11, line 21 skipping to change at page 11, line 21
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-keystore:keystore": { "ietf-keystore:keystore": {
"asymmetric-keys": { "asymmetric-keys": {
"asymmetric-key": [ "asymmetric-key": [
{ {
"name": "Manufacturer-Generated Hidden Key", "name": "Manufacturer-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
-info-format", -info-format",
"public-key": "base64encodedvalue==", "public-key": "BASE64VALUE=",
"hidden-private-key": [null], "hidden-private-key": [null],
"certificates": { "certificates": {
"certificate": [ "certificate": [
{ {
"name": "Manufacturer-Generated IDevID Cert", "name": "Manufacturer-Generated IDevID Cert",
"cert-data": "base64encodedvalue==" "cert-data": "BASE64VALUE="
}, },
{ {
"name": "Newly-Generated LDevID Cert", "name": "Newly-Generated LDevID Cert",
"cert-data": "base64encodedvalue==" "cert-data": "BASE64VALUE="
} }
] ]
} }
} }
] ]
} }
} }
} }
This second example illustrates the case where the signed certificate This second example illustrates the case where the signed certificate
skipping to change at page 12, line 15 skipping to change at page 12, line 15
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-keystore:keystore": { "ietf-keystore:keystore": {
"asymmetric-keys": { "asymmetric-keys": {
"asymmetric-key": [ "asymmetric-key": [
{ {
"name": "Manufacturer-Generated Hidden Key", "name": "Manufacturer-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
-info-format", -info-format",
"public-key": "base64encodedvalue==", "public-key": "BASE64VALUE=",
"hidden-private-key": [null], "hidden-private-key": [null],
"certificates": { "certificates": {
"certificate": [ "certificate": [
{ {
"name": "Manufacturer-Generated IDevID Cert", "name": "Manufacturer-Generated IDevID Cert",
"cert-data": "base64encodedvalue==" "cert-data": "BASE64VALUE="
} }
] ]
} }
}, },
{ {
"name": "Newly-Generated Hidden Key", "name": "Newly-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
-info-format", -info-format",
"public-key": "base64encodedvalue==", "public-key": "BASE64VALUE=",
"hidden-private-key": [null], "hidden-private-key": [null],
"certificates": { "certificates": {
"certificate": [ "certificate": [
{ {
"name": "Newly-Generated LDevID Cert", "name": "Newly-Generated LDevID Cert",
"cert-data": "base64encodedvalue==" "cert-data": "BASE64VALUE="
} }
] ]
} }
} }
] ]
} }
} }
} }
In addition to configuring the signed certificate, it is often In addition to configuring the signed certificate, it is often
necessary to also configure the Issuer's signing certificate so that necessary to also configure the Issuer's signing certificate so that
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], uses a data type This module augments an RPC defined in [RFC8572], uses a data type
defined in [I-D.ietf-netconf-crypto-types], has an normative defined in [I-D.ietf-netconf-crypto-types], has normative references
references to [RFC2986] and [ITU.X690.2015], and an informative to [RFC2986] and [ITU.X690.2015], and an informative reference to
reference to [Std-802.1AR-2018]. [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2021-06-15.yang" <CODE BEGINS> file "ietf-sztp-csr@2021-06-29.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 27 skipping to change at page 14, line 27
(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-06-15 { revision 2021-06-29 {
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 16, line 6 skipping to change at page 16, line 6
that it supports generating certificate signing requests that it supports generating certificate signing requests
(CSRs), and to provide details around the CSRs it is able (CSRs), and to provide details around the CSRs it is able
to generate. to generate.
The 'csr' node enables the SZTP-client to relay a CSR to The 'csr' node enables the SZTP-client to relay a CSR to
the SZTP-server."; the SZTP-server.";
reference reference
"IEEE 802.1AR: IEEE Standard for Local and metropolitan "IEEE 802.1AR: IEEE Standard for Local and metropolitan
area networks - Secure Device Identity area networks - Secure Device Identity
RFC 8572: Secure Zero Touch Provisioning (SZTP)"; RFC 8572: Secure Zero Touch Provisioning (SZTP)";
container csr-support { choice msg-type {
presence
"Indicates that the SZTP-client is capable of sending CSRs.";
description description
"The 'csr-support' node enables the SZTP-client to indicate "Only a 'csr-support' or a 'csr' message may be sent.";
that it supports generating certificate signing requests container csr-support {
(CSRs), and provide details around the CSRs it is able
to generate.
When present, the SZTP-server MAY respond with the HTTP
error 400 (Bad Request) with an 'ietf-restconf:errors'
document having the 'error-tag' value 'missing-attribute'
and the 'error-info' node containing the 'request-info'
structure described in this module.";
container key-generation {
presence presence
"Indicates that the SZTP-client is capable of "Indicates that the SZTP-client is capable of sending
generating a new asymmetric key pair. CSRs.";
If this node is not present, the SZTP-server MAY
request a CSR using the asymmetric key associated
with the device's existing identity certificate
(e.g., an IDevID from IEEE 802.1AR).";
description description
"Specifies details for the SZTP-client's ability to "The 'csr-support' node enables the SZTP-client to
generate a new asymmetric key pair."; indicate that it supports generating certificate
container supported-algorithms { signing requests (CSRs), and provide details around
the CSRs it is able to generate.
When present, the SZTP-server MAY respond with the HTTP
code 300 Multiple Choices with an 'ietf-restconf:errors'
document having the 'error-tag' value 'missing-attribute'
and the 'error-info' node containing the 'request-info'
structure described in this module.";
container key-generation {
presence
"Indicates that the SZTP-client is capable of
generating a new asymmetric key pair.
If this node is not present, the SZTP-server MAY
request a CSR using the asymmetric key associated
with the device's existing identity certificate
(e.g., an IDevID from IEEE 802.1AR).";
description description
"A list of public key algorithms supported by the "Specifies details for the SZTP-client's ability to
SZTP-client for generating a new key."; generate a new asymmetric key pair.";
leaf-list algorithm-identifier { container supported-algorithms {
type binary;
min-elements 1;
description description
"An AlgorithmIdentifier, as defined in RFC 2986, "A list of public key algorithms supported by the
encoded using ASN.1 distinguished encoding rules SZTP-client for generating a new key.";
(DER), as specified in ITU-T X.690."; leaf-list algorithm-identifier {
reference type binary;
"RFC 2986: PKCS #10: Certification Request Syntax min-elements 1;
Specification Version 1.7 description
ITU-T X.690: "An AlgorithmIdentifier, as defined in RFC 2986,
Information technology - ASN.1 encoding rules: encoded using ASN.1 distinguished encoding rules
Specification of Basic Encoding Rules (BER), (DER), as specified in ITU-T X.690.";
Canonical Encoding Rules (CER) and Distinguished reference
Encoding Rules (DER)."; "RFC 2986: PKCS #10: Certification Request Syntax
} Specification Version 1.7
ITU-T X.690:
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
}
} }
} container csr-generation {
container csr-generation {
description
"Specifies details for the SZTP-client's ability to
generate a certificate signing requests.";
container supported-formats {
description description
"A list of certificate request formats supported "Specifies details for the SZTP-client's ability to
by the SZTP-client for generating a new key."; generate a certificate signing requests.";
leaf-list format-identifier { container supported-formats {
type identityref {
base certificate-request-format;
}
min-elements 1;
description description
"A certificate request format supported by the "A list of certificate request formats supported
SZTP-client."; by the SZTP-client for generating a new key.";
leaf-list format-identifier {
type identityref {
base certificate-request-format;
}
min-elements 1;
description
"A certificate request format supported by the
SZTP-client.";
}
} }
} }
} }
} container csr {
container csr { presence "Indicates that the SZTP-client has sent a CSR.";
presence "Indicates that the SZTP-client has sent a CSR.";
description
"The 'csr' node enables the SZTP-client to convey
a certificate signing request, using the encoding
format selected by the SZT-server's 'request-info'
response to the SZTP-client's previously sent
'get-bootstrapping-data' request containing the
'csr-support' node.
When present, the SZTP-server SHOULD respond with
an SZTP onboarding information message containing
a signed certificate for the conveyed CSR. The
SZTP-server MAY alternatively respond with another
HTTP error containing another 'request-info', in
which case the SZTP-client MUST invalidate the CSR
sent in this node.";
choice request-type {
mandatory true;
description description
"A choice amongst certificate signing request formats. "The 'csr' node enables the SZTP-client to convey
a certificate signing request, using the encoding
format selected by the SZTP-server's 'request-info'
response to the SZTP-client's previously sent
'get-bootstrapping-data' request containing the
'csr-support' node.
Additional formats MAY be augmented into this 'choice' When present, the SZTP-server SHOULD respond with
statement by future efforts."; an SZTP onboarding information message containing
case p10 { a signed certificate for the conveyed CSR. The
leaf p10 { SZTP-server MAY alternatively respond with another
type ct:csr; HTTP error containing another 'request-info', in
description which case the SZTP-client MUST invalidate the CSR
"A CertificationRequest structure, per RFC 2986. sent in this node.";
Please see 'csr' in RFC AAAA for encoding details."; choice request-type {
reference mandatory true;
"RFC 2986: description
PKCS #10: Certification Request Syntax Specification "A choice amongst certificate signing request formats.
RFC AAAA:
YANG Data Types and Groupings for Cryptography"; Additional formats MAY be augmented into this 'choice'
statement by future efforts.";
case p10 {
leaf p10 {
type ct:csr;
description
"A CertificationRequest structure, per RFC 2986.
Please see 'csr' in RFC AAAA for encoding details.";
reference
"RFC 2986: PKCS #10: Certification
Request Syntax Specification
RFC AAAA: YANG Data Types and Groupings
for Cryptography";
}
} }
} case cmc {
case cmc { leaf cmc {
leaf cmc { 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 For asymmetric key-based origin authentication
of a CSR based on the IDevID's private key for the of a CSR based on the IDevID's private key for the
associated IDevID's public key, the PKIData contains associated IDevID's public key, the PKIData contains
one reqSequence element and no controlSequence, one reqSequence element and no controlSequence,
cmsSequence, or otherMsgSequence elements. The cmsSequence, 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 CHOICE. The tcr is the TaggedCertificationRequest
and it a bodyPartId and the certificateRequest and it a bodyPartId and the certificateRequest
elements. The certificateRequest is signed with elements. The certificateRequest is signed with
the IDevID's private key. the IDevID's private key.
For asymmetric key-based origin authentication For asymmetric key-based origin authentication
based on the IDevID's private key that encapsulates based on the IDevID's private key that encapsulates
a CSR signed by the LDevID's private key, the a CSR signed by the LDevID's private key, the
PKIData contains one cmsSequence element and no PKIData contains one cmsSequence element and no
controlSequence, reqSequence, or otherMsgSequence controlSequence, reqSequence, or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo
and it includes a bodyPartID element and a and it includes a bodyPartID element and a
contentInfo. The contentInfo is a SignedData contentInfo. The contentInfo is a SignedData
encapsulating a PKIData with one reqSequence encapsulating a PKIData with one reqSequence
element and no controlSequence, cmsSequence, or element and no controlSequence, cmsSequence, or
otherMsgSequence elements. The reqSequence is otherMsgSequence elements. The reqSequence is
the TaggedRequest and it is the tcr CHOICE. The the TaggedRequest and it is the tcr CHOICE. The
tcr is the TaggedCertificationRequest and it a tcr is the TaggedCertificationRequest and it a
bodyPartId and the certificateRequest elements. bodyPartId and the certificateRequest elements.
The certificateRequest is signed with the LDevID's The certificateRequest is signed with the LDevID's
private key. private key.
For shared secret-based origin authentication of For shared secret-based origin authentication of
a CSR signed by the LDevID's private key, the a CSR signed by the LDevID's private key, the
PKIData contains one cmsSequence element and no PKIData contains one cmsSequence element and no
controlSequence, reqSequence, or otherMsgSequence controlSequence, reqSequence, or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo
and it includes a bodyPartID element and a and it includes a bodyPartID element and a
contentInfo. The contentInfo is an AuthenticatedData contentInfo. The contentInfo is an AuthenticatedData
encapsulating a PKIData with one reqSequence encapsulating a PKIData with one reqSequence
element and no controlSequence, cmsSequence, or element and no controlSequence, cmsSequence, or
otherMsgSequence elements. The reqSequence is the otherMsgSequence elements. The reqSequence is the
TaggedRequest and it is the tcr CHOICE. The tcr TaggedRequest and it is the tcr CHOICE. The tcr
is the TaggedCertificationRequest and it a is the TaggedCertificationRequest and it a
bodyPartId and the certificateRequest elements. bodyPartId and the certificateRequest elements.
The certificateRequest is signed with the LDevID's The certificateRequest is signed with the LDevID's
private key."; private key.";
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 {
case cmp { leaf cmp {
leaf cmp { 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.
The PKIMessage structure contains a PKCS#10 The PKIMessage structure contains a PKCS#10
Certificate Signing Request (p10cr), as defined in Certificate Signing Request (p10cr), as defined in
RFC 2986, encapsulated in a Nested Message Content RFC 2986, encapsulated in a Nested Message Content
(nested) structure, as defined in RFC 4210. (nested) structure, as defined in RFC 4210.
For asymmetric key-based origin authentication of For asymmetric key-based origin authentication of
a CSR based on the IDevID's private key for the a CSR based on the IDevID's private key for the
associated IDevID's public key, PKIMessages contains associated IDevID's public key, PKIMessages contains
one PKIMessage with one body element, a header one PKIMessage with one body element, a header
element that is an empty sequence, and no protection element that is an empty sequence, and no protection
or extraCerts elements. The body element contains a or extraCerts elements. The body element contains a
p10cr CHOICE. p10cr CHOICE.
For asymmetric key-based origin authentication based For asymmetric key-based origin authentication based
on the IDevID's private key that encapsulates a CSR on the IDevID's private key that encapsulates a CSR
signed by the LDevID's private key, PKIMessages signed by the LDevID's private key, PKIMessages
contains one PKIMessage with one header element, contains one PKIMessage with one header element,
one body element, one protection element, and one one body element, one protection element, and one
extraCerts element. The header element contains extraCerts element. The header element contains
pvno, sender, recipient, and protectionAlg elements pvno, sender, recipient, and protectionAlg elements
and no other elements. The body element contains the and no other elements. The body element contains the
nested CHOICE. The nested element's PKIMessages nested CHOICE. The nested element's PKIMessages
contains one PKIMessage with one body element, one contains one PKIMessage with one body element, one
header element that is an empty sequence, and no header element that is an empty sequence, and no
protection or extraCerts elements. The nested protection or extraCerts elements. The nested
element's body element contains a p10cr CHOICE. The element's body element contains a p10cr CHOICE. The
protection element contains the digital signature protection element contains the digital signature
generated with the IDevID's private key. The generated with the IDevID's private key. The
extraCerts element contains the IDevID certificate. extraCerts element contains the IDevID certificate.
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 LDevID's private key, PKIMessages
contains one PKIMessage with one header element, contains one PKIMessage with one header element,
one body element, one protection element, and no one body element, one protection element, and no
extraCerts element. The header element contains extraCerts element. The header element contains
pvno, sender, recipient, and protectionAlg elements pvno, sender, recipient, and protectionAlg elements
and no other elements. The body element contains and no other elements. The body element contains
the nested CHOICE. The nested element's PKIMessages the nested CHOICE. The nested element's PKIMessages
contains one PKIMessage with one body element, one contains one PKIMessage with one body element, one
header element that is an empty sequence, and no header element that is an empty sequence, and no
protection or extraCerts elements. The body element protection or extraCerts elements. The body element
contains a p10cr CHOICE. The protection element contains a p10cr CHOICE. The protection element
contains the MAC value generated with the shared contains the MAC value generated with the shared
secret."; secret.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax PKCS #10: Certification Request Syntax
Specification Version 1.7 Specification Version 1.7
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).";
}
} }
} }
} }
} }
} }
sx:structure request-info { sx:structure request-info {
container key-generation { container key-generation {
presence presence
"Indicates that the SZTP-client is to generate a new "Indicates that the SZTP-client is to generate a new
asymmetric key. If missing, then the SZTP-client asymmetric key. If missing, then the SZTP-client
MUST reuse the key associated with its existing MUST reuse the key associated with its existing
identity certificate (e.g., IDevID). identity certificate (e.g., IDevID).
skipping to change at page 22, line 31 skipping to change at page 22, line 34
RFC AAAA. RFC AAAA.
Enables the SZTP-server to provide a fully-populated Enables the SZTP-server to provide a fully-populated
CertificationRequestInfo structure that the SZTP-client CertificationRequestInfo structure that the SZTP-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 SZTP-server 'CertificationRequest' structure to send to SZTP-server
in its next 'get-bootstrapping-data' request message. in its next 'get-bootstrapping-data' request message.
When provided, the SZTP-client SHOULD use this When provided, the SZTP-client SHOULD use this
structure to generate its CSR; failure to do so MAY structure to generate its CSR; failure to do so MAY
result in a 400 (Bad Request) response containing result in a 300 Multiple Choices response containing
another 'request-info' structure. another 'request-info' structure.
When not provided, the SZTP-client SHOULD generate a When not provided, the SZTP-client SHOULD generate a
CSR using the same structure defined in its existing CSR using the same structure defined in its existing
identity certificate (e.g., IDevID). identity certificate (e.g., IDevID).
It is an error if the 'AlgorithmIdentifier' field It is an error if the 'AlgorithmIdentifier' field
contained inside the 'SubjectPublicKeyInfo' field contained inside the 'SubjectPublicKeyInfo' field
does not match the algorithm identified by the does not match the algorithm identified by the
'selected-algorithm' node."; 'selected-algorithm' node.";
skipping to change at page 23, line 51 skipping to change at page 24, line 7
key associated with the device's initial secure device identity key associated with the device's initial secure 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.
3.1.3. Replay Attack Protection 3.1.3. Replay Attack Protection
This RFC enables an SZTP-client to announce an ability to generate This RFC enables an SZTP-client to announce an ability to generate a
new key to use for its CSR. new key to use for its CSR.
When the SZTP-server responds with a request for the device to When the SZTP-server responds with a request for the device to
generate a new key, it is essential that the device actually generate a new key, it is essential that the device actually
generates a new key. generates a new key.
Generating a new key each time enables the random bytes used to Generating a new key each time enables the random bytes used to
create the key to serve the dual-purpose of also acting like a create the key to also serve the dual-purpose of acting like a
"nonce" used in other mechanisms to detect replay attacks. "nonce" used in other mechanisms to detect replay attacks.
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 IDevID used for When a public/private key pair associated with the manufacturer-
the request, there may not be confirmation to the SZTP-client that generated identity certificate (e.g., IDevID) is used for the
the response has not been replayed; however, the worst case result is request, there may not be confirmation to the SZTP-client that the
a lost certificate that is associated to the private key known only response has not been replayed; however, the worst case result is a
to the SZTP-client. lost certificate that is associated to the private key known only to
the SZTP-client.
3.1.4. Connecting to an Untrusted Bootstrap Server 3.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.
However, the HTTP error message used in this document cannot be However, the HTTP error message used in this document cannot be
signed data, as described in RFC 8572. signed data, as described in RFC 8572.
Therefore, the solution presented in this document cannot be used Therefore, the solution presented in this document cannot be used
when the SZTP-client connects to an untrusted SZTP-server. when the SZTP-client connects to an untrusted SZTP-server.
Consistent with the recommendation presented in Section 9.6 of Consistent with the recommendation presented in Section 9.6 of
[RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input
parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass
instead the "signed-data-preferred" input parameter, as discussed in instead the "signed-data-preferred" input parameter, as discussed in
Appendix B of [RFC8572]. Appendix B of [RFC8572].
3.1.5. Selecting the Best Origin Authentication Mechanism 3.1.5. Selecting the Best Origin Authentication Mechanism
When generating a new key, it is important that the client be able to When generating a new key, it is important that the client be able to
provide additional proof to the CA that it was the entity that provide additional proof to the CA that it was the entity that
generated the key. generated the key.
All of the certificate request formats defined in this document All the certificate request formats defined in this document (e.g.,
(e.g., CMC, CMP, etc.), not including a raw PKCS#10, support origin CMC, CMP, etc.), not including a raw PKCS#10, support origin
authentication. authentication.
These formats support origin authentication using both PKI and shared These formats support origin authentication using both PKI and shared
secret. secret.
Typically only one possible origin authentication mechanism can Typically, only one possible origin authentication mechanism can
possibly be used but, in the case that the SZTP-client authenticates possibly be used but, in the case that the SZTP-client authenticates
itself using both TLS-level (e.g., IDevID) and HTTP-level credentials itself using both TLS-level (e.g., IDevID) and HTTP-level credentials
(e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the
SZTP-client may need to choose between the two options. SZTP-client may need to choose between the two options.
In the case the SZTP-client must choose between the asymmetric key In the case that the SZTP-client must choose between the asymmetric
option versus a shared secret for origin authentication, it is key option versus a shared secret for origin authentication, it is
RECOMMENDED that the SZTP-client choose using the asymmetric key RECOMMENDED that the SZTP-client choose using the asymmetric key
option. option.
3.1.6. Clearing the Private Key and Associated Certificate 3.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 device is reset to its factory default state, such as by the the device is reset to its factory default state, such as by the
"factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default].
3.2. SZTP-Server Considerations 3.2. SZTP-Server Considerations
3.2.1. Conveying Proof of Possession to a CA 3.2.1. Conveying Proof of Possession to a CA
When the bootstrapping device's manufacturer-generated private key
(e.g., the IDevID key) is reused, a CA may validate that the CSR was
signed by that key.
Both the CMP and CMC formats entail the bootstrapping device signing
the request once with its (e.g., LDevID) key and then again with its
(e.g., IDevID) key, which enables a downstream CA to be assured that
the device possesses the public key being signed.
3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server
[RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers,
by blindly authenticating the SZTP-server's TLS end-entity by blindly authenticating the SZTP-server's TLS end-entity
certificate. certificate.
As is recommended in Section 3.1.4 in this document, in such cases, As is recommended in Section 3.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.
The reciprocal of this statement is that SZTP-servers, wanting to The reciprocal of this statement is that SZTP-servers, wanting to
skipping to change at page 27, line 9 skipping to change at page 27, line 25
reference: RFC XXXX reference: RFC XXXX
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-netconf-crypto-types] [I-D.ietf-netconf-crypto-types]
Watsen, K., "YANG Data Types and Groupings for Watsen, K., "YANG Data Types and Groupings for
Cryptography", Work in Progress, Internet-Draft, draft- Cryptography", Work in Progress, Internet-Draft, draft-
ietf-netconf-crypto-types-19, 10 February 2021, ietf-netconf-crypto-types-19, 10 February 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-crypto- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
types-19>. crypto-types-19>.
[ITU.X690.2015] [ITU.X690.2015]
International Telecommunication Union, "Information International Telecommunication Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, ISO/IEC 8825-1, August 2015, X.690, ISO/IEC 8825-1, August 2015,
<https://www.itu.int/rec/T-REC-X.690/>. <https://www.itu.int/rec/T-REC-X.690/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[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
skipping to change at page 28, line 8 skipping to change at page 28, line 32
[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>.
5.2. Informative References 5.2. Informative References
[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-21, Progress, Internet-Draft, draft-ietf-netconf-keystore-21,
10 February 2021, <https://tools.ietf.org/html/draft-ietf- 10 February 2021, <https://datatracker.ietf.org/doc/html/
netconf-keystore-21>. draft-ietf-netconf-keystore-21>.
[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-14, 10 February 2021, anchors-14, 10 February 2021,
<https://tools.ietf.org/html/draft-ietf-netconf-trust- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
anchors-14>. trust-anchors-14>.
[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://tools.ietf.org/html/draft-ietf-netmod- 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-
factory-default-15>. netmod-factory-default-15>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
 End of changes. 70 change blocks. 
304 lines changed or deleted 340 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/