< draft-ietf-netconf-sztp-csr-10.txt   draft-ietf-netconf-sztp-csr-11.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: 28 April 2022 S. Turner Expires: 12 May 2022 S. Turner
sn3rd sn3rd
25 October 2021 8 November 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-10 draft-ietf-netconf-sztp-csr-11
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 41 skipping to change at page 1, line 41
progress. Please apply the following replacements: progress. Please apply the following replacements:
* XXXX --> the assigned numerical RFC value for this draft * XXXX --> the assigned numerical RFC value for this draft
* AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types * AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types
Artwork in this document contains a placeholder value for the Artwork in this document contains a placeholder value for the
publication date of this draft. Please apply the following publication date of this draft. Please apply the following
replacement: replacement:
* 2021-10-25 --> the publication date of this draft * 2021-11-08 --> 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 28 April 2022. This Internet-Draft will expire on 12 May 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 29 skipping to change at page 3, line 29
4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30
4.2.3. Supporting SZTP-Clients that don't trust the 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 . . . . . . . . . . . . . . . . . . . . . . . . . 31 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Normative References . . . . . . . . . . . . . . . . . . 32 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
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-10-25.yang" <CODE BEGINS> file "ietf-sztp-csr@2021-11-08.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-10-25 { revision 2021-11-08 {
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-10-25.yang" <CODE BEGINS> file "ietf-ztp-types@2021-11-08.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-10-25 { revision 2021-11-08 {
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 30, line 19 skipping to change at page 30, line 19
key. Proof-of-possession of the private key is verified by ensuring key. Proof-of-possession of the private key is verified by ensuring
the signature over the CSR using the public key placed in the CSR. the signature over the CSR using the public key placed in the CSR.
4.2.2. Verifying Proof of Origin 4.2.2. Verifying Proof of Origin
When the bootstrapping device's manufacturer-generated private key When the bootstrapping device's manufacturer-generated private key
(e.g., the IDevID key) is reused for the CSR, proof-of-origin is (e.g., the IDevID key) is reused for the CSR, proof-of-origin is
verified by validating the IDevID-issuer cert and ensuring that the verified by validating the IDevID-issuer cert and ensuring that the
CSR uses the same key pair. CSR uses the same key pair.
When a new asymmetric key is used, proof-or-origin is provided, in
the CMP and CMC formats, by the CSR's parent ASN.1 structure
containing origin authentication using either the manufacturer-
generated private key or a shared secret.
When a new asymmetric key is used, with the CMP or CMC formats, the When a new asymmetric key is used, with the CMP or CMC formats, the
parent ASN.1 structure of the CSR provides origin authentication parent ASN.1 structure of the CSR provides origin authentication
using either the manufacturer-generated private key or a shared using either the manufacturer-generated private key or a shared
secret. In this way the proof-of-possession of the CSR is directly 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. 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 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
 End of changes. 11 change blocks. 
15 lines changed or deleted 10 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/