< draft-ietf-netconf-zerotouch-16.txt   draft-ietf-netconf-zerotouch-17.txt >
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track M. Abrahamsson Intended status: Standards Track M. Abrahamsson
Expires: March 2, 2018 T-Systems Expires: March 15, 2018 T-Systems
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
August 29, 2017 September 11, 2017
Zero Touch Provisioning for NETCONF or RESTCONF based Management Zero Touch Provisioning for NETCONF or RESTCONF based Management
draft-ietf-netconf-zerotouch-16 draft-ietf-netconf-zerotouch-17
Abstract Abstract
This draft presents a secure technique for establishing a NETCONF or This draft presents a secure technique for establishing a NETCONF or
RESTCONF connection between a newly deployed device, configured with RESTCONF connection between a newly deployed device, configured with
just its preconfigured initial state (e.g., factory default just its preconfigured initial state (e.g., factory default
settings), and its deployment specific network management system settings), and its deployment specific network management system
(NMS). (NMS).
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 48 skipping to change at page 1, line 48
the "DHCPv6 Zero Touch Option" option the "DHCPv6 Zero Touch Option" option
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:
o "XXXX" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2017-08-29" --> the publication date of this draft o "2017-09-11" --> the publication date of this draft
Please update the following references to reflect their final RFC Please update the following references to reflect their final RFC
assignments: assignments:
o I-D.ieft-netconf-netconf-client-server o I-D.ieft-netconf-netconf-client-server
The following one Appendix section is to be removed prior to The following one Appendix section is to be removed prior to
publication: publication:
o Appendix A. Change Log o Appendix A. Change Log
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 March 2, 2018. This Internet-Draft will expire on March 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 3, line 23 skipping to change at page 3, line 23
2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8 2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8
2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9 2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Zero Touch Information . . . . . . . . . . . . . . . . . 10 3.1. Zero Touch Information . . . . . . . . . . . . . . . . . 10
3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 10 3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 10
3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 11 3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 11
3.4. Artifact Groupings . . . . . . . . . . . . . . . . . . . 11 3.4. Artifact Groupings . . . . . . . . . . . . . . . . . . . 11
4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 12 4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 12
4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 12 4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 12
4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 15 4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 15
5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 17 5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Processing a Source of Bootstrapping Data . . . . . . . . 19 5.3. Processing a Source of Bootstrapping Data . . . . . . . . 19
5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 21 5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 21
5.5. Processing Redirect Information . . . . . . . . . . . . . 22 5.5. Processing Redirect Information . . . . . . . . . . . . . 22
5.6. Processing Onboarding Information . . . . . . . . . . . . 22 5.6. Processing Onboarding Information . . . . . . . . . . . . 22
6. The Zero Touch Information Artifact . . . . . . . . . . . . . 23 6. The Zero Touch Information Artifact . . . . . . . . . . . . . 23
6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 23
6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 24
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
7. The Zero Touch Bootstrap Server API . . . . . . . . . . . . . 32 7. The Zero Touch Bootstrap Server API . . . . . . . . . . . . . 32
7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 32 7.1. API Overview . . . . . . . . . . . . . . . . . . . . . . 32
7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 33 7.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 33
7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 35 7.3. Example Usage . . . . . . . . . . . . . . . . . . . . . . 34
8. DHCP Zero Touch Options . . . . . . . . . . . . . . . . . . . 43 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. DHCPv4 Zero Touch Option . . . . . . . . . . . . . . . . 43 8. DHCP Zero Touch Options . . . . . . . . . . . . . . . . . . . 44
8.2. DHCPv6 Zero Touch Option . . . . . . . . . . . . . . . . 44 8.1. DHCPv4 Zero Touch Option . . . . . . . . . . . . . . . . 45
8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 46 8.2. DHCPv6 Zero Touch Option . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 47
9.1. Immutable storage for trust anchors . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9.2. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 47 9.1. Immutable storage for trust anchors . . . . . . . . . . . 48
9.3. Blindly authenticating a bootstrap server . . . . . . . . 47 9.2. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 48
9.4. Entropy loss over time . . . . . . . . . . . . . . . . . 47 9.3. Blindly authenticating a bootstrap server . . . . . . . . 49
9.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 47 9.4. Entropy loss over time . . . . . . . . . . . . . . . . . 49
9.6. Sequencing Sources of Bootstrapping Data . . . . . . . . 48 9.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 49
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 9.6. Disclosing Information to Untrusted Servers . . . . . . . 49
9.7. Sequencing Sources of Bootstrapping Data . . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
10.1. The BOOTP Manufacturer Extensions and DHCP Options 10.1. The BOOTP Manufacturer Extensions and DHCP Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 48 Registry . . . . . . . . . . . . . . . . . . . . . . . . 50
10.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 48 10.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 50
10.3. The YANG Module Names Registry . . . . . . . . . . . . . 48 10.3. The YANG Module Names Registry . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 10.4. RESTCONF Capability URNs . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . 49 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Workflow Overview . . . . . . . . . . . . . . . . . 53 12.2. Informative References . . . . . . . . . . . . . . . . . 54
A.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 53 Appendix A. Workflow Overview . . . . . . . . . . . . . . . . . 55
A.2. Owner Stages the Network for Bootstrap . . . . . . . . . 55 A.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 55
A.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 57 A.2. Owner Stages the Network for Bootstrap . . . . . . . . . 57
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 60 A.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 59
B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Promoting a Connection from Untrusted to Trusted . . 62
B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 60 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 63
B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 60 C.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 63
B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 61 C.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 63
B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 61 C.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 61 C.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 62 C.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 62 C.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 64
B.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 62 C.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 62 C.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 62 C.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 63 C.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 63 C.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 65
B.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 63 C.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 66
B.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 64 C.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 66
B.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 64 C.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 67
B.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 64 C.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 C.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 67
C.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 68
C.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
A fundamental business requirement for any network operator is to A fundamental business requirement for any network operator is to
reduce costs where possible. For network operators, deploying reduce costs where possible. For network operators, deploying
devices to many locations can be a significant cost, as sending devices to many locations can be a significant cost, as sending
trained specialists to each site for installations is both cost trained specialists to each site for installations is both cost
prohibitive and does not scale. prohibitive and does not scale.
This document defines a bootstrapping strategy enabling devices to This document defines a bootstrapping strategy enabling devices to
skipping to change at page 6, line 7 skipping to change at page 6, line 9
Ownership Voucher, and Owner Certificate). These artifacts Ownership Voucher, and Owner Certificate). These artifacts
collectively provide all the bootstrapping data a device may use. collectively provide all the bootstrapping data a device may use.
Bootstrapping Data: The term "bootstrapping data" is used throughout Bootstrapping Data: The term "bootstrapping data" is used throughout
this document to refer to the collection of data that a device this document to refer to the collection of data that a device
may obtain during the bootstrapping process. Specifically, it may obtain during the bootstrapping process. Specifically, it
refers to the three artifacts defined in Section 3. refers to the three artifacts defined in Section 3.
Bootstrap Server: The term "bootstrap server" is used within this Bootstrap Server: The term "bootstrap server" is used within this
document to mean any RESTCONF server implementing the YANG module document to mean any RESTCONF server implementing the YANG module
defined in Section 7.3. defined in Section 7.4.
Device: The term "device" is used throughout this document to refer Device: The term "device" is used throughout this document to refer
to the network element that needs to be bootstrapped. See to the network element that needs to be bootstrapped. See
Section 5 for more information about devices. Section 5 for more information about devices.
Initial Secure Device Identifier (IDevID): The term "IDevID" is Initial Secure Device Identifier (IDevID): The term "IDevID" is
defined in [Std-802.1AR-2009] as the globally unique secure defined in [Std-802.1AR-2009] as the globally unique secure
device identifier (DevID) installed on the device by the device identifier (DevID) installed on the device by the
manufacturer. This identifier is used in this document to enable manufacturer. This identifier is used in this document to enable
a Bootstrap Server to securely identify and authenticate a a Bootstrap Server to securely identify and authenticate a
skipping to change at page 6, line 34 skipping to change at page 6, line 36
throughout this document to refer to the deployment specific throughout this document to refer to the deployment specific
management system that the bootstrapping process is responsible management system that the bootstrapping process is responsible
for introducing devices to. From a device's perspective, when for introducing devices to. From a device's perspective, when
the bootstrapping process has completed, the NMS is a NETCONF or the bootstrapping process has completed, the NMS is a NETCONF or
RESTCONF client. RESTCONF client.
Onboarding Information: The term "onboarding information" is used Onboarding Information: The term "onboarding information" is used
herein to refer to one of the two types of 'zero touch herein to refer to one of the two types of 'zero touch
information' (see term) defined in this document, the other being information' (see term) defined in this document, the other being
'redirect information'. Specifically, onboarding information is 'redirect information'. Specifically, onboarding information is
defined by the 'onboarding-information' YANG-data struture in defined by the 'onboarding-information' YANG-data structure in
Section 6.3. Section 6.3.
Owner: The term "owner" is used throughout this document to refer to Owner: The term "owner" is used throughout this document to refer to
the person or organization that purchased or otherwise owns a the person or organization that purchased or otherwise owns a
device. device.
Owner Certificate: The term "owner certificate" is used in this Owner Certificate: The term "owner certificate" is used in this
document to represent an X.509 certificate that binds an owner document to represent an X.509 certificate that binds an owner
identity to a public key, which a device can use to validate a identity to a public key, which a device can use to validate a
signature over the zero touch information artifacts. The owner signature over the zero touch information artifacts. The owner
skipping to change at page 13, line 19 skipping to change at page 13, line 25
From an artifact perspective, since a removable storage device From an artifact perspective, since a removable storage device
presents itself as a filesystem, the bootstrapping artifacts need to presents itself as a filesystem, the bootstrapping artifacts need to
be presented as files. The three artifacts defined in Section 3 are be presented as files. The three artifacts defined in Section 3 are
mapped to files below. mapped to files below.
Artifact to File Mapping: Artifact to File Mapping:
Zero Touch Information: Mapped to a file containing the binary Zero Touch Information: Mapped to a file containing the binary
artifact described in Section 3.1 (e.g., zerotouch- artifact described in Section 3.1 (e.g., zerotouch-
information.pkcs7). information.pk7).
Owner Certificate: Mapped to a file containing the binary Owner Certificate: Mapped to a file containing the binary
artifact described in Section 3.2 (e.g., owner- artifact described in Section 3.2 (e.g., owner-
certificate.pkcs7). certificate.pk7).
Ownership Voucher: Mapped to a file containing the binary Ownership Voucher: Mapped to a file containing the binary
artifact described in Section 3.3 (e.g., ownership- artifact described in Section 3.3 (e.g., ownership-
voucher.pkcs7). voucher.pk7).
The format of the removable storage device's filesystem and the The format of the removable storage device's filesystem and the
naming of the files are outside the scope of this document. However, naming of the files are outside the scope of this document. However,
in order to facilitate interoperability, it is RECOMMENDED devices in order to facilitate interoperability, it is RECOMMENDED devices
support open and/or standards based filesystems. It is also support open and/or standards based filesystems. It is also
RECOMMENDED that devices assume a file naming convention that enables RECOMMENDED that devices assume a file naming convention that enables
more than one instance of bootstrapping data to exist on a removable more than one instance of bootstrapping data to exist on a removable
storage device. The file naming convention SHOULD be unique to the storage device. The file naming convention SHOULD be unique to the
manufacturer, in order to enable bootstrapping data from multiple manufacturer, in order to enable bootstrapping data from multiple
manufacturers to exist on a removable storage device. manufacturers to exist on a removable storage device.
skipping to change at page 15, line 44 skipping to change at page 15, line 52
4.4. Bootstrap Server 4.4. Bootstrap Server
A bootstrap server MAY be used as a source of zero touch A bootstrap server MAY be used as a source of zero touch
bootstrapping data. A bootstrap server is defined as a RESTCONF bootstrapping data. A bootstrap server is defined as a RESTCONF
[RFC8040] server implementing the YANG module provided in Section 7. [RFC8040] server implementing the YANG module provided in Section 7.
Unlike any other source of bootstrap data described in this document, Unlike any other source of bootstrap data described in this document,
a bootstrap server is not only a source of data, but it can also a bootstrap server is not only a source of data, but it can also
receive data from devices using the YANG-defined 'update-progress' receive data from devices using the YANG-defined 'update-progress'
action defined in the YANG module (Section 7.3). The data sent from action defined in the YANG module (Section 7.4). The data sent from
devices both enables visibility into the bootstrapping process (e.g., devices both enables visibility into the bootstrapping process (e.g.,
warnings and errors) as well as provides potentially useful warnings and errors) as well as provides potentially useful
completion status information (e.g., the device's SSH host-keys). completion status information (e.g., the device's SSH host-keys).
To use a bootstrap server as a source of bootstrapping data, a device To use a bootstrap server as a source of bootstrapping data, a device
MUST use the RESTCONF protocol to access the YANG container node MUST use the RESTCONF protocol to access the YANG container node
/device, passing its unique identifier in the URL as the key to the /device, passing its unique identifier in the URL as the key to the
'device' list. 'device' list.
Using a bootstrap server as a source of bootstrapping data is a Using a bootstrap server as a source of bootstrapping data is a
skipping to change at page 16, line 33 skipping to change at page 16, line 39
When a device is able to trust a bootstrap server, it MUST send its When a device is able to trust a bootstrap server, it MUST send its
IDevID certificate in the form of a TLS client certificate, and it IDevID certificate in the form of a TLS client certificate, and it
MUST send progress updates to the bootstrap server. When a device is MUST send progress updates to the bootstrap server. When a device is
not able to trust a bootstrap server, it MUST NOT send its IDevID not able to trust a bootstrap server, it MUST NOT send its IDevID
certificate in the form of a TLS client certificate, and it MUST NOT certificate in the form of a TLS client certificate, and it MUST NOT
send any progress updates to the bootstrap server. send any progress updates to the bootstrap server.
From an artifact perspective, since a bootstrap server presents data From an artifact perspective, since a bootstrap server presents data
as a YANG-modeled data, the bootstrapping artifacts need to be mapped as a YANG-modeled data, the bootstrapping artifacts need to be mapped
to nodes in the YANG module. The three artifacts defined in to nodes in the YANG module. The three artifacts defined in
Section 3 are mapped to bootstrap server nodes defined in Section 7.3 Section 3 are mapped to bootstrap server nodes defined in Section 7.4
below. below.
Artifact to Bootstrap Server Node Mapping: Artifact to Bootstrap Server Node Mapping:
Zero Touch Information: Mapped to the leaf node /device/ Zero Touch Information: Mapped to the leaf node /device/
zerotouch-information. zerotouch-information.
Owner Certificate: Mapped to the leaf node /device/owner- Owner Certificate: Mapped to the leaf node /device/owner-
certificate. certificate.
skipping to change at page 19, line 20 skipping to change at page 19, line 22
of bootstrapping data, it runs with the new bootstrapped of bootstrapping data, it runs with the new bootstrapped
configuration. configuration.
4. Otherwise the device MAY loop back through the list of 4. Otherwise the device MAY loop back through the list of
bootstrapping sources again and/or wait for manual provisioning. bootstrapping sources again and/or wait for manual provisioning.
5.3. Processing a Source of Bootstrapping Data 5.3. Processing a Source of Bootstrapping Data
This section describes a recursive algorithm that devices can use to, This section describes a recursive algorithm that devices can use to,
ultimately, obtain onboarding information. The algorithm is ultimately, obtain onboarding information. The algorithm is
recursive only because sources of bootstrapping data MAY return recursive because sources of bootstrapping data MAY return redirect
redirect information, which causes the algorithm to run again, for information, which causes the algorithm to run again, for the newly
the newly discovered sources of information. To be clear, an discovered sources of bootstrapping information. An ANBF-like
expression that captures all possible combinations is "(redirect expression that captures all possible sequences of bootstrapping
information)* onboarding information". That is, zero or more information is "(redirect information)* onboarding information".
redirect information responses, followed by one bootstrap information That is, zero or more redirect information responses, followed by one
response. bootstrap information response.
An important aspect of the algorithm is knowing when data needs to be An important aspect of the algorithm is knowing when data needs to be
signed or not. The following figure provides a summary of options: signed or not. The following figure provides a summary of options:
Untrusted Source Trusted Source Untrusted Source Trusted Source
Kind of Bootstrapping Data Can Provide? Can Provide? Kind of Bootstrapping Data Can Provide? Can Provide?
Unsigned Redirect Info : Yes+ Yes Unsigned Redirect Info : Yes+ Yes
Signed Redirect Info : Yes Yes* Signed Redirect Info : Yes Yes*
Unsigned Onboarding Info : No Yes Unsigned Onboarding Info : No Yes
Signed Onboarding Info : Yes Yes* Signed Onboarding Info : Yes Yes*
The '+' above denotes that the source redirected to MUST The '+' above denotes that the source redirected to MUST
return signed data, or more unsigned redirect information. return signed data, or more unsigned redirect information.
The '*' above denotes that, while possible, it is generally The '*' above denotes that, while possible, it is generally
unnecessary for a trusted source to return signed data. In unnecessary for a trusted source to return signed data. In
fact, it's only needed when the '+' case occurs. fact, it's only needed when the '+' case occurs.
As an example, imagine a device initially obtains unsigned redirect The recursive algorithm uses a conceptual global-scoped variable
information, which redirects it to an [untrusted] bootstrap server called "trust-state". The trust-state variable is initialized to
where it obtains more unsigned redirect information, which redirects FALSE. The ultimate goal of this algorithm is for the device to
it to another [untrusted] bootstrap server where it obtains signed process onboarding information (Section 2.2) while the trust-state
redirect information, which redirects it to a [trusted] bootstrap variable is TRUE.
server where it obtains redirect information (signed or unsigned
doesn't matter, its trusted either way), but without an included
trust anchor certificate, which is unexpected but possible, so the
device can't trust the server it's redirected to, and so on, until
finally the device obtains some onboarding information.
To support this behavior, this recursive algorithm uses a
conceptually global-scoped algorithm variable called "trust-state".
The trust-state variable is initialized to FALSE. The ultimate goal
of this algorithm is for the device to process onboarding information
(Section 2.2) while the trust-state variable is TRUE.
If the data source is a bootstrap server, the only source of If the data source is a bootstrap server, and the device is able to
bootstrapping data defined in this document that can be trusted via authenticate the bootstrap server using X.509 certificate path
transport level security, and the device is able to authenticate the validation ([RFC6125], Section 6) to one of the device's
server using X.509 certificate path validation ([RFC6125], Section 6) preconfigured trust anchors, or to a trust anchor that it learned
to one of the device's preconfigured trust anchors, or to a trust from a previous step, then the device MUST set trust-state to TRUE.
anchor that it learned from a previous step, then the device MUST set
trust-state to TRUE.
If trust-state is TRUE, when connecting to the bootstrap server, the If trust-state is TRUE, when connecting to the bootstrap server, the
device MUST use its IDevID certificate for client certificate based device MUST use its IDevID certificate for client certificate based
authentication and MUST post progress updates using the bootstrap authentication and MUST post progress updates using the bootstrap
server's "update-progress" action. Otherwise, if trust-state is server's "update-progress" action. Otherwise, if trust-state is
FALSE, when connecting to the bootstrap server, the device MUST NOT FALSE, when connecting to the bootstrap server, the device MUST NOT
use its IDevID certificate for a client certificate based use its IDevID certificate for a client certificate based
authentication and MUST NOT post progress updates using the bootstrap authentication and MUST NOT post progress updates using the bootstrap
server's "update-progress" action. server's "update-progress" action.
skipping to change at page 21, line 16 skipping to change at page 21, line 7
If the data is redirect information, the device MUST process the If the data is redirect information, the device MUST process the
redirect information as described in Section 5.5. This is the redirect information as described in Section 5.5. This is the
recursion step, it will cause to device to reenter this algorithm, recursion step, it will cause to device to reenter this algorithm,
but this time the data source will most definitely be a bootstrap but this time the data source will most definitely be a bootstrap
server, as that is all redirect information is able to redirect a server, as that is all redirect information is able to redirect a
device to. device to.
5.4. Validating Signed Data 5.4. Validating Signed Data
Whenever a device is presented signed data from an untrusted source, Whenever a device is presented signed data, it MUST validate the
it MUST validate the signed data as described in this section. If signed data as described in this section. This includes the case
the signed data is provided by a trusted source, a redundant trust where the signed data is provided by a trusted source.
case, the device MAY skip verifying the signature.
Whenever there is signed data, the device MUST also be provided an Whenever there is signed data, the device MUST also be provided an
ownership voucher and an owner certificate. How all the needed ownership voucher and an owner certificate. How all the needed
artifacts are provided for each source of bootstrapping data is artifacts are provided for each source of bootstrapping data is
defined in Section 4. defined in Section 4.
The device MUST first authenticate the ownership voucher by The device MUST first authenticate the ownership voucher by
validating the signature on it to one of its preconfigured trust validating the signature on it to one of its preconfigured trust
anchors (see Section 5.1). If the device has an accurate clock, it anchors (see Section 5.1), which may entail using additional
MUST ensure that the ownership voucher was created in the past (i.e., intermediate certificates attached to the ownership voucher. If the
'created-on' < now). If the 'expires-on' leaf is present, the device device has an accurate clock, it MUST ensure that the ownership
MUST verify that the ownership voucher has not yet expired (i.e., now voucher was created in the past (i.e., 'created-on' < now). If the
< 'expires-on'), which requires an accurate clock. The device MUST 'expires-on' leaf is present, the device MUST verify that the
verify that the ownership voucher's 'assertion' value is acceptable ownership voucher has not yet expired (i.e., now < 'expires-on'),
(e.g., some devices may only accept the assertion value 'verified'). which requires an accurate clock. The device MUST verify that the
The device MUST verify that the ownership voucher specifies the ownership voucher's 'assertion' value is acceptable (e.g., some
device's serial number in the 'serial-number' leaf. If the 'idevid- devices may only accept the assertion value 'verified'). The device
issuer' leaf is present, the device MUST verify that the value is set MUST verify that the ownership voucher specifies the device's serial
correctly. If the authentication of the ownership voucher is number in the 'serial-number' leaf. If the 'idevid-issuer' leaf is
successful, the device extracts the 'pinned-domain-certificate' node, present, the device MUST verify that the value is set correctly. If
an X.509 certificate, that is needed to verify the owner certificate the authentication of the ownership voucher is successful, the device
in the next step. extracts the 'pinned-domain-certificate' node, an X.509 certificate,
that is needed to verify the owner certificate in the next step.
The device MUST next authenticate the owner certificate by performing The device MUST next authenticate the owner certificate by performing
X.509 certificate path verification to the trusted certificate X.509 certificate path verification to the trusted certificate
extracted from the voucher's 'pinned-domain-cert' node. If the extracted from the voucher's 'pinned-domain-cert' node. This
ownership voucher's 'domain-cert-revocation-checks' node's value is verification may entail using additional intermediate certificates
set to "true", the device MUST verify the revocation status of the attached to the owner certificate artifact. If the ownership
voucher's 'domain-cert-revocation-checks' node's value is set to
"true", the device MUST verify the revocation status of the
certificate chain used to sign the owner certificate and, if the certificate chain used to sign the owner certificate and, if the
revocation status is not attainable or if it is determined that a revocation status is not attainable or if it is determined that a
certificate has been revoked, the device MUST not validate the owner certificate has been revoked, the device MUST not validate the owner
certificate. certificate.
Finally the device MUST verify the signature over information Finally the device MUST verify the signature over information
artifact was generated by the private key matching the public key artifact was generated by the private key matching the public key
from the owner certificate. from the owner certificate.
If any of these steps fail, then the device MUST mark the data as If any of these steps fail, then the device MUST mark the data as
skipping to change at page 23, line 49 skipping to change at page 23, line 43
MUST post the 'bootstrap-complete' progress update now, using the MUST post the 'bootstrap-complete' progress update now, using the
bootstrap server's 'update-progress' action. bootstrap server's 'update-progress' action.
At this point the device is running its initial configuration. At this point the device is running its initial configuration.
Notably, if NETCONF Call Home or RESTCONF Call Home [RFC8071] is Notably, if NETCONF Call Home or RESTCONF Call Home [RFC8071] is
configured, the device initiates trying to establish a call home configured, the device initiates trying to establish a call home
connection at this time. connection at this time.
6. The Zero Touch Information Artifact 6. The Zero Touch Information Artifact
This section defines a YANG [RFC6020] module that is used to define This section defines a YANG 1.1 [RFC7950] module that is used to
the data model for the zero touch information artifact described in define the data model for the zero touch information artifact
Section 3.1. Examples illustrating this artifact in use are provided described in Section 3.1. Examples illustrating this artifact in use
in Section 6.2. are provided in Section 6.2.
6.1. Tree Diagram 6.1. Data Model Overview
The following tree diagram provides an overview of the data model for The following tree diagram provides an overview of the data model for
the zero touch information artifact. The syntax used for this tree the zero touch information artifact. The syntax used for this tree
diagram is described in Section 1.4. diagram is described in Section 1.4.
module: ietf-zerotouch-information module: ietf-zerotouch-information
yang-data: yang-data:
zerotouch-information zerotouch-information
+---- (information-type) +---- (information-type)
+--:(redirect-information) +--:(redirect-information)
skipping to change at page 27, line 13 skipping to change at page 27, line 13
</onboarding-information> </onboarding-information>
6.3. YANG Module 6.3. YANG Module
The zero touch information artifact is normatively defined by the The zero touch information artifact is normatively defined by the
YANG module defined in this section. YANG module defined in this section.
Note: the module defined herein uses data types defined in [RFC5280], Note: the module defined herein uses data types defined in [RFC5280],
[RFC6234], and [RFC6991]. [RFC6234], and [RFC6991].
<CODE BEGINS> file "ietf-zerotouch-information@2017-08-29.yang" <CODE BEGINS> file "ietf-zerotouch-information@2017-09-11.yang"
module ietf-zerotouch-information { module ietf-zerotouch-information {
yang-version "1.1"; yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-information"; namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-information";
prefix "zti"; prefix "zti";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
} }
skipping to change at page 28, line 9 skipping to change at page 28, line 9
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision "2017-08-29" { revision "2017-09-11" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based
Management"; Management";
} }
rc:yang-data zerotouch-information { rc:yang-data zerotouch-information {
choice information-type { choice information-type {
skipping to change at page 32, line 22 skipping to change at page 32, line 22
reset that will force a new boot-image install (wiping out reset that will force a new boot-image install (wiping out
anything the script may have done) and restart the entire anything the script may have done) and restart the entire
bootstrapping process again."; bootstrapping process again.";
} }
} }
<CODE ENDS> <CODE ENDS>
7. The Zero Touch Bootstrap Server API 7. The Zero Touch Bootstrap Server API
This section defines a YANG [RFC6020] module that is used to define This section defines the API for bootstrap servers. The API is
the RESTCONF [RFC8040] API used by the bootstrap server defined in defined as the API produced by a RESTCONF [RFC8040] server that
Section 4.4. Examples illustrating this API in use are provided in supports the YANG 1.1 [RFC7950] module defined in this section. The
Section 7.2. bootstrap server MAY also support the query parameters defined in
this section.
7.1. Tree Diagram 7.1. API Overview
The following tree diagram provides an overview for the bootstrap The following tree diagram provides an overview for the bootstrap
server RESTCONF API. The syntax used for this tree diagram is server RESTCONF API. The syntax used for this tree diagram is
described in Section 1.4. described in Section 1.4.
module: ietf-zerotouch-bootstrap-server module: ietf-zerotouch-bootstrap-server
+--ro device* [unique-id] +--ro device* [unique-id]
+--ro unique-id string +--ro unique-id string
+--ro zerotouch-information pkcs7 +--ro zerotouch-information pkcs7
+--ro owner-certificate? pkcs7 +--ro owner-certificate? pkcs7
skipping to change at page 33, line 12 skipping to change at page 33, line 12
+---w protocol* enumeration +---w protocol* enumeration
+---w certificate pkcs7 +---w certificate pkcs7
In the above diagram, notice that all of the protocol accessible In the above diagram, notice that all of the protocol accessible
nodes are read-only, to assert that devices can only pull data from nodes are read-only, to assert that devices can only pull data from
the bootstrap server. the bootstrap server.
Also notice that the module defines an action statement, which Also notice that the module defines an action statement, which
devices use to provide progress updates to the bootstrap server. devices use to provide progress updates to the bootstrap server.
7.2. Example Usage 7.2. Query Parameters
Bootstrap servers may optionally support the query parameters defined
in this section.
o The "os-name" Query Parameter
The "os-name" query parameter indicates the name of the
operating system the device is running. This parameter is only
needed if it is possible for the device, as identified by its
<unique-id> to run more than one type of operating system.
This query parameter MUST be supported by servers needing to
support such devices.
HTTP Methods: GET, HEAD
Capability URI: urn:ietf:params:restconf:capability:os-name:1.0
o The "os-version" Query Parameter
The "os-version" query parameter indicates the version of the
operating system the device is running. This parameter enables
the server to dynamically generate an optimal response for the
device negating, for instance, the need for a potentially
expensive boot-image update. This query parameter MUST be
supported by servers wanting to support such use-cases.
HTTP Methods: GET, HEAD
Capability URI: urn:ietf:params:restconf:capability:os-
version:1.0
o The "circuit-id" Query Parameter
The "circuit-id" query parameter, along with the "remote-id"
query parameter, enables a device to propagate information
collected (e.g., via DHCP Option 82) to the bootstrap server.
This information enables the bootstrap server to return a
customized response independent of the device's unique
identifier.
HTTP Methods: GET, HEAD
Capability URI: urn:ietf:params:restconf:capability:circuit-
id:1.0
o The "remote-id" Query Parameter
The "remote-id" query parameter, along with the "circuit-id"
query parameter, enables a device to propogate information
collected (e.g., via DHCP Option 82) to the bootstrap server.
This information enables the bootstrap server to return a
customized response independent of the device's unique
identifier.
HTTP Methods: GET, HEAD
Capability URI: urn:ietf:params:restconf:capability:remote-
id:1.0
o The "nonce" Query Parameter
The "nonce" query parameter enables a device without an
accurate clock to obtain a one-time use voucher, as opposed to
a never-expiring voucher that it would otherwise receive. This
query parameter is only useful for cases where the device is
connected to an untrusted bootstrap server, when signed data
must be returned. The bootstrap server uses backend APIs not
described in this document to dynamically obtain the one-time
use voucher from the device's manufacturer.
HTTP Methods: GET, HEAD
Capability URI: urn:ietf:params:restconf:capability:nonce:1.0
7.3. Example Usage
This section presents some examples illustrating the bootstrap This section presents some examples illustrating the bootstrap
server's API. Two examples are provided, one illustrating a device server's API. Two examples are provided, one illustrating a device
fetching bootstrapping data from the server, and the other fetching bootstrapping data from the server, and the other
illustrating a data posting a progress updates to the server. illustrating a data posting a progress updates to the server.
The following example illustrates a device using the API to fetch its The following example illustrates a device using the API to fetch its
bootstrapping data from the bootstrap server. In this example, the bootstrapping data from the bootstrap server. In this example, the
device receives a signed response; an unsigned response would look device receives a signed response; an unsigned response would look
similar except the last two fields (owner-certificate and ownership- similar except the last two fields (owner-certificate and ownership-
skipping to change at page 35, line 25 skipping to change at page 37, line 6
</action> </action>
</rpc> </rpc>
RESPONSE RESPONSE
-------- --------
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server Server: example-server
7.3. YANG Module 7.4. YANG Module
The bootstrap server's device-facing API is normatively defined by The bootstrap server's device-facing API is normatively defined by
the YANG module defined in this section. the YANG module defined in this section.
Note: the module defined herein uses data types defined in [RFC2315], Note: the module defined herein uses data types defined in [RFC2315],
[RFC5280], and [I-D.ietf-anima-voucher]. [RFC5280], and [I-D.ietf-anima-voucher].
<CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2017-08-29.yang" <CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2017-09-11.yang"
module ietf-zerotouch-bootstrap-server { module ietf-zerotouch-bootstrap-server {
yang-version "1.1"; yang-version "1.1";
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
prefix "ztbs"; prefix "ztbs";
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
skipping to change at page 36, line 20 skipping to change at page 37, line 48
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision "2017-08-29" { revision "2017-09-11" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based
Management"; Management";
} }
// typedefs // typedefs
typedef pkcs7 { typedef pkcs7 {
skipping to change at page 37, line 5 skipping to change at page 38, line 32
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER).";
} }
// protocol accessible nodes // protocol accessible nodes
list device { list device {
key unique-id; key unique-id;
config false; config false;
description description
"A device's record entry. This is the only RESTCONF resource "A device record containing bootstrapping data for the device
that a device will GET, as described in Section 8.2 in RFC XXXX. with the specified identifier. This top-level node provides
Getting just this top-level node provides a device with all the a device with all the data it needs in a single request.";
data it needs in a single request.";
reference reference
"RFC XXXX: Zero Touch Provisioning for NETCONF or "RFC XXXX: Zero Touch Provisioning for NETCONF or
RESTCONF based Management"; RESTCONF based Management";
leaf unique-id { leaf unique-id {
type string; type string;
description description
"A unique identifier for the device (e.g., serial number). "A unique identifier for the device (e.g., serial number).
Each device accesses its bootstrapping record by its unique Each device accesses its bootstrapping record by its unique
identifier."; identifier.";
skipping to change at page 38, line 35 skipping to change at page 40, line 12
description description
"An owner certificate must be present whenever an ownership "An owner certificate must be present whenever an ownership
voucher is presented."; voucher is presented.";
} }
description description
"A 'voucher' artifact, as described in Section 5 of "A 'voucher' artifact, as described in Section 5 of
I-D.ietf-anima-voucher. The voucher informs the device I-D.ietf-anima-voucher. The voucher informs the device
who it's 'owner' is. The voucher encodes the device's who it's 'owner' is. The voucher encodes the device's
serial number, so that the device can be ensured that serial number, so that the device can be ensured that
the voucher applies to it. The voucher is signed by the voucher applies to it. The voucher is signed by
the device's manufacturer or delagate."; the device's manufacturer or delegate.";
reference reference
"I-D.etf-anima-voucher: "I-D.etf-anima-voucher:
Voucher and Voucher Revocation Profiles for Bootstrapping Voucher and Voucher Revocation Profiles for Bootstrapping
Protocols"; Protocols";
} }
action update-progress { action update-progress {
input { input {
leaf update-type { leaf update-type {
type enumeration { type enumeration {
skipping to change at page 48, line 8 skipping to change at page 49, line 37
This draft uses the device's serial number both in the IDevID This draft uses the device's serial number both in the IDevID
certificate as well as in the bootstrap server API. Serial numbers certificate as well as in the bootstrap server API. Serial numbers
are ubiquitous and prominently contained in invoices and on labels are ubiquitous and prominently contained in invoices and on labels
affixed to devices and their packaging. That said, serial numbers affixed to devices and their packaging. That said, serial numbers
many times encode revealing information, such as the device's model many times encode revealing information, such as the device's model
number, manufacture date, and/or sequence number. Knowledge of this number, manufacture date, and/or sequence number. Knowledge of this
information may provide an adversary with details needed to launch an information may provide an adversary with details needed to launch an
attack. attack.
9.6. Sequencing Sources of Bootstrapping Data 9.6. Disclosing Information to Untrusted Servers
This document enables devices to establish provisional connections to
untrusted bootstrap servers, in order for the server to provide
signed data to the device. However, since the server is untrusted,
it may be under the control of an adversary, and therefore devices
should be cautious about the data they send in such cases.
Already this document prevents devices from sending either their
IDevID certificate or their progress updates to untrusted servers,
however potentially identifying values (e.g., unique-id, os-name, os-
version) are still potentially encoded in the HTTP request sent to
the servers. This information could be used by an adversary to mount
an attack against the device.
Devices concerned about such disclosures, when connecting to an
untrusted server, should 1) use a 'unique-id' value that is not
easily associated to the type of device it is (e.g., use a key
derivation function over the unique-id value) and 2) be very
selective about which HTTP query parameters are sent (ideally none).
Building on top of the recursive nature of the solution presented in
this document, a server, seeing that a device is following the
recommendation from the previous paragraph, should return signed
redirect information, not signed onboarding information, as would
normally be expected. The redirect information should point the
device back to the same server but, because the signed redirect
information contained the trust anchor certificate for the server,
the device would then establish a trusted connection to the server,
and thereby be able to freely send data to the server, including its
IDevID certificate, unique-id, query parameters, and various progress
updates. Please see Appendix B for more information on this.
9.7. Sequencing Sources of Bootstrapping Data
For devices supporting more than one source for bootstrapping data, For devices supporting more than one source for bootstrapping data,
no particular sequencing order has to be observed for security no particular sequencing order has to be observed for security
reasons, as the solution for each source is considered equally reasons, as the solution for each source is considered equally
secure. However, from a privacy perspective, it is RECOMMENDED that secure. However, from a privacy perspective, it is RECOMMENDED that
devices access local sources before accessing remote sources. devices access local sources before accessing remote sources.
10. IANA Considerations 10. IANA Considerations
10.1. The BOOTP Manufacturer Extensions and DHCP Options Registry 10.1. The BOOTP Manufacturer Extensions and DHCP Options Registry
skipping to change at page 49, line 15 skipping to change at page 51, line 29
name: ietf-zerotouch-information name: ietf-zerotouch-information
namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information
prefix: zti prefix: zti
reference: RFC XXXX reference: RFC XXXX
name: ietf-zerotouch-bootstrap-server name: ietf-zerotouch-bootstrap-server
namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server
prefix: ztbs prefix: ztbs
reference: RFC XXXX reference: RFC XXXX
10.4. RESTCONF Capability URNs
This document registers several capability identifiers in the
"RESTCONF Capability URNs" registry per [RFC8040]:
Index Capability Identifier
---------------------------------------------------------------------
:os-name urn:ietf:params:restconf:capability:os-name:1.0
:os-version urn:ietf:params:restconf:capability:os-version:1.0
:circuit-id urn:ietf:params:restconf:capability:circuit-id:1.0
:remote-id urn:ietf:params:restconf:capability:remote-id:1.0
:nonce urn:ietf:params:restconf:capability:nonce:1.0
11. Acknowledgements 11. Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): David Harrington, on list and in the halls (ordered by last name): David Harrington,
Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke,
Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, Russ Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, Russ
Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael
Richardson, Phil Shafer, Juergen Schoenwaelder. Richardson, Phil Shafer, Juergen Schoenwaelder.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for
brainstorming the original I-D's solution during the IETF 87 meeting brainstorming the original I-D's solution during the IETF 87 meeting
in Berlin. in Berlin.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-anima-voucher] [I-D.ietf-anima-voucher]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"Voucher Profile for Bootstrapping Protocols", draft-ietf- "Voucher Profile for Bootstrapping Protocols", draft-ietf-
anima-voucher-04 (work in progress), July 2017. anima-voucher-05 (work in progress), August 2017.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[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,
<http://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, <https://www.rfc- DOI 10.17487/RFC6762, February 2013,
editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>. <https://www.rfc-editor.org/info/rfc7227>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<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
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Std-802.1AR-2009] [Std-802.1AR-2009]
IEEE SA-Standards Board, "IEEE Standard for Local and IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
skipping to change at page 51, line 29 skipping to change at page 54, line 15
12.2. Informative References 12.2. Informative References
[I-D.ietf-netconf-netconf-client-server] [I-D.ietf-netconf-netconf-client-server]
Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client
and Server Models", draft-ietf-netconf-netconf-client- and Server Models", draft-ietf-netconf-netconf-client-
server-04 (work in progress), July 2017. server-04 (work in progress), July 2017.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
DOI 10.17487/RFC2939, September 2000, DOI 10.17487/RFC2939, September 2000,
<http://www.rfc-editor.org/info/rfc2939>. <https://www.rfc-editor.org/info/rfc2939>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017, RFC 8071, DOI 10.17487/RFC8071, February 2017,
<https://www.rfc-editor.org/info/rfc8071>. <https://www.rfc-editor.org/info/rfc8071>.
Appendix A. Workflow Overview Appendix A. Workflow Overview
The zero touch solution presented in this document is conceptualized The zero touch solution presented in this document is conceptualized
to be composed of the non-normative workflows described in this to be composed of the non-normative workflows described in this
section. Implementations details are expected to vary. Each diagram section. Implementations details are expected to vary. Each diagram
skipping to change at page 55, line 25 skipping to change at page 57, line 25
2. If the manufacturer's devices are able to validate signed data 2. If the manufacturer's devices are able to validate signed data
(Section 5.4), and assuming that the prospective owner's NMS is (Section 5.4), and assuming that the prospective owner's NMS is
able to prepare and sign the bootstrapping data itself, the able to prepare and sign the bootstrapping data itself, the
prospective owner's NMS might set a trust anchor certificate onto prospective owner's NMS might set a trust anchor certificate onto
the manufacturer's bootstrap server, using the credentials the manufacturer's bootstrap server, using the credentials
provided in the previous step. This certificate is the trust provided in the previous step. This certificate is the trust
anchor certificate that the prospective owner would like the anchor certificate that the prospective owner would like the
manufacturer to place into the ownership vouchers it generates, manufacturer to place into the ownership vouchers it generates,
thereby enabling devices to trust the owner's owner certificate. thereby enabling devices to trust the owner's owner certificate.
How this trust anchor certifiate is used to enable devices to How this trust anchor certificate is used to enable devices to
validate signed bootstrapping data is described in Section 5.4. validate signed bootstrapping data is described in Section 5.4.
3. Some time later, the prospective owner places an order with the 3. Some time later, the prospective owner places an order with the
manufacturer or delegate, perhaps with a special flag checked for manufacturer or delegate, perhaps with a special flag checked for
zero touch handling. At this time, or perhaps before placing the zero touch handling. At this time, or perhaps before placing the
order, the owner may model the devices in their NMS, creating order, the owner may model the devices in their NMS, creating
virtual objects for the devices with no real-world device virtual objects for the devices with no real-world device
associations. For instance the model can be used to simulate the associations. For instance the model can be used to simulate the
device's location in the network and the configuration it should device's location in the network and the configuration it should
have when fully operational. have when fully operational.
skipping to change at page 59, line 20 skipping to change at page 61, line 20
bootstrap server. bootstrap server.
* The contents of the initial configuration should configure an * The contents of the initial configuration should configure an
administrator account on the device (e.g., username, ssh-rsa administrator account on the device (e.g., username, ssh-rsa
key, etc.) and should configure the device either to listen key, etc.) and should configure the device either to listen
for NETCONF or RESTCONF connections or to initiate call home for NETCONF or RESTCONF connections or to initiate call home
connections [RFC8071]. connections [RFC8071].
* If the bootstrap server supports forwarding device progress * If the bootstrap server supports forwarding device progress
updates to external systems (e.g., via a webhook), a updates to external systems (e.g., via a webhook), a
"bootstrap-complete" progress update (Section 7.3) informs the "bootstrap-complete" progress update (Section 7.4) informs the
external system to know when it can, for instance, initiate a external system to know when it can, for instance, initiate a
connection to the device (assuming it knows the device's connection to the device (assuming it knows the device's
address and the device was configured to listen for address and the device was configured to listen for
connections). To support this further, the bootstrap-complete connections). To support this further, the bootstrap-complete
progress update may also relay the device's SSH host keys and/ progress update may also relay the device's SSH host keys and/
or TLS certificates, with which the external system can use to or TLS certificates, with which the external system can use to
authenticate subsequent connections to the device. authenticate subsequent connections to the device.
If the device successfully completes the bootstrapping process If the device successfully completes the bootstrapping process
(i.e., zerotouch bootstrapping is no longer configured), it exits (i.e., zerotouch bootstrapping is no longer configured), it exits
skipping to change at page 60, line 5 skipping to change at page 62, line 5
following the description provided in (3) above. following the description provided in (3) above.
5. After having tried all supported sources of bootstrapping data, 5. After having tried all supported sources of bootstrapping data,
the device may retry again all the sources and/or provide the device may retry again all the sources and/or provide
manageability interfaces for manual configuration (e.g., CLI, manageability interfaces for manual configuration (e.g., CLI,
HTTP, NETCONF, etc.). If manual configuration is allowed, and HTTP, NETCONF, etc.). If manual configuration is allowed, and
such configuration is provided, the device should cease trying to such configuration is provided, the device should cease trying to
obtain bootstrapping data, as the need to do so would no longer obtain bootstrapping data, as the need to do so would no longer
be present. be present.
Appendix B. Change Log Appendix B. Promoting a Connection from Untrusted to Trusted
B.1. ID to 00 The following diagram illustrates a sequence of bootstrapping
activities that promote an untrusted connection to a bootstrap server
to a trusted connection to the same bootstrap server.
+----------+
|Deployment|
| Specific |
+------+ |Bootstrap |
|Device| | Server |
+------+ +----------+
| |
| 1. "HTTPS" Request (GET /device=<kdf(unique-id)>) |
|------------------------------------------------------->|
| 2. "HTTPS" Response (signed redirect information) |
|<-------------------------------------------------------|
| |
| |
| 3. HTTPS Request (GET /device=unique-id?os-name=xyz) |
|------------------------------------------------------->|
| 4. HTTPS Response (unsigned onboarding information |
|<-------------------------------------------------------|
| |
The interactions in the above diagram are described below.
1. The device initiates an untrusted connection to a bootstrap
server, as is indicated by putting "HTTPS" in doublequotes above.
Because the device is unable to trust the server, it does not
send its IDevID certificate, or its raw unique id, or any HTTP
query parameters it may have. The diagram above uses
<kdf(unique-id)> to indicate that the device used a key
derivation function, KDF, over its unique-id to protect the
device's identity in case the server is owned by an adversary.
2. The bootstrap server iterates over some internal database of
devices until finding one for which the key derivation function
over its unique-id generates a match. In this example, the
bootstrap server wants the device to have a secure connection to
it so, rather than sending the device signed onboarding
information, it sends signed redirect information instead,
redirecting the device back to it again.
3. Upon validating the signed redirect information, the device
establishes a secure connection to the bootstrap server.
Unbeknownst to the device, it is the same bootstrap server it was
connected to previously. Because the device is able to
authenticate the bootstrap server, it sends its IDevID
certificate, raw unique-id, and any additional query parameters
it has ("os-name" shown above) to the bootstrap server.
4. This time the bootstrap server returns unsigned onboarding
information to the device.
Appendix C. Change Log
C.1. ID to 00
o Major structural update; the essence is the same. Most every o Major structural update; the essence is the same. Most every
section was rewritten to some degree. section was rewritten to some degree.
o Added a Use Cases section o Added a Use Cases section
o Added diagrams for "Actors and Roles" and "NMS Precondition" o Added diagrams for "Actors and Roles" and "NMS Precondition"
sections, and greatly improved the "Device Boot Sequence" diagram sections, and greatly improved the "Device Boot Sequence" diagram
o Removed support for physical presence or any ability for o Removed support for physical presence or any ability for
skipping to change at page 60, line 30 skipping to change at page 63, line 36
o Defined the Zero Touch Information DHCP option o Defined the Zero Touch Information DHCP option
o Added an ability for devices to also download images from o Added an ability for devices to also download images from
configuration servers configuration servers
o Added an ability for configlets to be encrypted o Added an ability for configlets to be encrypted
o Now configuration servers only have to support HTTP/S - no other o Now configuration servers only have to support HTTP/S - no other
schemes possible schemes possible
B.2. 00 to 01 C.2. 00 to 01
o Added boot-image and validate-owner annotations to the "Actors and o Added boot-image and validate-owner annotations to the "Actors and
Roles" diagram. Roles" diagram.
o Fixed 2nd paragraph in section 7.1 to reflect current use of o Fixed 2nd paragraph in section 7.1 to reflect current use of
anyxml. anyxml.
o Added encrypted and signed-encrypted examples o Added encrypted and signed-encrypted examples
o Replaced YANG module with XSD schema o Replaced YANG module with XSD schema
o Added IANA request for the Zero Touch Information DHCP Option o Added IANA request for the Zero Touch Information DHCP Option
o Added IANA request for media types for boot-image and o Added IANA request for media types for boot-image and
configuration configuration
B.3. 01 to 02 C.3. 01 to 02
o Replaced the need for a configuration signer with the ability for o Replaced the need for a configuration signer with the ability for
each NMS to be able to sign its own configurations, using each NMS to be able to sign its own configurations, using
manufacturer signed ownership vouchers and owner certificates. manufacturer signed ownership vouchers and owner certificates.
o Renamed configuration server to bootstrap server, a more o Renamed configuration server to bootstrap server, a more
representative name given the information devices download from representative name given the information devices download from
it. it.
o Replaced the concept of a configlet by defining a southbound o Replaced the concept of a configlet by defining a southbound
interface for the bootstrap server using YANG. interface for the bootstrap server using YANG.
o Removed the IANA request for the boot-image and configuration o Removed the IANA request for the boot-image and configuration
media types media types
B.4. 02 to 03 C.4. 02 to 03
o Minor update, mostly just to add an Editor's Note to show how this o Minor update, mostly just to add an Editor's Note to show how this
draft might integrate with the draft-pritikin-anima-bootstrapping- draft might integrate with the draft-pritikin-anima-bootstrapping-
keyinfra. keyinfra.
B.5. 03 to 04 C.5. 03 to 04
o Major update formally introducing unsigned data and support for o Major update formally introducing unsigned data and support for
Internet-based redirect servers. Internet-based redirect servers.
o Added many terms to Terminology section. o Added many terms to Terminology section.
o Added all new "Guiding Principles" section. o Added all new "Guiding Principles" section.
o Added all new "Sources for Bootstrapping Data" section. o Added all new "Sources for Bootstrapping Data" section.
o Rewrote the "Interactions" section and renamed it "Workflow o Rewrote the "Interactions" section and renamed it "Workflow
Overview". Overview".
B.6. 04 to 05 C.6. 04 to 05
o Semi-major update, refactoring the document into more logical o Semi-major update, refactoring the document into more logical
parts parts
o Created new section for information types o Created new section for information types
o Added support for DNS servers o Added support for DNS servers
o Now allows provisional TLS connections o Now allows provisional TLS connections
skipping to change at page 61, line 47 skipping to change at page 65, line 4
o Semi-major update, refactoring the document into more logical o Semi-major update, refactoring the document into more logical
parts parts
o Created new section for information types o Created new section for information types
o Added support for DNS servers o Added support for DNS servers
o Now allows provisional TLS connections o Now allows provisional TLS connections
o Bootstrapping data now supports scripts o Bootstrapping data now supports scripts
o Device Details section overhauled o Device Details section overhauled
o Security Considerations expanded o Security Considerations expanded
o Filled in enumerations for notification types o Filled in enumerations for notification types
B.7. 05 to 06 C.7. 05 to 06
o Minor update o Minor update
o Added many Normative and Informative references. o Added many Normative and Informative references.
o Added new section Other Considerations. o Added new section Other Considerations.
B.8. 06 to 07 C.8. 06 to 07
o Minor update o Minor update
o Added an Editorial Note section for RFC Editor. o Added an Editorial Note section for RFC Editor.
o Updated the IANA Considerations section. o Updated the IANA Considerations section.
B.9. 07 to 08 C.9. 07 to 08
o Minor update o Minor update
o Updated to reflect review from Michael Richardson. o Updated to reflect review from Michael Richardson.
B.10. 08 to 09 C.10. 08 to 09
o Added in missing "Signature" artifact example. o Added in missing "Signature" artifact example.
o Added recommendation for manufacturers to use interoperable o Added recommendation for manufacturers to use interoperable
formats and file naming conventions for removable storage devices. formats and file naming conventions for removable storage devices.
o Added configuration-handling leaf to guide if config should be o Added configuration-handling leaf to guide if config should be
merged, replaced, or processed like an edit-config/yang-patch merged, replaced, or processed like an edit-config/yang-patch
document. document.
o Added a pre-configuration script, in addition to the post- o Added a pre-configuration script, in addition to the post-
configuration script from -05 (issue #15). configuration script from -05 (issue #15).
B.11. 09 to 10 C.11. 09 to 10
o Factored ownership vocher and voucher revocation to a separate o Factored ownership vocher and voucher revocation to a separate
document: draft-kwatsen-netconf-voucher. (issue #11) document: draft-kwatsen-netconf-voucher. (issue #11)
o Removed <configuration-handling> options 'edit-config' and yang- o Removed <configuration-handling> options 'edit-config' and yang-
patch'. (issue #12) patch'. (issue #12)
o Defined how a signature over signed-data returned from a bootstrap o Defined how a signature over signed-data returned from a bootstrap
server is processed. (issue #13) server is processed. (issue #13)
skipping to change at page 63, line 20 skipping to change at page 66, line 26
o switched owner-certificate to be encoded using the pkcs#7 format. o switched owner-certificate to be encoded using the pkcs#7 format.
(issue #16) (issue #16)
o Replaced md5/sha1 with sha256 inside a choice statement, for o Replaced md5/sha1 with sha256 inside a choice statement, for
future extensibility. (issue #17) future extensibility. (issue #17)
o A ton of editorial changes, as I went thru the entire draft with a o A ton of editorial changes, as I went thru the entire draft with a
fine-toothed comb. fine-toothed comb.
B.12. 10 to 11 C.12. 10 to 11
o fixed yang validation issues found by IETFYANGPageCompilation. o fixed yang validation issues found by IETFYANGPageCompilation.
note: these issues were NOT found by pyang --ietf or by the note: these issues were NOT found by pyang --ietf or by the
submission-time validator... submission-time validator...
o fixed a typo in the yang module, someone the config false o fixed a typo in the yang module, someone the config false
statement was removed. statement was removed.
B.13. 11 to 12 C.13. 11 to 12
o fixed typo that prevented Appendix B from loading the examples o fixed typo that prevented Appendix B from loading the examples
correctly. correctly.
o fixed more yang validation issues found by o fixed more yang validation issues found by
IETFYANGPageCompilation. note: again, these issues were NOT found IETFYANGPageCompilation. note: again, these issues were NOT found
by pyang --ietf or by the submission-time validator... by pyang --ietf or by the submission-time validator...
o updated a few of the notification enumerations to be more o updated a few of the notification enumerations to be more
consistent with the other enumerations (following the warning/ consistent with the other enumerations (following the warning/
error pattern). error pattern).
o updated the information-type artifact to state how it's encoded, o updated the information-type artifact to state how it's encoded,
matching the language that was in Appendix B. matching the language that was in Appendix B.
B.14. 12 to 13 C.14. 12 to 13
o defined a standalone artifact to encode the old information-type o defined a standalone artifact to encode the old information-type
into a PKCS#7 structure. into a PKCS#7 structure.
o standalone information artifact hardcodes JSON encoding (to match o standalone information artifact hardcodes JSON encoding (to match
the voucher draft). the voucher draft).
o combined the information and signature PKCS#7 structures into a o combined the information and signature PKCS#7 structures into a
single PKCS#7 structure. single PKCS#7 structure.
o moved the certificate-revocations into the owner-certificate's o moved the certificate-revocations into the owner-certificate's
PKCS#7 structure. PKCS#7 structure.
o eliminated support for voucher-revocations, to reflect the o eliminated support for voucher-revocations, to reflect the
voucher-draft's switch from revocations to renewals. voucher-draft's switch from revocations to renewals.
B.15. 13 to 14 C.15. 13 to 14
o Renamed "bootstrap information" to "onboarding information". o Renamed "bootstrap information" to "onboarding information".
o Rewrote DHCP sections to address the packet-size limitation issue, o Rewrote DHCP sections to address the packet-size limitation issue,
as discussed in Chicago. as discussed in Chicago.
o Added Ian as an author for his text-contributions to the DHCP o Added Ian as an author for his text-contributions to the DHCP
sections. sections.
o Removed the Guiding Principles section. o Removed the Guiding Principles section.
B.16. 14 to 15 C.16. 14 to 15
o Renamed action 'notification' to 'update-progress' and, likewise o Renamed action 'notification' to 'update-progress' and, likewise
'notification-type' to 'update-type'. 'notification-type' to 'update-type'.
o Updated examples to use "base64encodedvalue==" for binary values. o Updated examples to use "base64encodedvalue==" for binary values.
o Greatly simplified the 'Artifact Groupings' section, and moved it o Greatly simplified the 'Artifact Groupings' section, and moved it
as a subsection to the 'Artifacts' section. as a subsection to the 'Artifacts' section.
o Moved the 'Workflow Overview' section to the Appendix. o Moved the 'Workflow Overview' section to the Appendix.
o Renamed 'bootstrap information' to 'update information'. o Renamed 'bootstrap information' to 'update information'.
o Removed 'Other Considerations' section. o Removed 'Other Considerations' section.
o Tons of editorial updates. o Tons of editorial updates.
B.17. 15 to 16 C.17. 15 to 16
o tweaked language to refer to "initial state" rather than "factory o tweaked language to refer to "initial state" rather than "factory
default configuration", so as accomodate white-box scenarios. default configuration", so as accommodate white-box scenarios.
o added a paragraph to Intro regarding how the solution primarily o added a paragraph to Intro regarding how the solution primarily
regards physical machines, but could be extended to VMs by a regards physical machines, but could be extended to VMs by a
future document. future document.
o added a pointer to the Workflow Overview section (recently moved o added a pointer to the Workflow Overview section (recently moved
to the Appendix) to the Intro. to the Appendix) to the Intro.
o added a note that, in order to simplify the verification process, o added a note that, in order to simplify the verification process,
the "Zerotouch Information" PKCS#7 structure MUST also contain the the "Zerotouch Information" PKCS#7 structure MUST also contain the
skipping to change at page 65, line 21 skipping to change at page 68, line 30
o noted that the owner certificate's must either have no Key Usage o noted that the owner certificate's must either have no Key Usage
or the Key Usage must set the "digitalSignature" bit. or the Key Usage must set the "digitalSignature" bit.
o noted that the owner certificate's subject and subjectAltName o noted that the owner certificate's subject and subjectAltName
values are not constrained. values are not constrained.
o moved/consolidated some text from the Artifacts section down to o moved/consolidated some text from the Artifacts section down to
the Device Details section. the Device Details section.
o tightened up some ambigous language, for instance, by refering to o tightened up some ambiguous language, for instance, by referring
specific leaf names in the Voucher artifact. to specific leaf names in the Voucher artifact.
o reverted a previously overzealous s/unique-id/serial-number/ o reverted a previously overzealous s/unique-id/serial-number/
change. change.
o modified language for when ZTP runs from when factory-default o modified language for when ZTP runs from when factory-default
config is running to when ZTP is confgured, which the factory- config is running to when ZTP is configured, which the factory-
defaults should set . defaults should set .
C.18. 16 to 17
o Added an example for how to promote an untrusted connection to a
trusted connection.
o Added a "query parameters" section defining some parameters
enabling scenarios raised in last call.
o Added a "Disclosing Information to Untrusted Servers" section to
the Security Considerations.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
Mikael Abrahamsson Mikael Abrahamsson
T-Systems T-Systems
 End of changes. 78 change blocks. 
177 lines changed or deleted 362 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/