NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track J. Clarke Expires: April 21, 2016 Cisco Systems M. Abrahamsson T-Systems October 19, 2015 Zero Touch Provisioning for NETCONF Call Home draft-ietf-netconf-zerotouch-04 Abstract This draft presents a technique for establishing a secure NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its rightful owner's network management system (NMS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Watsen, et al. Expires April 21, 2016 [Page 1] Internet-Draft Zero Touch October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 2. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 6 2.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Conveying Trust . . . . . . . . . . . . . . . . . . . . . 6 2.3. Ownership . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Information Types . . . . . . . . . . . . . . . . . . . . 7 3. Sources for Bootstrapping Data . . . . . . . . . . . . . . . 8 3.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 8 3.2. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Internet Based Service . . . . . . . . . . . . . . . . . 9 4. Workflow Overview . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Onboarding and Ordering Devices . . . . . . . . . . . . . 9 4.2. Owner Stages the Network for Bootstrap . . . . . . . . . 11 4.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 13 5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Factory Default State . . . . . . . . . . . . . . . . . . 16 5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Validating Signed Data . . . . . . . . . . . . . . . . . 19 5.4. Processing Bootstrap Data . . . . . . . . . . . . . . . . 19 6. YANG-defined API and Artifacts . . . . . . . . . . . . . . . 20 6.1. Module Overview . . . . . . . . . . . . . . . . . . . . . 20 6.2. API Examples . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Unsigned Redirect Information . . . . . . . . . . . . 22 6.2.2. Signed Redirect Information . . . . . . . . . . . . . 23 6.2.3. Unsigned Bootstrap Information . . . . . . . . . . . 26 6.2.4. Signed Bootstrap Information . . . . . . . . . . . . 28 6.2.5. Progress Notifications . . . . . . . . . . . . . . . 31 6.3. Artifact Examples . . . . . . . . . . . . . . . . . . . . 32 6.3.1. Signed Redirect Information . . . . . . . . . . . . . 32 6.3.2. Signed Bootstrap Information . . . . . . . . . . . . 33 6.3.3. Owner Certificate . . . . . . . . . . . . . . . . . . 35 6.3.4. Ownership Voucher . . . . . . . . . . . . . . . . . . 36 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7.1. Immutable storage for trust anchors . . . . . . . . . . . 44 7.2. Real time clock . . . . . . . . . . . . . . . . . . . . . 44 7.3. Entropy loss over time . . . . . . . . . . . . . . . . . 44 7.4. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8.1. Zero Touch Information DHCP Options . . . . . . . . . . . 45 Watsen, et al. Expires April 21, 2016 [Page 2] Internet-Draft Zero Touch October 2015 8.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 45 8.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 48 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction A fundamental business requirement is to reduce costs where possible. For network operators, deploying devices to many locations can be a significant cost, as sending trained specialists to each site to do installations is both cost prohibitive and does not scale. This document defines bootstrapping strategies enabling a device to securely obtain bootstrapping data with no installer input beyond racking the device and applying power. This bootstrapping data directs the device to install a boot image and an initial configuration, which enables the establishment of a NETCONF [RFC6241] or RESTCONF [draft-ietf-netconf-restconf] connection to its rightful owner's network management system (NMS). In order to enable a NETCONF or RESTCONF connection to be established, the initial configuration should include settings such as enabling the NETCONF/RESTCONF service, including parameters needed to support an NMS-initiated or device-initiated connection, and configuring a local administrator account. Examples used in this draft illustrate this using models defined by [RFC7317] and [draft-ietf-netconf-server-model]. 1.1. Use Cases o Connecting to a remotely administered network This use-case involves scenarios, such as a remote branch office or convenience store, whereby a device connects as an access gateway to an ISP's network. Assuming it is not possible to customize the ISP's network, and with no other nearby device to leverage, the device has no recourse but to Watsen, et al. Expires April 21, 2016 [Page 3] Internet-Draft Zero Touch October 2015 reach out to the public Internet for a well-known service it can bootstrap off of. o Connecting to a locally administered network This use-case covers all other scenarios and differs only in that the device may additionally leverage nearby devices, which may direct it to use a local service to bootstrap off of. If no such site-specific information is available, or the device is unable to use the information provided, it can then reach out to network just as it would for the remotely administered network use-case. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the sections below are to be interpreted as described in RFC 2119 [RFC2119]. This document defines the following terms: Artifact: The term "artifact" is used throughout to represent bootstrapping data that can be encoded outside of the RESTCONF protocol. For example, an artifact may be a file on disk or a message in another protocol. Unless used inside a secure protocol, artifacts must be signed and need to be provided along with an Owner Certificate and an Ownership Voucher (see terms), so the a device can validate the artifact's signature to its Rightful Owner (see term). Bootstrap Server: The term "bootstrap server" is used within this document to mean any RESTCONF server implementing the YANG module defined in Section 6.4. Device: The term "device" is used throughout this document to refer to the network element that needs to be bootstrapped. The device is the RESTCONF client to a Bootstrap Server (see above) and, at the end of bootstrapping process, the device is the NETCONF or RESTCONF server to a deployment-specific NMS. See Section 5 for more information about devices. Network Management System (NMS): The acronym "NMS" is used throughout this document to refer to the deployment specific management system that the bootstrapping process ultimately connects the devices to. From a device's perspective, when the bootstrapping process has completed, the NMS is a NETCONF or RESTCONF client. Watsen, et al. Expires April 21, 2016 [Page 4] Internet-Draft Zero Touch October 2015 Owner: See Rightful Owner. Owner Certificate: An owner certificate, signed by the device's manufacturer or delegate, binds an owner identity to the owner's private key, which the owner can subsequently use to sign artifacts. The owner certificate is an X.509 certificate encoding the owner's identity in the Subject field of the X.509 certificate. The owner certificate is used by devices only when validating owner signatures on Signed Data (see term). Ownership Voucher: An ownership voucher, signed by the device's manufacturer or delegate, binds an owner identity to one or more device identities (e.g., serial numbers). The ownership voucher is used by devices only when validating owner signatures on Signed Data (see term). Redirect Server: The term "redirect server" is used to refer to a Bootstrap Server (see above) that only returns Redirect Information (Section 2.4). Rightful Owner: The rightful owner of a device is the person or organization that purchased the device. How ownership can be conveyed to a device is described in Section 2.3. Secure Redirect: Secure redirect is like an HTTP Redirect except that it also returns TLS certificates that can be used as trust anchors to validate the secure connection to the Bootstrap Server the device is being redirected to. Signed Data: The term "signed data" is used throughout to mean data that has been signed by a device's Rightful Owner's private key. Any time data is signed, it must be presented along with an Owner Certificate and Ownership Voucher (see terms). Unsigned Data: The term "unsigned data" is used throughout to mean data that has not been signed by a device's Rightful Owner's private key. The option to use unsigned data is available only when the data is obtained over a secure connection, such as to a Redirect Server or a Bootstrap Server (see terms). 1.3. Tree Diagrams A simplified graphical representation of the data models is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. Watsen, et al. Expires April 21, 2016 [Page 5] Internet-Draft Zero Touch October 2015 o Braces "{" and "}" enclose feature names, and indicate that the named feature must be present for the subtree to be present. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Guiding Principles This section provides overarching principles guiding the solution presented in this document. 2.1. Trust Anchors A device in its factory default state can only trust remote keys for which it has preconfigured trust anchors. For instance, the device may have a trust anchor (e.g., a X.509 certificate) for when authenticating a very specific HTTPS server, and another trust anchor for when validating boot-image files, and yet another trust anchor for when verifying software licenses. 2.2. Conveying Trust Trust can be conveyed by either transport level security or artifact signing. For instance, if a device connects to an HTTPS server, authenticating the TLS certificate to a known trust anchor, then any data the device receives from the HTTPS server can also be trusted. Likewise, if a device can authenticate the signature over some data to a known trust anchor, then that data can also be trusted. In general, any data obtained from a trusted source MAY be trusted and, any data obtained from an untrusted source MUST NOT be trusted. It is possible but unnecessary to provide signed data over a secure connection. For instance, a device connecting to a trusted HTTPS server may retrieve data that has been signed by its rightful owner, but this is not required, as the device is already assured by the server that its data was staged by its rightful owner. That said, when an insecure connection is used (e.g., DHCP), the device has no choice but to require that the data be signed, in order to trust the data. Watsen, et al. Expires April 21, 2016 [Page 6] Internet-Draft Zero Touch October 2015 2.3. Ownership The goal of this document is to enable a device to connect with its rightful owner's NMS. This entails the manufacturer being able to track who owns which devices (out of the scope of this document), as well as an ability to convey that information to devices (in scope). Matching the two ways to convey trust, this document provides both a protocol-oriented solution as well as an artifact based solution for conveying ownership. The protocol based solution conveys ownership by API contract, in that the server asserts that it will only return data that it is sure was staged by that device's rightful owner. How ownership for a device is assured is out of scope of this document. The artifact based solution involves the manufacturer signing an owner key and then later, when the ownership for devices is established, the manufacturer signing a voucher that assigns those devices to the owner, and then the owner using their private key to sign the artifacts. Thus, from the device's perspective, it can use the presented "ownership voucher" to validate the presented "owner certificate", which it can then use to validate the signature over the presented artifact. The YANG module in Section 6.4 includes grouping statements defining the format for the owner certificates and ownership vouchers used by the bootstrapping solution presented in this document. 2.4. Information Types This document presumes there exists two types of zero touch information: redirect information and bootstrapping information. Either type of data may by accessed as unsigned data over a secure connection to a trusted server (e.g., HTTPS), or as signed artifacts obtained via an insecure method (DHCP server, removable storage device, etc.). The redirect information type of data provides two bits of information: bootstrap server locations and trust anchors. The trust anchors are provided to enable the device to authentic the specified bootstrap servers (TLS certificate-based authentication). This is what distinguishes this technique from a standard HTTP Redirect and why it may sometimes be called "secure redirect". The bootstrap information type of data provides information describing the boot-image and configuration the device should be running, in order to be considered bootstrapped. The boot-image Watsen, et al. Expires April 21, 2016 [Page 7] Internet-Draft Zero Touch October 2015 information is optional but, if it is provided, the device should install the boot image prior to installing the configuration. The YANG module in Section 6.4 includes grouping statements defining the format for redirect and bootstrap information types used by the bootstrapping solution presented in this document. 3. Sources for Bootstrapping Data Following are the sources of bootstrapping data that are referenced by the workflow presented in Section 4.3. Other sources for bootstrapping information may be described in other documents, so long as the principles for when the bootstrapping data needs to be signed or not are enforced. Each of the descriptions below show how the bootstrapping data needs to be handled in a manner consistent with the guiding principles in Section 2. For devices supporting more than one source for bootstrapping data, no particular sequencing order has to be observed, as each source is equally secure, in that the chain of trust always goes back to the same root of trust, the manufacturer. 3.1. Removable Storage A device may attempt to read bootstrapping information from a directly attached removable storage device. This information would most likely have to be signed, as removable storage devices are generally not trustworthy. The information loaded from a removable storage device may redirect the device to a bootstrap server (i.e., redirect information) or it may provide the boot image and configuration (i.e., bootstrapping information) directly. For when providing the information directly, even the raw boot image file could be on the removable storage device, making it a fully self-standing solution. 3.2. DHCP Server A device may attempt to read bootstrapping information from a DHCP server (e.g., DHCP options). This information would have to be signed, as the DHCP protocol is not a secure protocol. The information may again be either redirect or bootstrapping information. If bootstrapping information is provided, the URI to the boot image would have to specify a file server (e.g., ftp://, tftp://, etc.), as DHCP servers do not themselves distribute files. Watsen, et al. Expires April 21, 2016 [Page 8] Internet-Draft Zero Touch October 2015 Note that it is acceptable for boot images to be fetched using an insecure protocol when having an embedded signature, as is commonly the case. 3.3. Internet Based Service A device may attempt to read bootstrapping information from a trusted Internet based service. The hosted information would not have to be signed, as the device would authenticate the service when establishing a secure connection to it, using trust anchors the device is manufactured with in its factory default state. This document defines a RESTCONF API for a bootstrap server that may be hosted on the Internet. The YANG module describing this API is provided in Section 6.4. The information may again redirect the device to a bootstrap server (i.e., redirect information) or it may direct the device to load a boot image and a configuration (i.e., bootstrapping information). If bootstrapping information is provided, the URI to the boot image would not have to be to a server the device has a trust anchor for, assuming the boot image has an embedded signature, as is commonly the case. 4. Workflow Overview The zero touch solution presented in this document is conceptualized to be composed of the workflows described in this section. Implementations MAY vary in details. 4.1. Onboarding and Ordering Devices The following diagram illustrates key interactions that occur from when a manufacturer or delegate onboards a prospective device owner to when the manufacturer ships devices for an order placed by the prospective device owner. Watsen, et al. Expires April 21, 2016 [Page 9] Internet-Draft Zero Touch October 2015 +-----------+ +------------+ |Prospective| +---+ |Manufacturer| | Owner | |NMS| +------------+ +-----------+ +---+ | | | | | | | 1. enroll me please | | #<----------------------------| | # | | # account credentials and/or | | # and/or owner certificate | | #---------------------------->| | | | | | | | | | | | 2. get IDevID trust anchor | | |<----------------------------# set IDevID trust anchor | | #------------------------->| | | | | | | | 3. place device order | | |<----------------------------# model devices | | #------------------------->| | | | | 4. ship devices and send | | | device identifiers and | | | ownership vouchers | | |----------------------------># set device identifiers | | # and ownership vouchers | | #------------------------->| | | | | | | The interactions in the above diagram are described below. 1. A prospective owner establishes a trust relationship with a manufacturer in order to place zero touch orders. Assuming the manufacturer or delegate hosts a secure redirect server, this onbording interaction might entail the creation of an online account that the owner can use to configure redirect information for future device orders. Alternatively, the onbording interaction may include the manufacturer signing an owner certificate (see Section 1.2), to be used for bootstrapping devices not using the manufacturer's redirect server. The onboarding interaction may also do both, giving the choice to the owner for how specific devices should bootstrap. Watsen, et al. Expires April 21, 2016 [Page 10] Internet-Draft Zero Touch October 2015 2. The prospective owner downloads from the manufacturer the X.509 based trust anchor certificate that can be used to validate the IDevID certificate [Std-802.1AR-2009] the devices will present as their SSH host key or TLS server certificate, when establishing a NETCONF or RESTCONF connection with the prospective owner's deployment-specific NMS. 3. Some time later, the prospective owner places an order with the manufacturer, perhaps with a special flag checked for zero touch handling. At this time, perhaps before placing the order, the owner may model the devices in their NMS. That is, create virtual objects for the devices with no real-world device associations. For instance the model can be used to simulate the device's location in the network and the configuration it should have when fully operational. 4. When the manufacturer ships the devices for the order, the manufacturer notifies the owner of the devices' unique identifiers and shipping destinations, which the owner can use to stage the network for when the devices powers on. Additionally, the manufacturer may send a ownership voucher assigning ownership of those devices to the rightful owner and/or configure backend systems so the secure redirect service can associate the redirect information to the devices. The owner sets this information on the NMS, perhaps binding specific device identifiers and ownership vouchers (if supported) to specific modeled devices. 4.2. Owner Stages the Network for Bootstrap The following diagram illustrates how an owner stages the network for bootstrapping devices. Watsen, et al. Expires April 21, 2016 [Page 11] Internet-Draft Zero Touch October 2015 +----------+ +------------+ |Deployment| |Manufacturer| +------+ | Specific | | Hosted | | Local| +---------+ +---+ |Bootstrap | | Redirect | | DHCP | |Removable| |NMS| | Server | | Server | |Server| | Storage | +---+ +----------+ +------------+ +------+ +---------+ | | | | | activate | | | | | modeled | | | | | 1. device | | | | | ----------->| | | | | | | | | | | 2. stage bootstrap | | | | information | | | |---------->| | | | | | | | | | 3. (optional) configure | | | | redirect server | | | |-------------------------->| | | | | | | | | | | | | | 4. (optional) configure DHCP server | | |---------------------------------------->| | | | | | | | | | | | | 5. (optional) store bootstrapping artifacts on media | |----------------------------------------------------->| | | | | | | | | | | The interactions in the above diagram are described below. 1. Having previously modeled the devices, including setting their fully operational configurations, associating device identifiers and ownership vouchers (if supported), the owner may "activate" one or more modeled devices. That is, tell the NMS to perform the steps necessary to prepare for when the real-world devices are powered up. 2. One thing the NMS must do is configure the deployment specific bootstrap server. Illustrated here as an external component, the bootstrap server may be implemented as an internal component of the NMS itself. Configuring the bootstrap server may occur via a programmatic API not defined by this document. This step sets signed or unsigned bootstrap information, as shown in Section 6.2, for the devices being activated. The configuration set MUST be at least enough to enable a secure NETCONF or Watsen, et al. Expires April 21, 2016 [Page 12] Internet-Draft Zero Touch October 2015 RESTCONF connection to be established and MAY be the device's fully operational configuration. 3. If it is desired to use a manufacturer or delegate hosted redirect service to supply the bootstrapping information, the redirect server would need to be configured to supply the redirect information to the devices. Configuring the redirect server may occur via a programmatic API not defined by this document. This step sets signed or unsigned redirect information, as shown in Section 6.2, for the devices being activated. The redirect information MUST set the IP address or hostname of the deployment specific bootstrap server and MAY set the X.509 trust anchor certificate to authenticate the bootstrap server's TLS certificate. 4. If it is desired to use a DHCP server to supply bootstrapping information, the DHCP server would need to be configured to supply the redirect information to the devices. Configuring the DHCP server may occur via a programmatic API (not defined by this document). Since DHCP is an insecure protocol, the information would have to be signed. That is, either signed redirect or signed bootstrap information, as shown in Section 6.2. 5. If it is desired to use a removable storage device (e.g., USB flash drive) to supply bootstrapping information, the information would need to be placed onto it. Since a removable storage device is insecure, the information would have to be signed. That is, either signed redirect or signed bootstrap information, as shown in Section 6.2. 4.3. Device Powers On The following diagram illustrates how a device might behave when powered on. Note that this is merely exemplary, subject to which bootstrapping strategies the device supports, which may be more or less than depicted below. This example sequences the sources of information (see Section 3) based on locality, or how "close" to the device the data is. Whether this sequence makes sense for a specific type of device needs to be determined by the manufacturer. Watsen, et al. Expires April 21, 2016 [Page 13] Internet-Draft Zero Touch October 2015 +------------+ +----------+ +------+ |Manufacturer| |Deployment| +---------+ | Local| | Hosted | | Specific | +------+ |Removable| | DHCP | | Redirect | |Bootstrap | +---+ |Device| | Storage | |Server| | Server | | Server | |NMS| +------+ +---------+ +------+ +------------+ +----------+ +---+ | | | | | | | | | | | | | 1. if not factory default, then exit. | | | | | | | | | | | | | | | | 2. check | | | | | #----------->| | | | | # if signed redirect information found | | web- | #------------------------------------------------------># hook | # either NMS-initiated connection | #---------># #<-----------------------------------------------------------------# # or device-initiated connection | | | #----------------------------------------------------------------->| # else if signed bootstrap information found (call home)| | #----------------------------------------------------------------->| | | | | | | | | | | | | | | | | | | | 3. Get IP assignment | | | | #------------------------>| | | | # if signed redirect information found | web- | #------------------------------------------------------># hook | # either NMS-initiated connection | #---------># #<-----------------------------------------------------------------# # or device-initiated connection | | | #----------------------------------------------------------------->| | | | | | | | | | | | | | | | | | | | 4. check | | | | | #-------------------------------------->| | | # if signed or unsigned redirect information found | web- | #------------------------------------------------------># hook | # either NMS-initiated connection | #---------># #<-----------------------------------------------------------------# # or device-initiated connection | | | #----------------------------------------------------------------->| | | | | | | | | 5. loop or wait for manual provisioning. | Watsen, et al. Expires April 21, 2016 [Page 14] Internet-Draft Zero Touch October 2015 The interactions in the above diagram are described below. 1. Upon power being applied, the device's bootstrapping logic first checks to see if it is running in its factory default state. If it has a modified state, then the bootstrapping logic would exit and none to the following interactions would occur. 2. If the device is able to load bootstrapping data from a removable storage device (e.g., USB flash drive), it might choose to do so first. The removable storage may have either signed redirect information or signed bootstrap information, as shown in Section 6.3. In the case that signed redirect information is found, the device would use it to established a connection to the deployment-specific bootstrap server, which would set its boot image and configure it to enable connections with the deployment-specific NMS to be established. If the bootstrap supports notifying (e.g., via a web-hook) external systems when a device sends its bootstrap-complete notification (Section 6.4), it would be possible for the NMS to initiate a NETCONF or RESTCONF connection to the device. Otherwise the configuration could configure the device it initiate a NETCONF or RESTCONF call home [draft-ietf-netconf-call-home] connection to the deployment-specific NMS. In the case that signed bootstrap information is found, the device would use it to set its boot image and initial configuration, which would have to direct it to initiate a NETCONF or RESTCONF call home connection to the deployment- specific NMS. If the device is unable to bootstrap using any of the information on the removable storage device, it would proceed to the next source of bootstrapping information, if any. 3. If the device is able to load bootstrapping data from a DHCP server, when obtaining a DHCP assignment, it may receive signed redirect information in a DHCP Option (Section 8). The device would process the signed redirect information in the same manner as described above for when it's loaded from a removable storage device. If the device is unable to bootstrap using information provided by a DHCP server, it would proceed to the next source of bootstrapping information, if any. 4. If the device is able to obtain a routable address to the Internet, it may attempt to establish a connection to a redirect server that is set by its factory default state (Section 5.1). Watsen, et al. Expires April 21, 2016 [Page 15] Internet-Draft Zero Touch October 2015 These connections would use the RESTCONF API described in this document and would be secured using trust anchors also set in the device's factory default state. The redirect server may provide signed or unsigned redirect information. In either case, the device would process the redirect information in the same manner as described above for when it's loaded from a removable storage device. If the device is unable to bootstrap using information provided by any redirect servers, it would proceed to the next source of bootstrapping information, if any. 5. If no more sources of bootstrapping information are available, the device may fall into a loop to try again or it may provide manageability interfaces for manual configuration (e.g., CLI, HTTP, NETCONF, etc.). 5. Device Details Devices supporting Zero Touch MUST have the preconfigured factory default state and bootstrapping logic described in the following sections. 5.1. Factory Default State +------------------------------------------------------------------+ | | | | | +----------------------------------------------------------+ | | | | | | | | | | | 1. list of public Internet Bootstrap Servers | | | | 2. list of trust anchor certs for Bootstrap Servers | | | | 3. trust anchor cert for owner certificates | | | | 4. trust anchor cert for device ownership vouchers | | | | 5. IDevID cert & associated intermediate certificate(s) | | | +----------------------------------------------------------+ | | | | +----------------------+ | | | | | | | | | | | 6. private key | | | +----------------------+ | | | +------------------------------------------------------------------+ 1. Devices that support loading bootstrapping information from the Internet (see Section 3) MUST be manufactured with a list of default Bootstrap Servers. Each Bootstrap Server may be identified via a hostname or an IP address. Watsen, et al. Expires April 21, 2016 [Page 16] Internet-Draft Zero Touch October 2015 2. Devices that support loading bootstrapping information from the Internet (see Section 3) SHOULD be manufactured with a list of trust anchor certificates that can be used to authenticate the Bootstrap Server connections with. 3. Devices that support loading owner signed data (see Section 1.2) MUST be manufactured with the trust anchor certificate for the Owner Certificates that the Manufacturer provides to prospective owners when they enroll in the Manufacturer's Zero Touch program (see Section 4.1). 4. Devices that support loading owner signed data (see Section 1.2) MUST also be manufactured with the trust anchor certificate for the device Ownership Vouchers that the Manufacturer provides to prospective owners when it ships out an order of Zero Touch devices (see Section 4.1). 5. Devices MUST be manufactured with an initial device identifier (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an X.509 certificate, encoding a globally unique device identifier (e.g., serial number). The device MUST also possess any intermediate certificates between the IDevID certificate and the Manufacturer's IDevID trust anchor certificate. 6. Device MUST be manufactured with a private key that corresponds to the public key encoded in the device's IDevID certificate. This private key SHOULD be securely stored, ideally by a cryptographic processor (e.g., a TPM). 5.2. Boot Sequence A device claiming to support Zero Touch MUST support the boot sequence described in this section. Watsen, et al. Expires April 21, 2016 [Page 17] Internet-Draft Zero Touch October 2015 Power On | v No 1. Running default config? --------> Boot normally | | Yes v 2. For each supported source for bootstrapping information, try to load bootstrapping data from the source | | v Yes 3. Able to bootstrap off any source? -----> Run with new configuration | | No v 4. Loop or wait for manual provisioning. These interactions are described next. 1. When the device powers on, it first checks to see if it is running the factory default configuration. If it is running a modified configuration, then it boots normally. 2. The device iterates over its list of sources for bootstrapping information. Details for handling different types of sources are provided in subsequent sections. 3. If the device is able to bootstrap itself off any of the sources for bootstrapping information, it runs with the new bootstrapped configuration merged into its running datastore. 4. Otherwise the device MAY loop back through the list of bootstrapping sources again or wait for manual provisioning. When the source is a removable storage device, the device MUST be able to read from it signed data (see term) and validate that the data was signed by its rightful owner, using the algorithm in Section 5.3. When the source is a DHCP server, the device MUST be able to read from it signed data (see term) and validate that the data was signed by its rightful owner, using the algorithm in Section 5.3. When the source is a bootstrap server, that is, using the RESTCONF API presented in Section 6.4, the device MUST be able to authenticate the server using one of the the device's preconfigured trust anchors. Watsen, et al. Expires April 21, 2016 [Page 18] Internet-Draft Zero Touch October 2015 Once done authenticating the bootstrap server, the device MUST attempt to fetch the bootstrapping data hosted for it there, using its unique identifier (e.g., serial number) as the key into the "device" list. If bootstrapping data is found and it is signed, then the device MUST first validate that the data was signed by its rightful owner using the algorithm in Section 5.3. The device then processes the bootstrapping data as described in Section 5.4. The device MAY post progress notification messages to the server, but SHOULD only do so if it has first authenticated itself to the server (e.g., client authentication). 5.3. Validating Signed Data If the device is ever presented signed data, it MUST validate the signed data as described in this section. Whenever there is signed data, the device MUST also be provided an Ownership Voucher and an Owner Certificate. The device MUST first authenticate the Ownership Voucher by validating the signature on it to one of its preconfigured trust anchors (see Section 5.1) and verify that the voucher contains the device's unique identifier (e.g., serial number). If the authentication of the voucher is successful, the device extracts the Rightful Owner's identity from the voucher for use in the next step. Next the device MUST authenticate the Owner Certificate by performing X.509 certificate path validation on it to one of its preconfigured trust anchors (see Section 5.1) and by verifying that the Subject contained in the certificate matches the Rightful Owner identity extracted from the voucher in the previous step. If the authentication of the certificate is successful, the device extracts the Owner's public key from the certificate for use in the next step. Finally the device MUST authenticate the signed data by verifying the signature on it was generated by the private key matching the public key extracted from the Owner Certificate in the previous step. If any of these steps fail, then the device MUST mark the data as invalid and not perform any of the subsequent steps. 5.4. Processing Bootstrap Data In order to process bootstrapping data, the device MUST follow the steps presented in this section. If the data is redirect-information (see Section 2.4), the device MUST immediately attempt to establish a RESTCONF connection to the Watsen, et al. Expires April 21, 2016 [Page 19] Internet-Draft Zero Touch October 2015 provided bootstrap server IP address or hostname. If a hostname is provided and DNS resolves it to more than one IP address, the device MUST attempt to try to connect to all of them, until it is able to successfully bootstrap off one of them. The device MUST authenticate the bootstrap server's TLS certificate using the X.509 certificate provided by the redirect information. If the data is bootstrap-information (see Section 2.4), the device MUST first check if it contains any boot-image information and, if so, check to see if it differs from what the device is currently running and, if so, install the boot-image using the provided URI and reboot (Note, it is assumed that the boot-image contains an embedded signature that the installation step will verify). This will cause the device's bootstrap logic to restart, which will again come to this point, though with a matching boot-image, thus letting the device to proceed past this step. Next the device MUST process the configuration contained in the bootstrapping information, by merging it into its running configuration. At this point, the device has completely processed the bootstrapping data and is "bootstrap complete". If the configuration configured the device it initiate a call home connection, it would proceed to do so now. Otherwise, the device would wait for a NETCONF or RESTCONF client to connect to it. 6. YANG-defined API and Artifacts Central to the solution presented in this document is the use of a YANG module [RFC6020] to simultaneously define a RESTCONF based API for a bootstrap/redirect server as well as the encoding for signed artifacts that can be conveyed outside of the RESTCONF protocol (DHCP, FTP, TFTP, etc.). 6.1. Module Overview The following tree diagram Section 1.3 provides an overview for both the API and artifacts that can be used outside of RESTCONF. Watsen, et al. Expires April 21, 2016 [Page 20] Internet-Draft Zero Touch October 2015 module: ietf-zerotouch-bootstrap-server +--ro devices +--ro device* [unique-id] +--ro unique-id string +--ro (type)? | +--:(redirect-information) | | +--ro redirect-information | | +--ro address inet:host | | +--ro trust-anchor binary | | +--ro signature? string | +--:(bootstrap-information) | +--ro bootstrap-information | +--ro boot-image | | +--ro name string | | +--ro md5 string | | +--ro sha1 string | | +--ro path string | | +--ro signature? string | +--ro configuration | +--ro config | +--ro signature? string +--ro ownership-voucher | +--ro voucher binary | +--ro issuer-crl? string +--ro owner-certificate | +--ro certificate string | +--ro issuer-crl? string +---x notification +---w input +---w type enumeration +---w message? string +---w ssh-host-keys +---w ssh-host-key* +---w format enumeration +---w key-data string In the above diagram, notice that all of the protocol accessible node are read-only, to assert that devices can only pull data from the bootstrap server. Also notice that the module defines an action statement, which devices may use to provide progress notifications to the Bootstrap Server. Watsen, et al. Expires April 21, 2016 [Page 21] Internet-Draft Zero Touch October 2015 6.2. API Examples This section presents some examples illustrating device interactions with a Bootstrap Server to access Redirect and Bootstrap information, both unsigned and signed, as well as to send a progress notification. 6.2.1. Unsigned Redirect Information The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives unsigned redirect information. This example is representative of a response a well-known Internet facing redirect service might return. Watsen, et al. Expires April 21, 2016 [Page 22] Internet-Draft Zero Touch October 2015 REQUEST ------- GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 HOST: example.com Accept: application/yang.data+xml RESPONSE -------- HTTP/1.1 200 OK Date: Sat, 31 Oct 2015 17:02:40 GMT Server: example-server Content-Type: application/yang.data+xml 123456789
phs.example.com
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 RJSUJQFRStS0Cg== 6.2.2. Signed Redirect Information The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives signed redirect information. This example is representative of a response that redirect service might return if concerned the device might not be able to authenticate its TLS certificate. REQUEST ------- Watsen, et al. Expires April 21, 2016 [Page 23] Internet-Draft Zero Touch October 2015 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 HOST: example.com Accept: application/yang.data+xml RESPONSE -------- HTTP/1.1 200 OK Date: Sat, 31 Oct 2015 17:02:40 GMT Server: example-server Content-Type: application/yang.data+xml 123456789
phs.example.com
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 RJSUJQFRStS0Cg== SomeSignatureString ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v Watsen, et al. Expires April 21, 2016 [Page 24] Internet-Draft Zero Touch October 2015 MjAO QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal Watsen, et al. Expires April 21, 2016 [Page 25] Internet-Draft Zero Touch October 2015 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAO== 6.2.3. Unsigned Bootstrap Information The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives unsigned bootstrapping information. This example is representative of a response a locally deployed bootstrap server might return. REQUEST ------- GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 HOST: example.com Accept: application/yang.data+xml RESPONSE -------- HTTP/1.1 200 OK Date: Sat, 31 Oct 2015 17:02:40 GMT Server: example-server Content-Type: application/yang.data+xml 123456789 boot-image-v3.2R1.6.img SomeMD5String SomeSha1String /some/path/to/raw/file Watsen, et al. Expires April 21, 2016 [Page 26] Internet-Draft Zero Touch October 2015 admin admin's rsa ssh host-key ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 config-mgr east-data-center
11.22.33.44
 west-data-center
55.66.77.88
 my-call-home-x509-key Watsen, et al. Expires April 21, 2016 [Page 27] Internet-Draft Zero Touch October 2015 6.2.4. Signed Bootstrap Information The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives signed bootstrapping information. This example is representative of a response that bootstrap service might return if concerned the device might not be able to authenticate its TLS certificate. REQUEST ------- GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 HOST: example.com Accept: application/yang.data+xml RESPONSE -------- HTTP/1.1 200 OK Date: Sat, 31 Oct 2015 17:02:40 GMT Server: example-server Content-Type: application/yang.data+xml 123456789 boot-image-v3.2R1.6.img SomeMD5String SomeSha1String /some/path/to/raw/file SomeSignatureString Watsen, et al. Expires April 21, 2016 [Page 28] Internet-Draft Zero Touch October 2015 admin admin's rsa ssh host-key ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 config-mgr east-data-center
11.22.33.44
 west-data-center
55.66.77.88
 my-call-home-x509-key SomeSignatureString Watsen, et al. Expires April 21, 2016 [Page 29] Internet-Draft Zero Touch October 2015 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAO QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B Watsen, et al. Expires April 21, 2016 [Page 30] Internet-Draft Zero Touch October 2015 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAO== 6.2.5. Progress Notifications The following example illustrates a device using the API to post a notification to the server. The device may send more than one notification to the server (e.g., to provide status updates). The YANG module defines only one notification type, bootstrap-complete. Other notification types may be defined through YANG augmentation. The bootstrap server MUST NOT process a notification from a device without first authenticating the device. This is in contrast to when a device is fetching data from the server, a read-only operation, in which case device authentication is not strictly required. In this example, the device sends a notification indicating that it has completed bootstrapping off the data provided by the server. This example also illustrates the device sending its SSH host keys to the bootstrap server, which it might, for example, forward onto a downstream NMS component, so that it can subsequently authenticate the device when establishing a NETCONF over SSH connection to it. A device providing its SSH host key or TLS server certificate is not needed when the device has an IDevID certificate [Std-802.1AR-2009] and is able to present the IDevID certificate as its SSH host key or TLS server certificate, when establishing a NETCONF or RESTCONF connection. Watsen, et al. Expires April 21, 2016 [Page 31] Internet-Draft Zero Touch October 2015 REQUEST ------- POST https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456/notification HTTP/1.1 HOST: example.com Content-Type: application/yang.data+xml bootstrap-complete example message ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 ssh-dsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 RESPONSE -------- HTTP/1.1 204 No Content Date: Sat, 31 Oct 2015 17:02:40 GMT Server: example-server 6.3. Artifact Examples This section presents some examples for how the same information provided by the API can be packaged into stand alone artifacts. The encoding for these artifacts is the same as if an HTTP GET request had been sent to the RESTCONF URL for the specific resource. Encoding these artifacts for use outside of the RESTCONF protocol extends their utility for other deployment scenarios, such as when a local DHCP server or a removable storage device is used. By way of example, this may be done to address an inability for the device to access an Internet facing bootstrap/redirect server, or just for a preference to use locally deployed infrastructure. 6.3.1. Signed Redirect Information The following example illustrates how a redirect can be encoded into an artifact for use outside of the RESTCONF protocol. The redirect information is signed so that it is secure even when no transport- level security is provided. Watsen, et al. Expires April 21, 2016 [Page 32] Internet-Draft Zero Touch October 2015
phs.example.com
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 RJSUJQFRStS0Cg== SomeSignatureString 6.3.2. Signed Bootstrap Information The following example illustrates how bootstrapping data can be encoded into an artifact for use outside of the RESTCONF protocol. The bootstrapping information is signed so that it is secure when no transport-level security is provided. boot-image-v3.2R1.6.img SomeMD5String SomeSha1String /some/path/to/raw/file SomeSignatureString Watsen, et al. Expires April 21, 2016 [Page 33] Internet-Draft Zero Touch October 2015 admin admin's rsa ssh host-key ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 config-mgr east-data-center
11.22.33.44
 west-data-center
55.66.77.88
 my-call-home-x509-key SomeSignatureString Watsen, et al. Expires April 21, 2016 [Page 34] Internet-Draft Zero Touch October 2015 6.3.3. Owner Certificate The following example illustrates how the owner certificate, along with its CRL, can be encoded into an artifact for use outside of the RESTCONF protocol. As the Owner Certificate and CRL are already signed by the manufacturer, an additional owner signature is unnecessary. Watsen, et al. Expires April 21, 2016 [Page 35] Internet-Draft Zero Touch October 2015 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAO== 6.3.4. Ownership Voucher The following example illustrates how the ownership voucher, along with its CRL, can be encoded into an artifact for use outside of the RESTCONF protocol. As the Ownership Voucher and CRL are already Watsen, et al. Expires April 21, 2016 [Page 36] Internet-Draft Zero Touch October 2015 signed by the manufacturer, an additional owner signature is unnecessary. ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v MjAO QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 6.4. YANG Module The bootstrap server's device-facing interface is normatively defined by the following YANG module: file "ietf-zerotouch-bootstrap-server@2015-10-19.yang" module ietf-zerotouch-bootstrap-server { namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; prefix "ztbs"; import ietf-inet-types { // RFC 6991 prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; Watsen, et al. Expires April 21, 2016 [Page 37] Internet-Draft Zero Touch October 2015 contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Mahesh Jethanandani Editor: Kent Watsen "; description "This module defines the southbound interface for Zero Touch bootstrap servers. Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2015-10-19" { description "Initial version"; reference "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; } grouping redirect-information-grouping { description "This container contains information the device may use to redirect it to another bootstrap server."; leaf address { type inet:host; mandatory true; description "The IP address or hostname of the bootstrap server the device should redirect to."; } Watsen, et al. Expires April 21, 2016 [Page 38] Internet-Draft Zero Touch October 2015 leaf trust-anchor { type binary; mandatory true; description "A certificate that a device can use as a trust anchor to authenticate the bootstrap server it is being redirected to. The binary certificate structure as specified by RFC 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>; "; reference "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2"; } leaf signature { type string; must "../../ownership-voucher"; description "The signature over the concatenation of the previous leafs using the organization's private key. Specifically, sign(name+md5+sha1+path), where simple string concatenation to join values is used, resulting in a single null-terminated string."; } } grouping bootstrap-information-grouping { container boot-image { description "It is intended that the device will fetch this container as a whole, as it contains values that need to be processed together."; leaf name { type string; mandatory true; description "The name of the image of software the device is expected to be running."; } leaf md5 { type string; mandatory true; description "The output of the MD5 hash algorithm over the image file."; Watsen, et al. Expires April 21, 2016 [Page 39] Internet-Draft Zero Touch October 2015 } leaf sha1 { type string; mandatory true; description "The output of the SHA-1 hash algorithm over the image file."; } leaf path { type string; mandatory true; description "An absolute path to the boot-image file hosted on this Bootstrap server."; } leaf signature { type string; must "../../../ownership-voucher"; description "The signature over the concatenation of the previous leafs using the organization's private key. Specifically, sign(name+md5+sha1+path), where simple string concatenation to join values is used, resulting in a single null-terminated string."; } } container configuration { description "It is intended that the device will fetch this container as a whole, as its contents need to be processed together."; anyxml config { mandatory true; description "Any configuration data model known to the device. It may contain Vendor-specific and/or standards-based data models. An example configuration using a couple IETF-defined data models is presented the Appendix of RFC XXXX."; } leaf signature { type string; must "../../../ownership-voucher"; description "The signature over the concatenation of the previous leaf using the organization's private key. Specifically, sign(config), where 'config' is treated as a single null- terminated string."; } } Watsen, et al. Expires April 21, 2016 [Page 40] Internet-Draft Zero Touch October 2015 } grouping owner-certificate-grouping { leaf certificate { type string; mandatory true; description "This is an X.509 certificate, signed by a Vendor, for a business organization. This certificate must encode a Vendor-assigned value identifying the organization. This identifier must match the owner identifier encoded in the Ownership Voucher."; } leaf issuer-crl { type string; description "An optional CRL for the issuer used by the Vendor to sign Owner Certificates. The CRL should be as up to date as possible. This leaf is optional as it is primarily to support deployments where the device is unable to download the CRL from the CRL distribution point URLs listed in the Vendor's trust anchor certificate."; } } grouping ownership-voucher-grouping { leaf voucher { type binary; mandatory true; description "A Vendor-specific encoding binding unique device identifiers to an owner identifier value matching the value encoded in the owner-certificate below. An example format for a voucher is presented in the Appendix of RFC XXXX."; } leaf issuer-crl { type string; description "An optional CRL for the issuer used by the Vendor to sign Ownership Vouchers. The CRL should be as up to date as possible. This leaf is optional as it is primarily to support deployments where the device is unable to download the CRL from the CRL distribution point URLs listed in the Vendor's trust anchor Watsen, et al. Expires April 21, 2016 [Page 41] Internet-Draft Zero Touch October 2015 certificate."; } } container devices { config false; description "A read-only list of device entries"; list device { key unique-id; leaf unique-id { type string; description "A unique identifier for the device (e.g., serial number). Each device accesses its bootstrapping record by its unique identifier."; } choice type { container redirect-information { uses redirect-information-grouping; } container bootstrap-information { uses bootstrap-information-grouping; } } container ownership-voucher { description "This container contains the Ownership Voucher that the device uses to ascertain the identity of its rightful owner, as certified by its Vendor."; when "../redirect-information/signature or ../bootstrap-information/*/signature"; //must "../owner-certificate and ../redirect-information/signature or ../bootstrap-information/*/signature"; must "../owner-certificate"; uses ownership-voucher-grouping; } container owner-certificate { description "It is intended that the device will fetch this container as a whole, as it contains values that need to be Watsen, et al. Expires April 21, 2016 [Page 42] Internet-Draft Zero Touch October 2015 processed together."; when "../ownership-voucher"; //must "../ownership-voucher and ../redirect-information/signature or ../bootstrap-information/*/signature"; uses owner-certificate-grouping; } action notification { input { leaf type { type enumeration { enum bootstrap-complete { description "Indicates that the device successfully processed the bootstrap data, that is currently running the specified boot image and has committed the configuration. At this point, the device is ready to be managed by an external NMS system. The device is never expected access the bootstrap server again, unless reset to its factory default again."; } } mandatory true; } leaf message { type string; description "A human-readable value."; } container ssh-host-keys { list ssh-host-key { when "../type = bootstrap-complete"; leaf format { type enumeration { enum ssh-dss; enum ssh-rsa; } mandatory true; } leaf key-data { type string; mandatory true; } } } } Watsen, et al. Expires April 21, 2016 [Page 43] Internet-Draft Zero Touch October 2015 } // end action } } } 7. Security Considerations 7.1. Immutable storage for trust anchors Devices MUST ensure that all their trust anchor certificates, including those for the Owner Certificate and Ownership Voucher, are protected from external modification. It may be necessary to update these certificates over time (e.g., the manufacturer wants to delegate trust to a new CA). It is therefore expected that devices MAY update these trust anchors when needed through a verifiable process, such as a software upgrade using signed software images. 7.2. Real time clock The solution for signed data includes validating Owner Certificates and Ownership Vouchers, each of which may contain expirations. Further, the solution includes using a CRLs, which also require freshness. Device implementations should take care to ensure the devices have a reliable clock when processing signed data. 7.3. Entropy loss over time Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that IDevID certificate should never expire (i.e. having a notAfter 99991231235959Z). Given the long-lived nature of these certificates, it is paramount to use a strong key length (e.g., 512-bit ECC). Manufacturers SHOULD deploy Online Certificate State Protocol (OCSP) responders or CRL Distribution Points (CDP) to revoke certificates in case necessary. 7.4. Serial Numbers This draft suggests using the device's serial number as the unique identifier in its IDevID certificate. This is because serial numbers are ubiquitous and prominently contained in invoices and on labels affixed to devices and their packaging. That said, serial numbers many times encode revealing information, such as the device's model Watsen, et al. Expires April 21, 2016 [Page 44] Internet-Draft Zero Touch October 2015 number, manufacture date, and/or sequence number. Knowledge of this information may provide an adversary with details needed to launch an attack. 8. IANA Considerations Editor Note: this section needs to be rewritten to use the redirect and bootstrap information types (see Section 2.4). 8.1. Zero Touch Information DHCP Options The following registrations are in accordance to RFC 2939 for "BOOTP Manufacturer Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 8.1.1. DHCP v4 Option Tag: XXX Name: Zero Touch Information Description: Returns a list of null-terminated Configuration Server hostnames and/or IP addresses. Code Len +-----+-----+------+------+---- | XXX | n | svr1 | svr2 | ... +-----+-----+------+------+---- Reference: RFC XXXX 8.1.2. DHCP v6 Option Tag: YYY Name: Zero Touch Information Description: Returns a list of null-terminated Configuration Server hostnames and/or IP addresses. Code Len +-----+-----+------+------+---- | YYY | n | svr1 | svr2 | ... +-----+-----+------+------+---- Reference: RFC XXXX Watsen, et al. Expires April 21, 2016 [Page 45] Internet-Draft Zero Touch October 2015 9. Acknowledgements The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): David Harrington, Dean Bogdanovic, Martin Bjorklund, Max Pritikin, Stephen Hanna, Wes Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder. Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original I-D's solution during the IETF 87 meeting in Berlin. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [Std-802.1AR-2009] IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, . [draft-ietf-netconf-call-home] Watsen, K., "NETCONF Call Home (work in progress)", October 2014, . [draft-ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ieft-netconf-restconf-04 (work in progress), 2014, . [draft-ietf-netconf-server-model] Watsen, K., "NETCONF Server Model (work in progress)", September 2014, . Watsen, et al. Expires April 21, 2016 [Page 46] Internet-Draft Zero Touch October 2015 10.2. Informative References [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . Watsen, et al. Expires April 21, 2016 [Page 47] Internet-Draft Zero Touch October 2015 Appendix A. Examples A.1. Ownership Voucher Following describes an example data-model for an Ownership Voucher. Real vouchers are expected to be encoded in a Manufacturer-specific format outside the of scope for this draft. A tree diagram describing an Ownership Voucher: module: ietf-zerotouch-ownership-voucher +--rw voucher +--rw owner-id string +--rw unique-id* string +--rw created-on yang:date-and-time +--rw expires-on? yang:date-and-time +--rw signature string The YANG module for this example voucher: file "ietf-zerotouch-ownership-voucher@2015-10-19.yang" module ietf-zerotouch-ownership-voucher { namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher"; prefix "ztov"; import ietf-yang-types { prefix yang; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Mahesh Jethanandani Editor: Kent Watsen "; description "This module defines the format for a ZeroTouch ownership voucher, which is produced by Vendors, relayed by Bootstrap Servers, and consumed by devices. The purpose of the voucher is to enable a Watsen, et al. Expires April 21, 2016 [Page 48] Internet-Draft Zero Touch October 2015 device to ascertain the identity of its rightful owner, as certified by its Vendor. Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2015-10-19" { description "Initial version"; reference "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; } // top-level container container voucher { description "A voucher, containing the owner's identifier, a list of device's unique identifiers, information on when the voucher was created, when it might expire, and the vendor's signature over the above values."; leaf owner-id { type string; mandatory true; description "A Vendor-assigned value for the rightful owner of the devices enumerated by this voucher. The owner-id value must match the value in the owner-certificate below"; } leaf-list unique-id { type string; min-elements 1; description "The unique identifier (e.g., serial-number) for a device. The value must match the value in the device's IDevID certificate. A device uses this value to determine if the voucher applies to it."; } leaf created-on { Watsen, et al. Expires April 21, 2016 [Page 49] Internet-Draft Zero Touch October 2015 type yang:date-and-time; mandatory true; description "The date this voucher was created"; } leaf expires-on { type yang:date-and-time; description "The date this voucher expires, if at all. Use of this value requires that the device has access to a trusted real time clock"; } leaf signature { type string; mandatory true; description "The signature over the concatenation of all the previous values"; } } } Appendix B. Change Log B.1. ID to 00 o Major structural update; the essence is the same. Most every section was rewritten to some degree. o Added a Use Cases section o Added diagrams for "Actors and Roles" and "NMS Precondition" sections, and greatly improved the "Device Boot Sequence" diagram o Removed support for physical presence or any ability for Configlets to not be signed. o Defined the Zero Touch Information DHCP option o Added an ability for devices to also download images from Configuration Servers o Added an ability for Configlets to be encrypted Watsen, et al. Expires April 21, 2016 [Page 50] Internet-Draft Zero Touch October 2015 o Now Configuration Servers only have to support HTTP/S - no other schemes possible B.2. 00 to 01 o Added boot-image and validate-owner annotations to the "Actors and Roles" diagram. o Fixed 2nd paragraph in section 7.1 to reflect current use of anyxml. o Added encrypted and signed-encrypted examples o Replaced YANG module with XSD schema o Added IANA request for the Zero Touch Information DHCP Option o Added IANA request for media types for boot-image and configuration B.3. 01 to 02 o Replaced the need for a Configuration Signer with the ability for each NMS to be able to sign its own configurations, using Manufacturer signed Ownership Vouchers and Owner certificates. o Renamed Configuration Server to Bootstrap Server, a more representative name given the information devices download from it. o Replaced the concept of a Configlet by defining a southbound interface for the Bootstrap Server using YANG. o Removed the IANA request for the boot-image and configuration media types B.4. 02 to 03 o Minor update, mostly just to add an Editor's Note to show how this draft might integrate with the draft-pritikin-anima-bootstrapping- keyinfra. B.5. 03 to 04 o Major update formally introducing unsigned data and support for Internet-based redirect servers. o Added many terms to Terminology section. Watsen, et al. Expires April 21, 2016 [Page 51] Internet-Draft Zero Touch October 2015 o Added all new "Guiding Principles" section. o Added all new "Sources for Bootstrapping Data" section. o Rewrote the "Interactions" section and renamed it "Workflow Overview". Authors' Addresses Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Joe Clarke Cisco Systems EMail: jclarke@cisco.com Mikael Abrahamsson T-Systems EMail: "mikael.abrahamsson@t-systems.se Watsen, et al. Expires April 21, 2016 [Page 52]