< draft-ietf-netconf-sztp-csr-00.txt   draft-ietf-netconf-sztp-csr-01.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: 5 April 2021 S. Turner Expires: 20 May 2021 S. Turner
sn3rd sn3rd
2 October 2020 16 November 2020
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-00 draft-ietf-netconf-sztp-csr-01
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:
* "2020-10-02" --> the publication date of this draft * "2020-11-16" --> 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 5 April 2021. This Internet-Draft will expire on 20 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 7 skipping to change at page 3, line 7
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 24 3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 23
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 . 25 3.1.5. Selecting the Best Origin Authentication Mechanism . 24
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 . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . 26
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Normative References . . . . . . . . . . . . . . . . . . 27 5.1. Normative References . . . . . . . . . . . . . . . . . . 26
5.2. Informative References . . . . . . . . . . . . . . . . . 28 5.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 11, line 7 skipping to change at page 11, line 7
"pre-configuration-script"), while other implementations convey it "pre-configuration-script"), while other implementations convey it
inside the SZTP "configuration" node. inside the SZTP "configuration" node.
Following are two examples of conveying the signed certificate inside Following are two examples of conveying the signed certificate inside
the "configuration" node. Both examples assume that the SZTP-client the "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). As manufacturer-generated identity certificate (e.g., an IDevID, from
such, the configuration needs to associate the newly signed [Std-802.1AR-2018]). As such, the configuration needs to associate
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 ================
{ {
"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\
skipping to change at page 13, line 12 skipping to change at page 13, line 12
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 an normative
references to [RFC2986] and [ITU.X690.2015], and an informative references to [RFC2986] and [ITU.X690.2015], and an informative
reference to [Std-802.1AR-2018]. reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2020-10-02.yang" <CODE BEGINS> file "ietf-sztp-csr@2020-11-16.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 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)";
} }
skipping to change at page 14, line 26 skipping to change at page 14, line 26
(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 2020-10-02 { revision 2020-11-16 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC XXXX: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
identity certificate-request-format { identity certificate-request-format {
description description
skipping to change at page 23, line 37 skipping to change at page 23, line 37
In cases where the device does not possess an HSM, or otherwise is In cases where the device does not possess an HSM, or otherwise is
unable to use an HSM for the private key, it is RECOMMENDED to unable to use an HSM for the private key, it is RECOMMENDED to
regenerate the private key (and associated identity certificates) regenerate the private key (and associated identity certificates)
periodically. Details for how to generate a new private key and periodically. Details for how to generate a new private key and
associate a new identity certificate are outside the scope of this associate a new identity certificate are outside the scope of this
document. document.
3.1.2. Reuse of a Manufacturer-generated Private Key 3.1.2. Reuse of a Manufacturer-generated Private Key
It is RECOMMENDED in [RFC8572] that devices are shipped from It is RECOMMENDED that a new private key is generated for each CSR
manufacturing with a secure device identity certificate (e.g., an described in this document.
IDevID, from [Std-802.1AR-2018]). It is also RECOMMENDED that the
private key for these necessarily long-lived certificates be stored
in an HSM, such as a TPM. Lastly, per the FIXME: guy says that the
the keys/certs aren't always stored in the TPM (see private email
from Aug 13th) previous consideration, when devices generate a new
private key, it is also RECOMMENDED that the private key is protected
by the HSM.
However, it is understood that space on an HSM chip may be limited, This private key SHOULD be protected as well as the built-in private
potentially to the point of not being able to store an additional key associated with the device's initial secure device identity
private key for the CSR described in this document, and that it may certificate (e.g., the IDevID, from [Std-802.1AR-2018]).
not be possible to store hardware-protected keys outside the TPM
(e.g., a TPM-encrypted key stored in non-volatile memory). In such In cases where it it not possible to generate a new private key that
cases, it is RECOMMENDED to reuse the existing hardware-protected is protected as well as the built-in private key, it is RECOMMENDED
private key rather than generate a second private key outside of to reuse the built-in private key rather then generate a new private
protection afforded by the hardware. 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
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.
 End of changes. 13 change blocks. 
33 lines changed or deleted 26 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/