[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-kwatsen-netconf-zerotouch) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

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

    +------------------------------------------------------------------+
    |                             <device>                             |
    |                                                                  |
    |   +----------------------------------------------------------+   |
    |   |                   <read-only storage>                    |   |
    |   |                                                          |   |
    |   | 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)  |   |
    |   +----------------------------------------------------------+   |
    |                                                                  |
    |                    +----------------------+                      |
    |                    |   <secure storage>   |                      |
    |                    |                      |                      |
    |                    |  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

<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <device>
    <unique-id>123456789</unique-id>
    <redirect-information>
      <address>phs.example.com</address>
      <trust-anchor>
        WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
        lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
        zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
        NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
        VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
        V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
        NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
        Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
        WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
        QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
        MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
        25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
        RJSUJQFRStS0Cg==
      </trust-anchor>
    </redirect-information>
  </device>
</devices>

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


<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <device>
    <unique-id>123456789</unique-id>
    <redirect-information>
      <address>phs.example.com</address>
      <trust-anchor>
        WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
        lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
        zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
        NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
        VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
        V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
        NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
        Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
        WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
        QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
        MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
        25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
        RJSUJQFRStS0Cg==
      </trust-anchor>
      <signature>
        SomeSignatureString
      </signature>
    </redirect-information>
    <ownership-voucher>
      <voucher>
        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
      </voucher>
      <issuer-crl>
        QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
        MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
        ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
        RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
        KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
        8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4
        AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF
        WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
        NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
      </issuer-crl>
    </ownership-voucher>
    <owner-certificate>
      <certificate>
        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==
      </certificate>
      <issuer-crl>
        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==
      </issuer-crl>
    </owner-certificate>
  </device>
</devices>

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


<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <device>
    <unique-id>123456789</unique-id>
    <bootstrap-information>
      <boot-image>
        <name>
          boot-image-v3.2R1.6.img
        </name>
        <md5>
          SomeMD5String
        </md5>
        <sha1>
          SomeSha1String
        </sha1>
        <path>
          /some/path/to/raw/file



Watsen, et al.           Expires April 21, 2016                [Page 26]


Internet-Draft                 Zero Touch                   October 2015


        </path>
      </boot-image>
      <configuration>
        <config>
          <!-- from ietf-system.yang -->
          <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
            <authentication>
              <user>
                <name>admin</name>
                <ssh-key>
                  <name>admin's rsa ssh host-key</name>
                  <algorithm>ssh-rsa</algorithm>
                  <key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC
                  jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj
                  E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC
                  WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5
                  vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq
                  EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6
                  gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
                </ssh-key>
              </user>
            </authentication>
          </system>
          <!-- from ietf-netconf-server.yang -->
          <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
            <call-home>
              <application>
                <name>config-mgr</name>
                <ssh>
                  <endpoints>
                    <endpoint>
                      <name>east-data-center</name>
                      <address>11.22.33.44</address>
                    </endpoint>
                    <endpoint>
                      <name>west-data-center</name>
                      <address>55.66.77.88</address>
                    </endpoint>
                  </endpoints>
                  <host-keys>
                    <host-key>my-call-home-x509-key</host-key>
                  </host-keys>
                </ssh>
              </application>
            </call-home>
          </netconf-server>
        </config>
      </configuration>



Watsen, et al.           Expires April 21, 2016                [Page 27]


Internet-Draft                 Zero Touch                   October 2015


    </bootstrap-information>
  </device>
</devices>

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

<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <device>
    <unique-id>123456789</unique-id>
    <bootstrap-information>
      <boot-image>
        <name>
          boot-image-v3.2R1.6.img
        </name>
        <md5>
          SomeMD5String
        </md5>
        <sha1>
          SomeSha1String
        </sha1>
        <path>
          /some/path/to/raw/file
        </path>
        <signature>
          SomeSignatureString
        </signature>
      </boot-image>
      <configuration>



Watsen, et al.           Expires April 21, 2016                [Page 28]


Internet-Draft                 Zero Touch                   October 2015


        <config>
          <!-- from ietf-system.yang -->
          <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
            <authentication>
              <user>
                <name>admin</name>
                <ssh-key>
                  <name>admin's rsa ssh host-key</name>
                  <algorithm>ssh-rsa</algorithm>
                  <key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC
                  jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj
                  E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC
                  WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5
                  vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq
                  EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6
                  gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
                </ssh-key>
              </user>
            </authentication>
          </system>
          <!-- from ietf-netconf-server.yang -->
          <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
            <call-home>
              <application>
                <name>config-mgr</name>
                <ssh>
                  <endpoints>
                    <endpoint>
                      <name>east-data-center</name>
                      <address>11.22.33.44</address>
                    </endpoint>
                    <endpoint>
                      <name>west-data-center</name>
                      <address>55.66.77.88</address>
                    </endpoint>
                  </endpoints>
                  <host-keys>
                    <host-key>my-call-home-x509-key</host-key>
                  </host-keys>
                </ssh>
              </application>
            </call-home>
          </netconf-server>
        </config>
        <signature>
          SomeSignatureString
        </signature>
      </configuration>



Watsen, et al.           Expires April 21, 2016                [Page 29]


Internet-Draft                 Zero Touch                   October 2015


    </bootstrap-information>
    <ownership-voucher>
      <voucher>
        ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
        Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
        MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
        ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
        yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
        WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
        MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
        GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
        X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
        MjAO
      </voucher>
      <issuer-crl>
        QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
        MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
        ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
        RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
        KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
        8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4
        AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF
        WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
        NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
      </issuer-crl>
    </ownership-voucher>
    <owner-certificate>
      <certificate>
        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==
      </certificate>
      <issuer-crl>
        Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
        MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
        ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
        yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
        WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
        MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
        GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
        X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
        MjAO==
      </issuer-crl>
    </owner-certificate>
  </device>
</devices>

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

<input xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <notification-type>bootstrap-complete</notification-type>
  <message>example message</message>
  <ssh-host-keys>
    <ssh-host-key>
      <format>ssh-rsa</format>
      <key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
    </ssh-host-key>
    <ssh-host-key>
      <format>ssh-dsa</format>
      <key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
    </ssh-host-key>
  </ssh-host-keys>
</input>


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


<redirect-information xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <address>phs.example.com</address>
  <trust-anchor>
    WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
    lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
    zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
    NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
    VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
    V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
    NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
    Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
    WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
    QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
    MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
    25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
    RJSUJQFRStS0Cg==
  </trust-anchor>
  <signature>
    SomeSignatureString
  </signature>
</redirect-information>

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.

<bootstrap-information xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <boot-image>
    <name>
      boot-image-v3.2R1.6.img
    </name>
    <md5>
      SomeMD5String
    </md5>
    <sha1>
      SomeSha1String
    </sha1>
    <path>
      /some/path/to/raw/file
    </path>
    <signature>
      SomeSignatureString
    </signature>
  </boot-image>
  <configuration>



Watsen, et al.           Expires April 21, 2016                [Page 33]


Internet-Draft                 Zero Touch                   October 2015


    <config>
      <!-- from ietf-system.yang -->
      <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
        <authentication>
          <user>
            <name>admin</name>
            <ssh-key>
              <name>admin's rsa ssh host-key</name>
              <algorithm>ssh-rsa</algorithm>
              <key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC
              jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj
              E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC
              WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5
              vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq
              EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6
              gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
            </ssh-key>
          </user>
        </authentication>
      </system>
      <!-- from ietf-netconf-server.yang -->
      <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
        <call-home>
          <application>
            <name>config-mgr</name>
            <ssh>
              <endpoints>
                <endpoint>
                  <name>east-data-center</name>
                  <address>11.22.33.44</address>
                </endpoint>
                <endpoint>
                  <name>west-data-center</name>
                  <address>55.66.77.88</address>
                </endpoint>
              </endpoints>
              <host-keys>
                <host-key>my-call-home-x509-key</host-key>
              </host-keys>
            </ssh>
          </application>
        </call-home>
      </netconf-server>
    </config>
    <signature>
      SomeSignatureString
    </signature>
  </configuration>



Watsen, et al.           Expires April 21, 2016                [Page 34]


Internet-Draft                 Zero Touch                   October 2015


</bootstrap-information>

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


<owner-certificate xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <certificate>
    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==
  </certificate>
  <issuer-crl>
    Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
    MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
    ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
    yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
    WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
    MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
    GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
    X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
    MjAO==
  </issuer-crl>
</owner-certificate>

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.

<ownership-voucher xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
  <voucher>
    ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
    Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
    MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
    ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
    yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal
    WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
    MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
    GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
    X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v
    MjAO
  </voucher>
  <issuer-crl>
    QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
    MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
    ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
    RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
    KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
    8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4
    AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF
    WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
    NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
  </issuer-crl>
</ownership-voucher>

6.4.  YANG Module

   The bootstrap server's device-facing interface is normatively defined
   by the following YANG module:

<CODE BEGINS> 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:   <http://tools.ietf.org/wg/netconf/>
    WG List:  <mailto:netconf@ietf.org>
    WG Chair: Mehmet Ersue
              <mailto:mehmet.ersue@nsn.com>
    WG Chair: Mahesh Jethanandani
              <mailto:mjethanandani@gmail.com>
    Editor:   Kent Watsen
              <mailto:kwatsen@juniper.net>";


  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
    }
  }

}

<CODE ENDS>


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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [Std-802.1AR-2009]
              IEEE SA-Standards Board, "IEEE Standard for Local and
              metropolitan area networks - Secure Device Identity",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

   [draft-ietf-netconf-call-home]
              Watsen, K., "NETCONF Call Home (work in progress)",
              October 2014, <https://tools.ietf.org/html/draft-ietf-
              netconf-call-home-04>.

   [draft-ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ieft-netconf-restconf-04 (work in
              progress), 2014, <https://tools.ietf.org/html/draft-ietf-
              netconf-restconf-04>.

   [draft-ietf-netconf-server-model]
              Watsen, K., "NETCONF Server Model (work in progress)",
              September 2014, <http://tools.ietf.org/html/
              draft-ietf-netconf-server-model-06>.




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,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <http://www.rfc-editor.org/info/rfc7317>.









































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:

   <CODE BEGINS> 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:   <http://tools.ietf.org/wg/netconf/>
       WG List:  <mailto:netconf@ietf.org>
       WG Chair: Mehmet Ersue
                 <mailto:mehmet.ersue@nsn.com>
       WG Chair: Mahesh Jethanandani
                 <mailto:mjethanandani@gmail.com>
       Editor:   Kent Watsen
                 <mailto:kwatsen@juniper.net>";


     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";
       }
     }
   }

   <CODE ENDS>


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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/