--- 1/draft-ietf-netconf-sztp-csr-00.txt 2020-11-16 12:13:24.368521117 -0800 +++ 2/draft-ietf-netconf-sztp-csr-01.txt 2020-11-16 12:13:24.424522539 -0800 @@ -1,22 +1,22 @@ NETCONF Working Group K. Watsen Internet-Draft Watsen Networks Updates: 8572 (if approved) R. Housley Intended status: Standards Track Vigil Security, LLC -Expires: 5 April 2021 S. Turner +Expires: 20 May 2021 S. Turner sn3rd - 2 October 2020 + 16 November 2020 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request - draft-ietf-netconf-sztp-csr-00 + draft-ietf-netconf-sztp-csr-01 Abstract This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. Editorial Note (To be removed by RFC Editor) @@ -31,21 +31,21 @@ * "XXXX" --> the assigned numerical RFC value for this draft * "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto- types Artwork in this document contains a placeholder value for the publication date of this draft. Please apply the following 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 in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: * I-D.ietf-netconf-crypto-types * I-D.ietf-netconf-keystore * I-D.ietf-netconf-trust-anchors @@ -60,21 +60,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -90,37 +90,37 @@ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 3.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 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.3. Replay Attack Protection . . . . . . . . . . . . . . 24 + 3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 23 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 Certificate . . . . . . . . . . . . . . . . . . . . . 25 3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25 3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25 3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25 3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 26 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 26 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 5.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 5.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 5.2. Informative References . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction 1.1. Overview This draft extends the "get-bootstrapping-data" RPC defined in [RFC8572] to include an optional certificate signing request (CSR) [RFC2986], enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of the "onboarding information" response provided in the RPC-reply. @@ -412,23 +412,23 @@ "pre-configuration-script"), while other implementations convey it inside the SZTP "configuration" node. Following are two examples of conveying the signed certificate inside the "configuration" node. Both examples assume that the SZTP-client understands the "ietf-keystore" module defined in [I-D.ietf-netconf-keystore]. This first example illustrates the case where the signed certificate is for the same asymmetric key used by the SZTP-client's - manufacturer-generated identity certificate (e.g., an IDevID). As - such, the configuration needs to associate the newly signed - certificate with the existing asymmetric key: + manufacturer-generated identity certificate (e.g., an IDevID, from + [Std-802.1AR-2018]). As such, the configuration needs to associate + the newly signed certificate with the existing asymmetric key: =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-keystore:keystore": { "asymmetric-keys": { "asymmetric-key": [ { "name": "Manufacturer-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ @@ -507,21 +507,21 @@ to use the "ietf-truststore" module defined in [I-D.ietf-netconf-trust-anchors]. 2.3. YANG Module This module augments an RPC defined in [RFC8572], uses a data type defined in [I-D.ietf-netconf-crypto-types], has an normative references to [RFC2986] and [ITU.X690.2015], and an informative reference to [Std-802.1AR-2018]. - file "ietf-sztp-csr@2020-10-02.yang" + file "ietf-sztp-csr@2020-11-16.yang" module ietf-sztp-csr { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; prefix sztp-csr; import ietf-sztp-bootstrap-server { prefix sztp-svr; reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; } @@ -569,21 +569,21 @@ (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2020-10-02 { + revision 2020-11-16 { description "Initial version"; reference "RFC XXXX: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } identity certificate-request-format { description @@ -1010,38 +1010,31 @@ 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 regenerate the private key (and associated identity certificates) periodically. Details for how to generate a new private key and associate a new identity certificate are outside the scope of this document. 3.1.2. Reuse of a Manufacturer-generated Private Key - It is RECOMMENDED in [RFC8572] that devices are shipped from - manufacturing with a secure device identity certificate (e.g., an - 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. + It is RECOMMENDED that a new private key is generated for each CSR + described in this document. - However, it is understood that space on an HSM chip may be limited, - potentially to the point of not being able to store an additional - private key for the CSR described in this document, and that it may - not be possible to store hardware-protected keys outside the TPM - (e.g., a TPM-encrypted key stored in non-volatile memory). In such - cases, it is RECOMMENDED to reuse the existing hardware-protected - private key rather than generate a second private key outside of - protection afforded by the hardware. + This private key SHOULD be protected as well as the built-in private + key associated with the device's initial secure device identity + certificate (e.g., the IDevID, from [Std-802.1AR-2018]). + + In cases where it it not possible to generate a new private key that + is protected as well as the built-in private key, it is RECOMMENDED + to reuse the built-in private key rather then generate a new private + key that is not as well protected. 3.1.3. Replay Attack Protection This RFC enables an SZTP-client to announce an ability to generate new key to use for its CSR. When the SZTP-server responds with a request for the device to generate a new key, it is essential that the device actually generates a new key.