NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track J. Clarke Expires: September 10, 2015 Cisco Systems M. Abrahamsson T-Systems March 9, 2015 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) draft-ietf-netconf-zerotouch-02 Abstract This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based 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 September 10, 2015. 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 September 10, 2015 [Page 1] Internet-Draft ZeroTouch March 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. High-level Design . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 4 2.2. Interactions . . . . . . . . . . . . . . . . . . . . . . 7 3. Bootstrap Server . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Northbound Interface . . . . . . . . . . . . . . . . . . 10 3.2. Southbound Interface . . . . . . . . . . . . . . . . . . 10 4. Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Factory Default State . . . . . . . . . . . . . . . . . . 16 4.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 18 5. Network Management System (NMS) . . . . . . . . . . . . . . . 22 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Precondition . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Connection Handling . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.1. Entropy loss over time . . . . . . . . . . . . . . . . . 23 6.2. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7.1. ZeroTouch Information DHCP Options . . . . . . . . . . . 24 7.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 24 7.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 26 A.2. Bootstrap Server's API . . . . . . . . . . . . . . . . . 28 A.3. Bootstrap Configuration . . . . . . . . . . . . . . . . . 28 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 30 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 30 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 30 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. Watsen, et al. Expires September 10, 2015 [Page 2] Internet-Draft ZeroTouch March 2015 The solution presented herein enables a device to securely obtain a bootstrapping configuration from the network without any operator input. Significantly, this configuration may configure the device to securely call home using NETCONF Call Home [draft-ietf-netconf-call-home]. Central to this solution is the device being able to process a set of files locally, without any need to reach out to the network again. As consequence, how the files are obtained is not critical to the security of the solution. The files can be read over any networking layer or medium. By example, the files could be loaded using a USB flash drive physically plugged into a device. The solution presented below focuses on supporting IP networks that may have a DHCP server. Solutions for other deployment scenarios may be defined by drafts in the future. 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 the device connects an access gateway device to an ISP's network. In this case, the device receives only generic networking settings provided by the ISP's DHCP server, with no site-specific customizations possible. In such a case, the device has no recourse but to reach out to the public Internet its initial configuration. o Connecting to a locally administered network This use-case covers all other scenarios and differs only in that the device may additionally receive site-specific information from the network, which could direct it to use a local server for its initial configuration. If no site- specific information is provided, or the device is unable to use the information provided, it can then reach out to network just as it would for a remotely administered network. 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]. Watsen, et al. Expires September 10, 2015 [Page 3] Internet-Draft ZeroTouch March 2015 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. 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. High-level Design 2.1. Design Overview The following diagram illustrates the overall solution presented in this draft. Note that some of the interactions illustrated below occur at different times, only the numbered interactions (1-3) occur at the time a device is bootstrapping itself. Watsen, et al. Expires September 10, 2015 [Page 4] Internet-Draft ZeroTouch March 2015 manufactures +----------------------------------+ | | | 1.discover | | bootstrap | 2.fetch bootstrap | information v data and provide | (optional) +------+ confirmation | +---------------|Device|----------------+ | | +------+ | | | | | | v | v +------+ +------+ | +---------+ |Vendor| | DHCP | |3.netconf |Bootstrap| +------+ |Server| | callhome | Server | | ^ +------+ | +---------+ | | ^ | ^ | | | stage | | | | | bootstrap | stage | | | | information v bootstrap | | | | (optional) +-------+ data | | | +---------------| NMS |---------------+ | | +-------+ | | imports trust anchor, | ^ | | signups for owner cert, | | | | and orders devices | | | +-------------------------------+ | +------------------------------------+ ships devices, provides serial-numbers and/or IDevID certs, and ownership vouchers The boxes in this diagram are described next. A sequence diagram explaining the various calls follows in Section 2.2. o Vendor Vendors manufacture the devices supporting NETCONF ZeroTouch. To support this solution, Vendors must support a one-time enrollment process per business organization owning the NMS. Vendors must also support sending additional information to the business organization about the devices that have been shipped for device orders it places. o Device The devices supporting NETCONF ZeroTouch will only attempt the bootstrapping process when booting with its factory default Watsen, et al. Expires September 10, 2015 [Page 5] Internet-Draft ZeroTouch March 2015 configuration. As illustrated above, the bootstrapping process consists of three interactions: 1. When joining the network, the device will attempt to configure IP networking from a DHCP server. If the device is able to reach a DHCP server, it may discover additional bootstrapping information. The additional bootstrapping information consists of one or more additional Bootstrap Servers the device should try to connect to. 2. The device sequentially processes its list of Bootstrap Servers, prioritizing any that might have been learned from the DHCP server. Once the device has successfully configured itself using the bootstrapping information, it notifies the bootstrapping server for monitoring purposes. 3. Assuming the bootstrapping information configures the device appropriately, the device will initiate a NETCONF Call Home connection [draft-ietf-netconf-call-home]. More information about Devices is in Section 4. o DHCP Server This draft assumes the use of a DHCP server but, in reality, the solution is not intrinsically tied to using a DHCP server. Any mechanism or combination of mechanisms that can provide dynamic networking assignment would equally do. Assuming the use of DHCP, this draft defines a specific DHCP Option for the discovering of addition bootstrapping information. More information about the ZeroTouch DHCP Option is in Section 7.1. o Bootstrap Server Bootstrap Servers host the bootstrapping information staged by NMSs for the devices to find. The Bootstrap Server presents a simple REST interface for devices to obtain both their bootstrapping information as well as notify the Bootstrapping Server when it has successfully completed the bootstrapping process. Bootstrap Servers may be deployed on the public Internet or on a local network. Devices may be preconfigured with a list of well-known Bootstrap Servers. Additional Bootstrap Servers (i.e. not in the device's preconfigured list) must be discovered from a DHCP server. Watsen, et al. Expires September 10, 2015 [Page 6] Internet-Draft ZeroTouch March 2015 How Bootstrap Servers are deployed is out of scope of this draft, but there are a couple points worth noting. Firstly, it is expected that Internet based Bootstrap Servers will initially be hosted by Vendors, whilst waiting for 3rd-party servers to become available. Secondly, it is expected that locally administrated networks with in-house solutions might bundle the Bootstrap Server into another system (e.g., the NMS), where having the features integrated can streamline various workflows. More information about Bootstrap Servers is in Section 3. o Network Management System The NMS is a term used here loosely to represent any system, or collection of systems, deployed by a business organization to manage its devices. An NMS being able to establish a secure NETCONF connection with devices purchased by its organization is the ultimate goal of this solution presented by this draft. More information about the Network Management System is in Section 5. 2.2. Interactions The following diagram illustrates the interactions between the entities described in the previous section. Note that the interactions can be roughly categorized as those that occur before a device powers on and those that occur after a device powers on. Watsen, et al. Expires September 10, 2015 [Page 7] Internet-Draft ZeroTouch March 2015 +------+ +------+ +---+ +---------+ +------+ |Vendor| |Device| |NMS| |Bootstrap| | DHCP | +------+ +------+ +---+ | Server | |Server| | | | +---------+ +------+ | | | | | | 1. imports trust anchor | | | |<------------------------------| | | | | | | | | 2. signs up for owner cert | | | |<------------------------------| | | | | | | | | 3. orders devices | | | |<------------------------------| | | | | | | | | 4. ships | | | | |-------------->| | | | | | | | | | 5. provides serial-numbers | | | | and/or IDevID cert(s), | | | | and ownership vouchers | | | |------------------------------>| | | | | | 6.stage | | x | | bootstrap | | | | data | | | |-------------->| | | | | | | | 7. stage bootstrap | | | info (optional) | | |------------------------------>| 8. power on | | | | -------------->| | | | | 9. get networking settings and| | | staged bootstrap info (if any) | |---------------------------------------------->| | | | | | | | x | 10. update boot-image, if | | needed, and install | | config, if valid | |------------------------------>| | | | | | x | 11. netconf | | call-home | |+------------->| | | v v Watsen, et al. Expires September 10, 2015 [Page 8] Internet-Draft ZeroTouch March 2015 These interactions are described below. 1. An organization, upon deciding to deploy a Vendor's devices for NETCONF ZeroTouch, would import into its NMS the IDevID trust anchor certificate from the Vendor. This certificate is later used by the NMS to authenticate device identities during NETCONF call home connections. 2. An organization needs to sign up to a Vendor-provided ZeroTouch program. This program entails the Vendor providing a signed Owner certificate to the organization (depicted here), as well as a commitment to sign Ownership Vouchers for future device orders (interaction #5). 3. Subsequently, the organization may place orders to the Vendor for devices supporting ZeroTouch. The ordering process may entail an explicit request for ZeroTouch support, as the Vendor providing the files in step #5 may not be enabled by default. 4. The Vendor ships the devices to the various addresses specified in the device order. For example, to an organization's inventory warehouse, where the devices are stored in batches to supply internal requests. In another example, the devices may be shipped to their final deployment destinations. 5. In order to support ZeroTouch, the Vendor sends to the organization information about the devices it shipped. This information may be sent to the organization via email or a portal site. The information includes the serial-number and/or IDevID certificate, for each device, as well as one more Ownership Vouchers, assigning ownership for the devices to the organization. 6. In anticipation for the devices performing the ZeroTouch process, the NMS configures the Bootstrap Server. This This configuration includes everything a device needs to securely connect to the NMS. 7. For deployments where the DHCP server can be customized, the NMS may configure the DHCP server to provide the device a list of additional Bootstrap Servers to consider, in addition to those the device knows of by default. This customization can be configured at a global level in the DHCP server, as it is not dependent on the type of device in any way. 8. At some point, the device powers on and, when having its factory default configuration, initiates the ZeroTouch process. Watsen, et al. Expires September 10, 2015 [Page 9] Internet-Draft ZeroTouch March 2015 9. The device obtains from the DHCP server a dynamic network assignment. The device may also at this time discover a list of additional bootstrap servers, as optionally configured by the NMS in step #7. 10. The device iterates over its list of Bootstrap Servers, until it can successfully bootstrap its initial configuration. If it is unable to bootstrap an initial configuration, the device boots as normal. If the staged information directs the device to load a new image, it does so and reboots. If the device reboots, it continues to have a factory default configuration state, which then bring it back to this state, when it would then have the correct image. The device then loads the staged configuration into its running datastore, after validating that the configuration was signed by its rightful owner, as designated by the Ownership Voucher. 11. Assuming the bootstrapping information configures the device appropriately, the device will initiate a NETCONF Call Home [draft-ietf-netconf-call-home] connection to the NMS, which then takes over the on-going management of the device. 3. Bootstrap Server A Bootstrap Server MUST implement the southbound interface defined below. In order to support the southbound interface, the Bootstrap Server will also need to have a northbound interface, which is described in general terms below. 3.1. Northbound Interface The Bootstrap Server will need to provide a northbound interface of some sort to enable configuration of the bootstrapping information for the devices. Defining this interface is out of scope for this document, but it northbound interface is generally expected to: o Enable listing, creation, modification, and deletion of entries o Enable determining a device's current bootstrapping state o Enable alerting external systems when a device sends notifications 3.2. Southbound Interface The Bootstrap Server's southbound interface is a REST API that is described by the YANG [RFC6020] module defined in this section and presented using RESTCONF [draft-ietf-netconf-restconf]. Example usage of this API is provided in Appendix A.2. Watsen, et al. Expires September 10, 2015 [Page 10] Internet-Draft ZeroTouch March 2015 A tree digram describing the Bootstrap Server's southbound interface follows: module: ietf-zerotouch-bootstrap-server +--ro devices +--ro device* [unique-id] +--ro unique-id string +--ro ownership-voucher | +--ro voucher binary | +--ro issuer-crl? string +--ro owner-certificate | +--ro certificate string | +--ro issuer-crl? string +--ro boot-image! | +--ro name string | +--ro path string | +--ro signature string +--ro configuration +--ro config +--ro signature string rpcs: +---x notification +---w input +---w unique-id string +---w type enumeration +---w message? string In the above diagram, notice that the entire data model is read-only, as devices can only pull data from the Bootstrap Server. The data model also defines a single RPC, which is used by the device to provide asynchronous notifications. The Bootstrap Server's southbound interface is normatively defined by the following YANG module: file "ietf-zerotouch-bootstrap-server@2015-03-09.yang" module ietf-zerotouch-bootstrap-server { namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; prefix "ztbs"; organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: Watsen, et al. Expires September 10, 2015 [Page 11] Internet-Draft ZeroTouch March 2015 WG List: WG Chair: Mehmet Ersue WG Chair: Mahesh Jethanandani Editor: Kent Watsen "; description "This module defines the southbound interface for ZeroTouch 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-03-09" { description "Initial version"; reference "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; } // top-level container container devices { config false; description "A list of device entries"; list device { key unique-id; leaf unique-id { type string; } container ownership-voucher { description "This container contains the Ownership Voucher that the Watsen, et al. Expires September 10, 2015 [Page 12] Internet-Draft ZeroTouch March 2015 device uses to ascertain the identity of its rightful owner, as certified by its Vendor."; 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 absolute path to a 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 certificate."; } } 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 processed together."; 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 absolute path to a 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 Watsen, et al. Expires September 10, 2015 [Page 13] Internet-Draft ZeroTouch March 2015 point URLs listed in the Vendor's trust anchor certificate."; } } container boot-image { presence "Only present when boot image information has been configured"; 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 path { type string; mandatory true; description "An absolute path to the boot-image file hosted on this Bootstrap server."; } leaf signature { type string; mandatory true; description "The signature over the concatenation of the previous two leafs using the organization's private key."; } } 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 { Watsen, et al. Expires September 10, 2015 [Page 14] Internet-Draft ZeroTouch March 2015 type string; mandatory true; description "The signature over the config leaf using the organization's private key."; } } } } rpc notification { input { leaf unique-id { type string; mandatory true; } leaf type { type enumeration { enum boot-image-missing { description "Indicates that the device got an error when trying to access the provided URL"; } enum boot-image-invalid { description "Indicates that the device had a problem processing the boot-image file (corruption)"; } enum image-name-mismatch { description "Indicates that the processed boot-image contains a name other than provided"; } enum voucher-invalid { description "Indicates that the device had a problem processing the voucher (chain verification failed, revoked crl)"; } enum owner-cert-invalid { description "Indicates that the device had a problem processing the voucher (chain verification failed, revoked crl)"; } enum owner-id-mismatch { description "Indicates that the owner-id in the voucher does not match the one inside the owner-cert"; Watsen, et al. Expires September 10, 2015 [Page 15] Internet-Draft ZeroTouch March 2015 } enum signature-invalid { description "Indicates that the signature could not be verified using the owner-cert"; } enum bootstrap-complete { description "Indicates that the device successfully processed the bootstrap data. At this point, the device is running the required boot-image and configuration. A device is expected to only send this notification once, assuming it does not receive an error in the HTTP response from the Bootstrap Server."; } } mandatory true; } leaf message { type string; description "A human-readable value that might provide useful information"; } } } } 4. Device Devices supporting ZeroTouch MUST have the preconfigured factory default state and bootstrapping logic described in the following sections. 4.1. Factory Default State Watsen, et al. Expires September 10, 2015 [Page 16] Internet-Draft ZeroTouch March 2015 +------------------------------------------------------------------+ | | | | | +----------------------------------------------------------+ | | | | | | | | | | | 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 MUST be manufactured with a list of default Bootstrap Servers. Each Bootstrap Server may be identified via a hostname or an IP address. This may be an empty list if for some reason the Vendor prefers to force its devices to have to discover Bootstrap Servers from a DHCP server. 2. Devices MUST be manufactured with a list of trust anchor certificates that can be used to authenticate Bootstrap Server connections with. To support Bootstrap Servers discovered from a DHCP server, these certificates SHOULD include public certificate authorities, such as those that are included in a web browser. 3. Devices MUST be manufactured with the trust anchor certificate for Owner certificates that the Vendors provide to business organizations when they enroll in the Vendor's ZeroTouch program. This trust anchor certificate is later used by the device to validate the Owner certificate it downloads from the Bootstrap Server. 4. Devices MUST be manufactured with the trust anchor certificate for the device ownership vouchers that the Vendors provide to organizations when it ships out an order of ZeroTouch devices. This trust anchor certificate is later used by the device to validate the Ownership Vouchers it downloads from the Bootstrap Server. Watsen, et al. Expires September 10, 2015 [Page 17] Internet-Draft ZeroTouch March 2015 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 Vendor's IDevID trust anchor certificate. These certificates are later used by the device to identify itself when it calls home. In particular, these certificates are to be used by the device's NETCONF server, either as its SSH host-key or its TLS server certificate. Please see NETCONF Call Home [draft-ietf-netconf-call-home] for more information. 6. Device MUST be manufactured with a private key that corresponds to the public key encoded in its IDevID certificate. This private key SHOULD be securely stored, ideally by a cryptographic processor (e.g., a TPM). 4.2. Boot Sequence Power On | v No 1. Running default config? --------> Boot normally | | Yes v No 2. Able to reach DHCP server? --------> Boot normally | | Yes v 3. Prepend any additional Bootstrap Servers discovered | v No 4. Able to bootstrap off any Bootstrap Server? -------> Boot normally (see next diagram for drill-down details) | | Yes v 5. Run with new configuration 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. Watsen, et al. Expires September 10, 2015 [Page 18] Internet-Draft ZeroTouch March 2015 2. The device tries to obtain a dynamic network assignment from a DHCP server. If it is unable to reach a DHCP server, it boots normally. 3. If the DHCP server's offer includes the ZeroTouch Information DHCP option defined in Section 7.1, the device prepends the specified Bootstrap Servers to its factory default list. 4. The device iterates over its list of Bootstrap Servers, as described in the next section. If it is unable to bootstrap itself off any of the servers, it boots normally. 5. If the device was able to bootstrap itself off any of the Bootstrap Servers, it runs with the new configuration merged into its running datastore. Following are the actions performed by the device when bootstrap off a Bootstrap Server (step #4 the in previous diagram). Watsen, et al. Expires September 10, 2015 [Page 19] Internet-Draft ZeroTouch March 2015 Connect to port 443 | v No 1. Able to validate server certificate? ------> Exit | | Yes v No 2. Able to validate ownership voucher? ------> Post notification and exit | | Yes v No 3. Able to validate owner certificate? ------> Post notification and exit | | Yes v No 4. Able to validate boot image info? ------> Post notification and exit | | Yes v No 5. Need to install boot image? ------> Install and reboot | | Yes v No 6. Able to validate configuration? ------> Post notification and exit | | Yes v 7. Merge configuration into running datastore | v 8. Post bootstrap complete notification and exit These interactions are described next. 1. As part of the HTTPS connection, the device will need to authenticate the server certificate presented by the Bootstrap Server. The device authenticates the server certificate using path-validation to one of its preconfigured Bootstrap Server trust anchors. If the device is unable to authenticate the server's certificate, it abandons this Bootstrap Server and exits. 2. The device downloads the ownership voucher from the Bootstrap Server. The device validates the voucher is signed by its Vendor, using its preconfigured trust anchor for device ownership vouchers. The device also validates that its unique identifier is listed by the voucher. If the device is unable to validate the voucher or can not find its unique identifier listed, it Watsen, et al. Expires September 10, 2015 [Page 20] Internet-Draft ZeroTouch March 2015 posts a notification message to that effect and abandons this Bootstrap Server. 3. The device downloads the owner certificate from the Bootstrap Server. The device validates that this certificate is signed by its Vendor, using path-validation to its preconfigured trust anchor for owner certificates. The device also validates that the organization identifier is the same as listed in the ownership voucher, validated in step #2. If the device is unable to validate the certificate or the owner identifier does not match, it posts a notification message to that effect and abandons this Bootstrap Server. 4. The device tries to download the boot image information. If no boot image information is available, it skips the remainder of this step. Otherwise, the device validates the boot image information using the public key from the owner certificate obtained in step #3. If it is unable to authenticate the boot image information, it posts a notification message to that effect and abandons this Bootstrap Server. 5. The device checks if the specified boot-image name matches what the device is currently running. If there is a mismatch, device downloads the new image from the Bootstrap Server and installs it. It is expected that the device will reboot itself in order to activate the new image and, further, that doing so preserves its factory default state such that it will return to this same check again, but then running the correct image. If the device is unable to install the boot-image, it posts a notification message to that effect and abandons this Bootstrap Server. 6. The device downloads the configuration from the Bootstrap Server and validates the configuration using the public key from the owner certificate obtained in step #3. If it is unable to authenticate the configuration, it posts a notification message to that effect and abandons this Bootstrap Server. 7. The device merges the configuration into its running datastore. It is expected that this configuration will provide the information necessary for the device to establish a secure NETCONF connection to its NMS using NETCONF Call Home ([draft-ietf-netconf-call-home]). 8. The device posts a bootstrap completion notification message to the Bootstrap Server and exits. Watsen, et al. Expires September 10, 2015 [Page 21] Internet-Draft ZeroTouch March 2015 5. Network Management System (NMS) 5.1. Overview It is expected that the bootstrapping configuration will guide the device to initiate a secure NETCONF connection to the NMS using NETCONF Call Home [draft-ietf-netconf-call-home]. This section describes what the NMS needs to do to ensure security for the device's connection. 5.2. Precondition +-----------------------------------------------------------------+ | | | | | +-----------------------------------------------------+ | | | | | | | | | | | 1. list of IDevID trust anchor certificates | | | +-----------------------------------------------------+ | | | | +-----------------------------------------------------+ | | | | | | | | | | | 2. list of expected device unique identifiers | | | +-----------------------------------------------------+ | | | | +-----------------------------------------------------+ | | | | | | | | | | | 3. map of device identifiers to login credentials | | | +-----------------------------------------------------+ | | | +-----------------------------------------------------------------+ 1. In order to authenticate a device, the NMS MUST possess the IDevID trust anchor provided by its Vendor to enable verification of the device's IDevID certificate. Specifically, the NMS uses this certificate to validate the identity certificate a device presents when negotiating the SSH or TLS transport for the NETCONF Call Home connection [draft-ietf-netconf-call-home]. Because an NMS may interoperate with multiple vendors, and a vendor may have more than one trust anchor for signing its devices IDevID certificates, this generalizes into the NMS needing a list of trust anchor certificates. These certificates SHOULD be stored in a way that prevents tampering, which is why they are shown in read-only storage in the diagram. Watsen, et al. Expires September 10, 2015 [Page 22] Internet-Draft ZeroTouch March 2015 2. In order for the NMS to validate that a specific device connecting to it is legitimate, it MUST have a list of expected unique device identifiers (e.g., serial-numbers). The unique identifier encoded into the device's IDevID certificate MUST match one of the expected identifiers in order for a device to be considered legitimate. 3. The NMS must have login credentials for each device. These credentials may be, for instance, a private key used for SSH or TLS client authentication. It is expected that a device is able to authenticate the NMS's credentials by virtue of the configuration it downloads from the Bootstrap Server. These private-keys SHOULD be stored securely, such that they can not be easily compromised. 5.3. Connection Handling When receiving a NETCONF call home connection from a device, the NSM completes the connection as specified NETCONF Call Home [draft-ietf-netconf-call-home]. 6. Security Considerations 6.1. 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). Vendors SHOULD deploy Online Certificate State Protocol (OCSP) responders or CRL Distribution Points (CDP) to revoke certificates in case necessary. 6.2. 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 number, manufacture date, and/or sequence number. Knowledge of this information may provide an adversary with details needed to launch an attack. Watsen, et al. Expires September 10, 2015 [Page 23] Internet-Draft ZeroTouch March 2015 7. IANA Considerations 7.1. ZeroTouch Information DHCP Options The following registrations are in accordance to RFC 2939 for "BOOTP Vendor Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 7.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 7.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 8. 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, Stephen Hanna, Wes Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder. Watsen, et al. Expires September 10, 2015 [Page 24] Internet-Draft ZeroTouch March 2015 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. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, March 2011. [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 September 10, 2015 [Page 25] Internet-Draft ZeroTouch March 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 Vendor-specific format outside the of scope for this draft. A tree digram describing an Ownership Voucher: module: ietf-zerotouch-ownership-voucher +--rw voucher +--rw unique-id* string +--rw owner-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-03-09.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 device to ascertain the identity of its rightful owner, as Watsen, et al. Expires September 10, 2015 [Page 26] Internet-Draft ZeroTouch March 2015 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-03-09" { description "Initial version"; reference "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; } // top-level container container voucher { 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 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 created-on { type yang:date-and-time; mandatory true; description "The date this voucher was created"; } leaf expires-on { Watsen, et al. Expires September 10, 2015 [Page 27] Internet-Draft ZeroTouch March 2015 type yang:date-and-time; description "The date this voucher expires, if any"; } leaf signature { type string; mandatory true; description "The signature over the concatenation of all the previous values"; } } } A.2. Bootstrap Server's API ['\' line wrapping added for formatting only] GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/ownership-voucher GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/owner-certificate GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/boot-image GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/configuration POST https://example.com/restconf/operations/ietf-zerotouch-bootstrap-\ server:notification A.3. Bootstrap Configuration This example illustrates a configuration enabling secure NETCONF call-home using standards-based YANG modules. Watsen, et al. Expires September 10, 2015 [Page 28] Internet-Draft ZeroTouch March 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 September 10, 2015 [Page 29] Internet-Draft ZeroTouch March 2015 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 ZeroTouch 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 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 ZeroTouch 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 Vendor signed Ownership Vouchers and Owner certificates. Watsen, et al. Expires September 10, 2015 [Page 30] Internet-Draft ZeroTouch March 2015 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 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 September 10, 2015 [Page 31]