< draft-ietf-netconf-sztp-csr-08.txt   draft-ietf-netconf-sztp-csr-09.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: 25 February 2022 S. Turner Expires: 25 April 2022 S. Turner
sn3rd sn3rd
24 August 2021 22 October 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-08 draft-ietf-netconf-sztp-csr-09
Abstract Abstract
This draft extends the "get-bootstrapping-data" RPC defined in RFC This draft extends the "get-bootstrapping-data" RPC defined in RFC
8572 to include an optional certificate signing request (CSR), 8572 to include an optional certificate signing request (CSR),
enabling a bootstrapping device to additionally obtain an identity enabling a bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
"onboarding information" response provided in the RPC-reply. "onboarding information" response provided in the RPC-reply.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. No other RFC summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document. Editor instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
* "XXXX" --> the assigned numerical RFC value for this draft * XXXX --> the assigned numerical RFC value for this draft
* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto- * 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-08-24" --> the publication date of this draft * 2021-10-22 --> 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 25 February 2022. This Internet-Draft will expire on 25 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 18 skipping to change at page 3, line 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27
4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27
4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27
4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28
4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28
4.1.5. Selecting the Best Origin Authentication Mechanism . 29 4.1.5. Selecting the Best Origin Authentication Mechanism . 29
4.1.6. Clearing the Private Key and Associated 4.1.6. Clearing the Private Key and Associated
Certificate . . . . . . . . . . . . . . . . . . . . . 29 Certificate . . . . . . . . . . . . . . . . . . . . . 29
4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29
4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 29 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30
4.2.2. Supporting SZTP-Clients that don't trust the 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30
4.2.3. Supporting SZTP-Clients that don't trust the
SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30
4.3. Security Considerations for the "ietf-sztp-csr" YANG 4.3. Security Considerations for the "ietf-sztp-csr" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 Module . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4. Security Considerations for the "ietf-ztp-types" YANG 4.4. Security Considerations for the "ietf-ztp-types" YANG
Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31
5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Normative References . . . . . . . . . . . . . . . . . . 31 6.1. Normative References . . . . . . . . . . . . . . . . . . 32
6.2. Informative References . . . . . . . . . . . . . . . . . 33 6.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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
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! +--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? 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 the generate CSRs. This
skipping to change at page 14, line 13 skipping to change at page 14, line 13
[I-D.ietf-netconf-trust-anchors]. [I-D.ietf-netconf-trust-anchors].
2.3. YANG Module 2.3. YANG Module
This module augments an RPC defined in [RFC8572]. The module uses a This module augments an RPC defined in [RFC8572]. The module uses a
data types and groupings defined in [RFC8572], [RFC8791], and data types and groupings defined in [RFC8572], [RFC8791], and
[I-D.ietf-netconf-crypto-types]. The module has additional normative [I-D.ietf-netconf-crypto-types]. The module has additional normative
references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015],
and an informative reference to [Std-802.1AR-2018]. and an informative reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-sztp-csr@2021-08-24.yang" <CODE BEGINS> file "ietf-sztp-csr@2021-10-22.yang"
module ietf-sztp-csr { module ietf-sztp-csr {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";
prefix sztp-csr; prefix sztp-csr;
import ietf-sztp-bootstrap-server { import ietf-sztp-bootstrap-server {
prefix sztp-svr; prefix sztp-svr;
reference reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)"; "RFC 8572: Secure Zero Touch Provisioning (SZTP)";
skipping to change at page 15, line 30 skipping to change at page 15, line 30
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices. itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision 2021-08-24 { revision 2021-10-22 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC XXXX: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
skipping to change at page 18, line 12 skipping to change at page 18, line 12
+--:(cmp-csr) +--:(cmp-csr)
+-- cmp-csr? binary +-- cmp-csr? binary
3.2. YANG Module 3.2. YANG Module
This module uses a data types and groupings [RFC8791] and This module uses a data types and groupings [RFC8791] and
[I-D.ietf-netconf-crypto-types]. The module has additional normative [I-D.ietf-netconf-crypto-types]. The module has additional normative
references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015],
and an informative reference to [Std-802.1AR-2018]. and an informative reference to [Std-802.1AR-2018].
<CODE BEGINS> file "ietf-ztp-types@2021-08-24.yang" <CODE BEGINS> file "ietf-ztp-types@2021-10-22.yang"
module ietf-ztp-types { module ietf-ztp-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";
prefix zt; prefix zt;
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; "RFC AAAA: YANG Data Types and Groupings for Cryptography";
skipping to change at page 19, line 20 skipping to change at page 19, line 20
(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-08-24 { revision 2021-10-22 {
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 29, line 13 skipping to change at page 29, line 13
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 pass 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].
4.1.5. Selecting the Best Origin Authentication Mechanism 4.1.5. Selecting the Best Origin Authentication Mechanism
A The CSR's origin SHOULD be verified before a certificate is issued. The origin of the CSR must be verified before a certificate is
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 does not support origin
authentication. authentication.
The CMP and CMC request formats support origin authentication using The CMP and CMC request formats support origin authentication using
skipping to change at page 29, line 46 skipping to change at page 30, line 4
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 [I-D.ietf-netmod-factory-default].
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
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
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.
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-possession is (e.g., the IDevID key) is reused for the CSR, proof-of-origin is
verified by ensuring the CSR was signed by that key. verified by ensuring the CSR was signed by that key.
When a new asymmetric key is used, proof-of-possession may be When a new asymmetric key is used, proof-or-origin is provided, in
verified, with the CMP or CMC formats, by ensuring the parent ASN.1 the CMP and CMC formats, by the CSR's parent ASN.1 structure
structure containing the CSR is signed by the manufacturer-generated containing origin authentication using either the manufacturer-
key. generated private key or a shared secret.
4.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server When a new asymmetric key is used, with the CMP or CMC formats, the
parent ASN.1 structure of the CSR provides origin authentication
using either the manufacturer-generated private key or a shared
secret. In this way the proof-of-possession of the CSR is directly
linked to the proof-or-origin provided by the parent ASN.1 structure.
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.
The reciprocal of this statement is that SZTP-servers, wanting to The reciprocal of this statement is that SZTP-servers, wanting to
support SZTP-clients that don't trust them, SHOULD support the support SZTP-clients that don't trust them, SHOULD support the
skipping to change at page 31, line 44 skipping to change at page 32, line 22
prefix: ztp-types prefix: ztp-types
reference: RFC XXXX reference: RFC XXXX
6. References 6. References
6.1. Normative References 6.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-20, 18 May 2021, ietf-netconf-crypto-types-21, 14 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf- <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
crypto-types-20>. crypto-types-21>.
[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
 End of changes. 24 change blocks. 
29 lines changed or deleted 63 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/