[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                                                  S. Hanna
Intended status: Standards Track                        Juniper Networks
Expires: April 30, 2015                                        J. Clarke
                                                           Cisco Systems
                                                          M. Abrahamsson
                                                               T-Systems
                                                        October 27, 2014


       Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)
                    draft-ietf-netconf-zerotouch-01

Abstract

   This draft presents a technique for establishing a secure NETCONF
   connection between a newly deployed IP-based device, configured with
   just its factory default settings, and the new 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 30, 2015.

Copyright Notice

   Copyright (c) 2014 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



Watsen, et al.           Expires April 30, 2015                 [Page 1]


Internet-Draft                  ZeroTouch                   October 2014


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Objectives  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.4.  Actors and Roles  . . . . . . . . . . . . . . . . . . . .   5
   2.  Configuration Server  . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Service Interface . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Interactive Interface . . . . . . . . . . . . . . . . . .   7
     2.3.  Transport Security  . . . . . . . . . . . . . . . . . . .   7
     2.4.  Expiration Policy . . . . . . . . . . . . . . . . . . . .   8
     2.5.  Troubleshooting and Auditing  . . . . . . . . . . . . . .   8
   3.  Configuration Signer  . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Signing Configurations  . . . . . . . . . . . . . . . . .   9
     3.3.  Optional Encryption . . . . . . . . . . . . . . . . . . .   9
     3.4.  Delegation of Trust . . . . . . . . . . . . . . . . . . .   9
     3.5.  Delegation to a Specific Customer . . . . . . . . . . . .  10
   4.  Device  . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Factory Default State . . . . . . . . . . . . . . . . . .  11
     4.3.  Boot Sequence . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Network Management System (NMS) . . . . . . . . . . . . . . .  15
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Precondition  . . . . . . . . . . . . . . . . . . . . . .  16
     5.3.  Connection Handling . . . . . . . . . . . . . . . . . . .  17
   6.  Vendor  . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Order Information . . . . . . . . . . . . . . . . . . . .  17
     6.2.  Ownership Validation  . . . . . . . . . . . . . . . . . .  17
   7.  Configlet . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.2.  Data Model  . . . . . . . . . . . . . . . . . . . . . . .  18
     7.3.  Signature . . . . . . . . . . . . . . . . . . . . . . . .  19
     7.4.  Encryption (optional) . . . . . . . . . . . . . . . . . .  19
     7.5.  XSD Schema  . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     8.1.  Immutable storage for trust anchors . . . . . . . . . . .  21
     8.2.  Substitutions . . . . . . . . . . . . . . . . . . . . . .  21
     8.3.  Confidentiality . . . . . . . . . . . . . . . . . . . . .  22
     8.4.  Entropy loss over time  . . . . . . . . . . . . . . . . .  22
     8.5.  Serial Numbers  . . . . . . . . . . . . . . . . . . . . .  22
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     9.1.  ZeroTouch Information DHCP Option . . . . . . . . . . . .  23



Watsen, et al.           Expires April 30, 2015                 [Page 2]


Internet-Draft                  ZeroTouch                   October 2014


       9.1.1.  DHCP v4 Option  . . . . . . . . . . . . . . . . . . .  23
       9.1.2.  DHCP v6 Option  . . . . . . . . . . . . . . . . . . .  23
     9.2.  Media Types for Boot Images and Configurations  . . . . .  23
       9.2.1.  application/zerotouch-configlet . . . . . . . . . . .  24
       9.2.2.  application/zerotouch-bootimage . . . . . . . . . . .  25
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     11.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  28
     A.1.  Unsigned Configlet  . . . . . . . . . . . . . . . . . . .  28
     A.2.  Signed Configlet  . . . . . . . . . . . . . . . . . . . .  29
     A.3.  Encrypted Configlet . . . . . . . . . . . . . . . . . . .  32
     A.4.  Signed Encrypted Configlet  . . . . . . . . . . . . . . .  33
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  36
     B.1.  ID to 00  . . . . . . . . . . . . . . . . . . . . . . . .  36
     B.2.  00 to 01  . . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Objectives

   A fundamental business requirement is to reduce operational costs
   where possible.  Deploying new IP-based devices is many times one of
   the largest costs in running a network, as sending trained
   specialists to each site to do an installation is both cost
   prohibitive and does not scale.

   Both networking vendors and standard bodies have tried to address
   this issue, with varying levels of success.  For instance, the
   Broadband Forum TR-069 specification [TR069] relies solely on DHCP
   for NMS discovery, but this can only work in environments where the
   DHCP server is locally administered, which is not the case when the
   device is connected to an ISP's network.  In another example, some
   network vendors have enabled their devices to load an initial
   configuration from removable storage media (e.g., a USB flash drive),
   but not all devices have such ports.

   The solution presented herein, ZeroTouch, enables a device to
   securely obtain an initial configuration from the network without any
   operator intervention.  The discovered configuration initiates the




Watsen, et al.           Expires April 30, 2015                 [Page 3]


Internet-Draft                  ZeroTouch                   October 2014


   device to "call home" using either SSH or TLS, as described in
   [NETCONF-CALL-HOME].




1.3.  Use Cases

   o  Connecting to a remotely administered network

         This use-case involves scenarios, such as a remote branch
         office or convenience store, whereby the device connects to an
         ISP's network.  In this case, the device receives only generic
         networking settings (address, netmask, gateway, DNS servers,
         etc.) provided by the ISP, with no site-specific
         customizations, such that the device has no recourse but to
         reach out to the presumably insecure network for its initial
         configuration.

   o  Connecting to a locally administered network

         This use-case covers all other scenarios and differs only in
         that the device may additionally receive some site-specific
         information to guide its call home process, which could then
         direct it to a local server for its initial configuration.  If
         no site-specific information is provided, or the device is
         unable to use the information provided, it can then reach out
         to network just as it would for a remotely administered
         network.






















Watsen, et al.           Expires April 30, 2015                 [Page 4]


Internet-Draft                  ZeroTouch                   October 2014


1.4.  Actors and Roles

                                  fetches Configlet and
                    +----------+  boot-image, if needed
       +------------|  Device  |---------------------+
       |            +----------+                     |
       |                 ^                           |
       |                 |                           V
       | call home       | manufactures         +----------+
       |                 | with necessary       |  Config  |
       |                 | default state        |  Server  |<----+
       |                 | for ZeroTouch        +----------+     |
       |                 |                                       |
       |                 |                                       |
       |            +----------+  delegates trust                |
       |            |  Vendor  |-------------------+             |
       |            +----------+                   |             |
       |               ^    ^                      |             |
       |               |    |                      V             |
       |               |    |                 +----------+       |
       |       imports |    | validate owner  |  Config  |       |
       |         trust |    +-----------------|  Signer  |       |
       |        anchor |                      +----------+       |
       |               |                           ^             |
       |               |                           |             |
       |            +---------+  requests signing  |             |
       +----------->|   NMS   |--------------------+             |
                    +---------+                                  |
                        |                                        |
                        +----------------------------------------+
                          signed Configlet and boot-image file

   Though not represented as a box in the diagram, the Configlet is also
   a first-class object in the solution.

   o  Configlet

         A Configlet is an XML document that, when loaded onto a device,
         configures the device to initiate a call home connection to a
         deployment specific NMS, as well as set a local administrator
         account for the NMS to log into.  The Configlet is signed and
         optionally encrypted.  More information about Configlets is in
         Section 7.

   o  Configuration Server

         A Configuration Server hosts Configlets and boot-images to be
         downloaded over a network via HTTP/S.  Configuration Servers



Watsen, et al.           Expires April 30, 2015                 [Page 5]


Internet-Draft                  ZeroTouch                   October 2014


         can be deployed either on the locally administered network or
         on some external network (e.g., the Internet).  Configuration
         Servers are known to devices in the form of a URI, which can be
         either preconfigured or dynamically discovered.  More
         information about Configuration Servers is in Section 2.

   o  Configuration Signer

         A Configuration Signer is an entity that the device's vendor
         has delegated the Configlet-signing function to.  A
         Configuration Signer only needs to ensure that the requestor is
         the rightful owner of the device to which a configuration is
         destined.  A Configuration Signer may be site-specific or an
         external entity.  More information about Configuration Signers
         is in Section 3.

   o  Device

         The device is the networking entity that initiates ZeroTouch,
         whenever booting with its factory default settings.  The device
         is preconfigured with a secure device identity, Configuration
         Servers URIs, and certificates for both Configuration Signers
         and Configuration Servers it trusts by default.  A device may
         dynamically discover additional URIs and certificates from a
         locally-administered network.  More information about Devices
         is in Section 4.

   o  Network Management System

         The NMS is the deployment-specific system that devices initiate
         their call home connections to.  The NMS must be configured
         with vendor-specific trust anchors and unique device
         identifiers.  The administrators of the NMS system interact
         with Configuration Signer and Configuration Server systems to
         stage the the device configurations.  More information about
         Network Management Systems is in Section 5.

   o  Vendor

         Vendors manufacture the devices with secure device identities
         and preconfigured Configuration URIs, and Configuration Signer
         certificates.  Vendors are the de facto Configuration Signer
         for the devices it manufactures, but may delegate that role to
         external Configuration Signers.  More information about Vendors
         is in Section 6.






Watsen, et al.           Expires April 30, 2015                 [Page 6]


Internet-Draft                  ZeroTouch                   October 2014


2.  Configuration Server

   A Configuration Server is the entity hosting configurations that can
   be downloaded over a network.  This section describes the service
   interface a Configuration Server MUST implement as well as what's
   needed for transport security.

2.1.  Service Interface

   Configuration Servers are known to devices in the form of a URI.
   Configuration Servers MUST support the URI schemes "https" and
   "http".  Other URI schemes are not supported.

   When accessing a Configuration Server, the device appends its unique
   device identifier (UID) to the URI.  The unique identifier MUST be
   the same as the identifier stored within the device's IDevID
   certificate, which is described in Section 4.2.

   For instance, if the URI were:

         http://example.com/zerotouch/devices/
         https://example.com/zerotouch?id=

   then the device would try to access:

         http://example.com/zerotouch/devices/<uid>
         https://example.com/zerotouch?id=<uid>

   When accessing the Configuration Server, the HTTP Accept-Type MUST be
   set to either "application/zerotouch-configlet" or "application/
   zerotouch-bootimage".  Please see Section 9.2.  A wildcard Accept-
   Type (e.g., */*) SHOULD default to "application/zerotouch-configlet".

2.2.  Interactive Interface

   The Configuration server SHOULD provide a user-facing interface to
   enable the end-user to provide a Configlet and, optionally, a
   bootimage file.  How the Configlet and bootimage file are provided to
   the Configuration Server is outside the scope of this document.




2.3.  Transport Security

   As described in Section 3, configurations MUST be signed and MAY be
   encrypted.  As such, transport-level security is not needed to assure
   authenticity or confidentiality of the configuration itself.



Watsen, et al.           Expires April 30, 2015                 [Page 7]


Internet-Draft                  ZeroTouch                   October 2014


   However, transport-level security enables devices to authenticate the
   Configuration Server and also extends confidentiality to the
   application-level protocol.  Therefore, it is RECOMMENDED that only
   secure URL schemes are used (see Section 2.1).

   If a Configuration Server uses X.509-based encryption, then its X.509
   certificate MUST have a chain of trust to a trust anchor known to
   devices (see Section 4.2.  More specifically, the Configuration
   Server MUST possess all the intermediate certificates leading to the
   trust anchor.

   When a Configuration Server negotiates encryption with the device, it
   provides the chain of certificates, from its server specific
   certificate to, but not including, its trust anchor.  Including the
   trust anchor's certificate is unnecessary since the device MUST be
   pre-provisioned with it.  Devices need the chain of certificates to
   be passed so they can validate the server using only a simple list of
   Configuration Server trust anchors.

2.4.  Expiration Policy

   An expiration policy is needed to limit how long a Configuration
   Server needs to retain a configuration and, in turn, how many
   configurations it might need to retain at a given time.

   It is expected that Configuration Servers will enable retention
   information to be given at the same time as when the configuration is
   provided to it.  Options should be temporal in nature, not based on
   access counts, so as to thwart a DoS attack whereby the configuration
   is accessed by an entity other than the device.  Configuration
   Servers SHOULD put a limit on the maximum amount of time it will hold
   onto a configuration before purging it, even if the configuration had
   never been accessed.

2.5.  Troubleshooting and Auditing

   In order to facilitate troubleshooting and auditing, the
   Configuration Server SHOULD record into a log a record of the various
   Configlet download requests.  This draft does not define what
   information should be kept or for how long.











Watsen, et al.           Expires April 30, 2015                 [Page 8]


Internet-Draft                  ZeroTouch                   October 2014


3.  Configuration Signer

3.1.  Overview

   A Configuration Signer MUST be able to sign configurations.  This
   function requires the Configuration Signer be able to authenticate
   that the requestor is the true owner of the device, as identified
   within the contents of the configuration being signed.

   The user interface a Configuration Signer provides to perform its
   role is outside the scope of this document.  However, in order to
   meet operational expectations, the time it takes to respond to a
   request should be as expeditious as possible.

   A Configuration Signer does not need to retain a configuration after
   signing it.  The Configuration Signer SHOULD retain an audit log for
   indemnification purposes.

3.2.  Signing Configurations

   A Configuration Signer MUST have an X.509 certificate with Key Usage
   capable of signing data (digitalSignature) and be signed by a
   certificate authority having a chain of trust leading to a trust
   anchor known to the devices loading its Configlets.  The
   Configuration Signer MUST possess all intermediate certificates
   leading to its trust anchor.

   When a Configuration Signer signs a Configlet, it attaches both the
   signature and the chain of X.509 certificates, including its own, but
   not necessarily including the trust anchor's certificate.  This chain
   of certificates is needed so a device can validate a Configlet using
   only the Configuration Signer trust anchors known to it.

3.3.  Optional Encryption

   A Configuration Signer MAY optionally encrypt configurations prior to
   signing them.  This function requires the Configuration Signer know
   the device's unique public key, as encoded within its secure device
   identity certificate.

3.4.  Delegation of Trust

   A device's vendor is the root of trust for all of its devices.  That
   is, the vendor's devices implicitly trust the vendor for such things
   as software images, subscription updates, and licenses.  As such, the
   vendor is the ultimate Configuration Signer for its devices.





Watsen, et al.           Expires April 30, 2015                 [Page 9]


Internet-Draft                  ZeroTouch                   October 2014


   However, both vendors and its customers may prefer that this role be
   performed by another entity.  For instance, a vendor may not want
   this role due to it being outside its primary business function, and
   customers may not want the vendor to have this role for privacy
   reasons.

   It is therefore provided that a vendor MAY delegate the Configuration
   Signer role to other entities.  Using X.509 certificates, the Vendor
   need only sign the delegate's certificate signing request (CSR),
   providing back to the delegate a signed X.509 certificate
   authenticating its ability to perform the signing function.

   In order enable a delegate to fulfill its operational role, as
   described in Section 3.1, the vendor MUST provide a mechanism that
   can be used to authenticate if a given requestor is the true owner of
   a specific device.  Additionally, to support Configuration Signers
   that want to encrypt configurations, the vendor MUST also provide a
   means for the Configuration Signer to know the public key for a given
   device.  How the vendor provides this information to Configuration
   Signers is outside the scope of this document.

3.5.  Delegation to a Specific Customer

   The general expectation is that the Configuration Signer is an
   impartial 3rd-party.  However, certain deployments may want to be
   able to perform the function for themselves.  Yet without
   constraints, that deployment could sign configurations for devices
   that do not belong to it.

   Resolving this concern is possible when 1) the deployment specific
   Configuration Signer's certificate is annotated with a customer
   identifier and 2) the devices sold to that customer have that same
   identifier encoded into their secure device identifier.

   This entails the vendor augmenting its manufacturing process for
   these special devices, which would likely be sold directly to the
   customer, as opposed to through a sales channel.  This takes
   extraordinary effort and likely only implemented for the most
   important customers, if at all.

4.  Device

4.1.  Overview

   While the wholistic solution, ZeroTouch, involves a number of
   entities, a device being powered-on is the essential event that sets
   things in motion.




Watsen, et al.           Expires April 30, 2015                [Page 10]


Internet-Draft                  ZeroTouch                   October 2014


   Whenever a device boots with its factory default settings, it
   initiates ZeroTouch with the goal of finding a configuration to
   initialize itself with.  Once a configuration is found, the device
   initializes its running datastore with it and then enters normal
   operation.  Since the configuration initializes the device to call
   home upon entering its normal operating mode, the device immediately
   begins trying to establish a secure connection with the deployment
   specific NMS.

4.2.  Factory Default State

    +------------------------------------------------------------------+
    |                            <device>                              |
    |                                                                  |
    |     +------------------------------------------------------+     |
    |     |                <immutable storage>                   |     |
    |     |                                                      |     |
    |     |  list of Configuration Signer trust anchor certs     |     |
    |     |  list of Configuration Server trust anchor certs     |     |
    |     +------------------------------------------------------+     |
    |                                                                  |
    |   +----------------------------------------------------------+   |
    |   |                    <other storage>                       |   |
    |   |                                                          |   |
    |   |  two sets of Configuration Server URIs                   |   |
    |   |  IDevID entity & associated intermediate certificate(s)  |   |
    |   +----------------------------------------------------------+   |
    |                                                                  |
    |                    +----------------------+                      |
    |                    |   <secure storage>   |                      |
    |                    |                      |                      |
    |                    |  IDevID private key  |                      |
    |                    +----------------------+                      |
    |                                                                  |
    +------------------------------------------------------------------+

   Devices supporting ZeroTouch MUST have a manufacturer-provisioned
   secure device identifier, as defined in [Std-802.1AR-2009].  This
   identifier is known by the IEEE standard as the Initial Device
   Identifier (IDevID).  The IDevID includes both an X.509 certificate,
   encoding a globally unique per-device identifier, and a chain of
   X.509 certificates leading to the manufacturer's well-known trust
   anchor.  The IDevID is needed in order for the NMS to positively
   authenticate a device.  The IDevID certificate MUST be used by the
   NETCONF server as its SSH host-key (see [RFC6187]) or its TLS server
   certificate, depending on which protocol is used.





Watsen, et al.           Expires April 30, 2015                [Page 11]


Internet-Draft                  ZeroTouch                   October 2014


   Devices supporting ZeroTouch MUST be pre-provisioned with one or more
   URIs for Internet-based Configuration Servers.  These URIs SHOULD be
   partitioned into one set that contains secure schemes (e.g. https://)
   and another set that contains insecure schemes (e.g., http://).  The
   reason for partitioning the URIs is so all the secure schemes can
   attempted before any of the insecure schemes (see Section 4.3).  When
   using a secure scheme, the Configuration Server MUST be authenticated
   using a trust anchor the device possesses.  As each Configuration
   Server may use a different trust anchor, this generalizes to a list
   of Configuration Server trust anchor certificates.

   In order to verify the signature on retrieved configurations, devices
   supporting ZeroTouch MUST also possess the trust anchor for the
   Configuration Signer that signed the configuration.  Generally, only
   the manufacturer's trust anchor is needed, as it can then delegate
   trust for 3rd-party Configuration Signers (see Section 3.4).
   However, for various reasons, there may be a need for more than one
   root anchor and therefore this generalizes to a list of Configuration
   Signer trust anchor certificates.

   Devices SHOULD ensure that the certificates for its trust anchors are
   protected from external modification.  It is for this reason that the
   diagram shows the Configuration Signer and Configuration Server
   certificates in immutable storage.  Similarly, per
   [Std-802.1AR-2009], the IDevID private key shall be stored
   confidentially and not available outside the IDevID module, hence the
   diagram shows it is held within secure storage.

4.3.  Boot Sequence

       DEVICE           DHCP                         CONFIGURATION   NMS
         |          SERVER/RELAY                        SERVERS       |
         |                |                                |          |
     +-->|                |                                |          |
     |   |                |                                |          |
     |   |--[if running config != factory default, boot normally]--+  |
     |   |                |                                |       |  |
   <---------------------------------------------------------------+  |
     |   |                |                                |          |
     |   |                |                                |          |
     |   |                |                                |          |
     |   |--(discovery)-->| [if no dhcp server found, boot normally]  |
     |   |                |                                |          |
     |   |  +---(offer)---|                                |          |
     |   |  |             |                                |          |
     |   |  +--[add any listed config servers to built-in list]--+    |
     |   |                |                                |     |    |
     |   |<------------------------------------------------------+    |



Watsen, et al.           Expires April 30, 2015                [Page 12]


Internet-Draft                  ZeroTouch                   October 2014


     |   |                |                                |          |
     |   |                |                                |          |
     |   |                |                                |          |
     |   | (iterate until match, else boot normally)       |          |
     |   |------------------------------------------------>|          |
     |   |                |                                |          |
     |   |<------------------------------(zerotouch info)--|          |
     |   |                |                                |          |
     |   |                |                                |          |
     |   |                |                                |          |
     |   |--[if current image != expected, get image]----->|          |
     |   |                |                                |          |
     |   |  +-------------------------------------(image)--|          |
     |   |  |             |                                |          |
     |   |  +--[if image valid, install & reboot]--+       |          |
     |   |                |                        |       |          |
     +---------------------------------------------+       |          |
         |                |                                |          |
         |                |                                |          |
         |                |                                |          |
         |--[get config]---------------------------------->|          |
         |                |                                |          |
         |  +------------------------------------(config)--|          |
         |  |             |                                |          |
         |  +--[if config valid, merge into running]--+    |          |
         |                |                           |    |          |
         |     +--------------------------------------+    |          |
         |     |          |                                |          |
         |     +--[per new configuration, call home]----------------->|
         |                |                                |          |
         |                |                                |          |

   Whenever a device boots with its factory default settings, it
   initiates ZeroTouch with the goal of finding a configuration that
   will enable it to call home to its deployment-specific NMS.

   The process begins with the device using the DHCP protocol to obtain
   a dynamic assignment for its networking stack.  When broadcasting the
   DISCOVERY request, the device may provide any DHCP options to
   identify itself or the type of device it is (e.g.  IPV4 options 60 or
   61).

   If the DHCP servers reside on a locally administered network (see
   Section 1.3), then their OFFER responses MAY include the ZeroTouch
   Information DHCP option defined in Section 9.1, as well as the legacy
   DHCP options for TFTP server name, bootfile name, and/or vendor
   specific information (e.g.  IPv4 options 43, 66, 67).




Watsen, et al.           Expires April 30, 2015                [Page 13]


Internet-Draft                  ZeroTouch                   October 2014


   If a DHCP server provides both the ZeroTouch Information and the
   vendor specific information DHCP options, then the ZeroTouch
   Information option MUST be processed first.  After exhausting all
   ZeroTouch options without being able to call home, a device MAY then
   process the information provided by the legacy DHCP options.

   The ZeroTouch Information option Section 9.1 provides a set of
   Configuration Server URIs.  If returned by the DHCP server, the
   device MUST append each URI to the end of one of its two sets of
   Configuration Server URIs, depending on if the URI's scheme is secure
   or not.  URIs added this way MUST remain distinguishable from those
   URIs the device was shipped with, for reasons discussed next.

   The device then iterates over its two sets of Configuration Server
   URIs.  The device MUST first try all the URIs from the set having
   secure schemes before trying any of the URIs from the set having
   insecure schemes.  For each URI, until a match is found and
   successfully loaded, the device attempts to initialize itself from
   the URI.  If the URI uses a secure scheme (e.g., https), the device
   MUST validate the Configuration Server's certificate using one of its
   Configuration Server trust anchors.  If the device is unable to
   verify the server's certificate, the device MUST skip that URI.  If
   the device reaches the end of all its URIs without finding a usable
   match, it SHOULD continue its normal boot sequence using its factory
   default configuration.

   When the device is accessing a Configuration Server URI that it was
   shipped with (i.e. not discovered while initializing its networking),
   it MUST do so by appending its UID to the URI string and using the
   Accept-Type "application/zerotouch-configlet", as described in
   Section 2.  For URIs discovered via the ZeroTouch Information option,
   the device MAY also try the raw URI after trying the permutation
   using its UID.

   If the Configuration Server returns a configuration, the device MUST
   first verify it before use.  Configuration verification entails both
   verifying the configuration's signature using the device's list of
   Configuration Signer trust anchors, and also verifying that the
   unique identifier within the Configlet matches the device's unique
   identifier.

   Once the configuration is authenticated, the device MUST compare its
   software image version with the expected version specified within the
   configuration.  If there is a mismatch, the device MUST download the
   correct image version from the Configuration Server, by appending its
   UID to the Configuration Server's URI string and using the Accept-
   Type "application/zerotouch-bootimage", as described in Section 2.
   For URIs discovered via the ZeroTouch Information option, the device



Watsen, et al.           Expires April 30, 2015                [Page 14]


Internet-Draft                  ZeroTouch                   October 2014


   MAY also try the raw URI after first trying the permutation using its
   UID.  Once the image has been downloaded, the device MUST install it
   and reboot, still with the factory default settings configured, so
   that ZeroTouch restarts when the device comes back up.

   If the device is running the correct software image version, it
   merges the Configlet's contents into its running configuration.  This
   step effectively modifies the device so that it is no longer having
   its factory default setting.  Thus, at this point, a reboot is no
   longer expected to start the ZeroTouch process.

   Though not technically required, the Configlet is presumed to have
   configured the device to "call home".  As soon as this configuration
   is merged into the running configuration, the device SHOULD
   immediately begin trying to establish the call home connection, as
   specified by the Configlet.

   If configured to establish a SSH connection, the the device MUST use
   its IDevID and associated intermediate X.509 certificates as its host
   key per RFC 6187 [RFC6187].  If configured to establish a TLS
   connection, the device MUST use its IDevID and associated
   intermediate X.509 certificates as its server-side certificate for
   the TLS connection.

   In order to facilitate troubleshooting, the device SHOULD record into
   a log information relating to its stepping through the ZeroTouch
   sequence of steps.  This draft does not define any specific log
   messages, for instance, for Syslog or SNMP.

5.  Network Management System (NMS)

5.1.  Overview

   The NMS is the ultimate destination of ZeroTouch for a device.  It is
   the NMS's network address configured in the Configlet.  The device
   will initiate a call home connection to the NMS, using either SSH or
   TLS, as configured by the Configlet loaded.














Watsen, et al.           Expires April 30, 2015                [Page 15]


Internet-Draft                  ZeroTouch                   October 2014


5.2.  Precondition

    +------------------------------------------------------------------+
    |                              <nsm>                               |
    |                                                                  |
    |     +------------------------------------------------------+     |
    |     |                <immutable storage>                   |     |
    |     |                                                      |     |
    |     |  list of IDevID trust anchor certificates            |     |
    |     |  list of expected device unique identifiers          |     |
    |     +------------------------------------------------------+     |
    |                                                                  |
    |       +--------------------------------------------------+       |
    |       |                 <secure storage>                 |       |
    |       |                                                  |       |
    |       |  map of device identifiers to login credentials  |       |
    |       +--------------------------------------------------+       |
    |                                                                  |
    +------------------------------------------------------------------+

   In order to authenticate the device, the NMS MUST possess the X.509
   certificate for the trust anchor leading to the device's entity
   certificate.  The NMS uses this certificate to validate the server-
   certificate the device presents during SSH or TLS transport
   negotiation.  Because an NMS may interoperate with multiple vendors,
   and a vendor may have more than one trust anchor for signing its
   devices IDevID certificates, this generalizes into the NMS needing a
   list of trust anchor certificates.  This certificates SHOULD be
   stored in a way that prevents tampering, which is why they are shown
   in immutable storage in the diagram.

   In order for the NMS to validate that the specific device connecting
   to it is expected, it MUST have a list of unique device identifiers
   that it can use to validate the device's IDevID certificate with.
   The list SHOULD be protected from external modification, which is why
   it is shown in immutable storage in the diagram.  In order for the
   NMS to know the unique identifiers, device manufacturers will need to
   provide a mechanism to convey this information to its customers.
   This draft not specify a format for this information exchange.

   In addition to authenticating the device, the NMS must also
   authenticate itself to the device.  How this is done is deployment
   specific, but generalizes to the NMS needing to have login
   credentials for each device.  These credentials will entail knowing a
   secret (e.g., password, private key).  For this reason the diagram
   shows the NMS storing a map of device credentials in secure storage.





Watsen, et al.           Expires April 30, 2015                [Page 16]


Internet-Draft                  ZeroTouch                   October 2014


5.3.  Connection Handling

   When receiving a NETCONF call home connection from a device, the NSM
   completes the connection as specified NETCONF Call Home
   [NETCONF-CALL-HOME].

6.  Vendor

6.1.  Order Information

   In order for a Vendor's customers to configure their NMSs with what
   devices are expected, as well as to know how to set the "unique-
   identifier" field within a Configlet when requesting a signing,
   Vendors need to provide a mechanism for customers to obtain the
   unique identifier value for the devices they have ordered.  For
   instance, customers could receive emails containing shipping
   information for their devices.

   Additionally, to facilitate workflows where the devices are initially
   received by a customer-specific warehouse, or moved after having been
   unboxed, it is ideal for the unique identifier to be easily tracked
   through labels affixed to the device as well as the box it is
   packaged in.  A device's serial number is commonly treated this way
   and would be suitable for this purpose, so long as it is directly
   related to its IDevID identity.

6.2.  Ownership Validation

   In order for Configuration Signers to validate that a requestor is
   the true owner of a device (i.e. its IDevID identity), Vendors need
   to provide a mechanism enabling a near real-time lookup.  The
   interface used to implement this lookup is outside the scope of this
   document.

7.  Configlet

7.1.  Overview

   A Configlet is an XML file, containing specific YANG-defined
   configuration, that has been signed by a trusted signer known to the
   device (e.g., the device's manufacturer).

   The Configlet data-model, defined by the XSD schema in Section 7.5,
   contains information for the device to ensure that it's safe for it
   to load the configlet (i.e. target-requirements) along with a
   payload, the configuration the device is to merge into its running
   datastore.




Watsen, et al.           Expires April 30, 2015                [Page 17]


Internet-Draft                  ZeroTouch                   October 2014


   In order for the device to call home, the configuration contained
   within the Configlet MUST at least configure a local user account and
   configure the connection information for the NMS the device is to
   call home to.  This configuration MAY use IETF-defined modules "ietf-
   system" [RFC7317] and "ietf-netconf-server" [NETCONF-SERVER-MODEL].

   The signature on the Configlet is enveloped, meaning that the
   signature is contained inside the XML file itself.  The signature
   block also contains the X.509 certificate of the Configuration Signer
   and its chain of trust.

   Once a device authenticates the signature on a Configlet and matches
   the unique identifier (e.g., serial number) within the Configlet, it
   merges the configuration contained in the Configlet into its running
   datastore.

7.2.  Data Model

   module: ietf-netconf-zerotouch
      +--rw configlet
         +--rw target-requirements
         |  +--rw unique-identifier    string
         |  +--rw software-version     string
         +--rw configuration

   The Configlet's data model is no more than a wrapper around a header
   (i.e. <target-requirements>) and a payload (i.e. <configuration>).

   The <target-requirements> element contains information that MUST be
   validated by the device prior to processing the <configuration>
   element.  Specifically, it contains:

   o  unique-identifier

         The unique-identifier field is used to ensure that the
         Configlet is loaded onto the targeted device and no other.
         This field is also used by the Configuration Signer, when
         ensuring the requestor is the true owner of the device.  The
         value MUST be the same as the 'subject' field in the device's
         IDevID credential, as specified by section 7.2.8 in IEEE Std
         802.1AR-2009.

   o  software-version

         The software-version field is used to ensure the device is
         running the right software version prior to loading the
         configuration (e.g., 14.1R2.5).  If the device finds that it is




Watsen, et al.           Expires April 30, 2015                [Page 18]


Internet-Draft                  ZeroTouch                   October 2014


         not running the correct version of software, it MUST pull the
         correct version from the Configuration Server.

   The <configuration> element contains the configuration that is to be
   committed to the device's running datastore.  This element uses the
   "anyxml" type, enabling it to contain either vendor-specific or
   standards-based data models.  When using standard models, in order to
   complete a call home connection, only the following is needed:

   o  The "authentication" subtree from "ietf-system", defined in
      [RFC7317].

   o  The "call-home" subtree from "ietf-netconf-server", defined in
      [NETCONF-SERVER-MODEL].

7.3.  Signature

   All Configlets MUST be signed by a Configuration Signer in order to
   be authentic.  Devices MUST reject any Configlet that is either
   unsigned or having an invalid signature.  Configlets are signed using
   the W3C standard "XML Signature Syntax and Processing" [XMLSIG].  The
   entire contents of the Configlet MUST be signed.  The signature block
   must also include the Configuration Signer's certificate and any
   intermediate certificates leading to a Configuration Signer trust
   anchor.  A signed Configlet example is in section Appendix A.2.

7.4.  Encryption (optional)

   Configlets MAY optionally be encrypted prior to being signed.
   Encrypting the Configlet provides confidentiality for the Configlet's
   contents without relying on transport-level security.  Configlets are
   encrypted using the W3C standard "XML Encryption Syntax and
   Processing" [XMLENC].  The entire contents of the Configlet MUST be
   encrypted.  An encrypted Configlet example is in section
   Appendix A.4.

7.5.  XSD Schema

   Following is the XSD for the Configlet:

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch"
   targetNamespace="urn:ietf:params:xml:ns:ietf-netconf-zerotouch"
   elementFormDefault="qualified">
   <xs:element name="configlet">
     <xs:complexType>
        <xs:sequence>



Watsen, et al.           Expires April 30, 2015                [Page 19]


Internet-Draft                  ZeroTouch                   October 2014


          <xs:element name="target-requirements">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="unique-identifier" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      Specifies the unique identifier of the device that
                      is to process this  Configlet.  The value MUST be
                      the same as the 'subject' field in the device's
                      DevID credential, as specified by section 7.2.8
                      in IEEE Std 802.1AR-2009.
                    </xs:documentation>
                  </xs:annotation>
                </xs:element>
                <xs:element name="software-version" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      In order to process this Configlet, the device
                      MUST must be running this version of software.
                      The value is device-specific, but it MUST be
                      an exact match (e.g., 14.1R2.5)
                    </xs:documentation>
                  </xs:annotation>
                </xs:element>
              </xs:sequence>
            </xs:complexType>
          </xs:element>
          <xs:element name="configuration">
            <xs:annotation>
              <xs:documentation>
                The configuration to be committed to the device's
                running datastore.  The configuration MUST be valid
                for the target device.

                Devices supporting ZeroTouch SHOULD support the
                following standard data-models:

                    ietf-system          // RFC 7317
                    ietf-netconf-server  // RFC YYYY

                These two data models contain everything needed to
                support NETCONF call home using either SSH or TLS.

                References:

                  RFC 7317: A YANG Data Model for System Management
                  RFC YYYY: NETCONF Server Configuration Model
              </xs:documentation>



Watsen, et al.           Expires April 30, 2015                [Page 20]


Internet-Draft                  ZeroTouch                   October 2014


            </xs:annotation>
            <xs:complexType>
             <xs:sequence maxOccurs="unbounded">
               <xs:any processContents="skip"/>
             </xs:sequence>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
     </xs:complexType>
   </xs:element>
 </xs:schema>

8.  Security Considerations

8.1.  Immutable storage for trust anchors

   Devices SHOULD ensure that all its trust anchor certificates,
   including those for the Configuration Signer and Configuration
   Server, are protected from external modification.  It is for this
   reason that the diagram in Section 4.2 shows them in immutable
   storage.

   However, it may be necessary to update these certificates over time
   (e.g., the vendor 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.

8.2.  Substitutions

   It is generally not possible to substitute a Configlet created for a
   different device, since devices assert that the Configlet contains
   their unique identifier (e.g., serial number).

   However, it is possible to substitute a Configlet created for a
   device with a different Configlet created for the same device.
   Generally, unless imposed by the Configuration Signers, there is no
   limit to the number of Configlets that may be generated for a given
   device.  This could be resolved, in part, by placing a timestamp into
   the Configlet and ensuring devices do not load Configlets older than
   some amount, but this requires the devices have an accurate clock
   when validating a Configlet and for Configuration Signers to not sign
   a Configlet when another Configlet is still active.








Watsen, et al.           Expires April 30, 2015                [Page 21]


Internet-Draft                  ZeroTouch                   October 2014


8.3.  Confidentiality

   This draft allows devices to use insecure schemes when doing a
   Configuration Server lookup.  This is deemed acceptable because the
   Configlet is tamper-proof, since it MUST be signed, only
   confidentiality is lost.

   Confidentiality of a Configlet's contents is assured when either the
   Configlet is encrypted or when the a secure scheme is used when
   accessing the Configuration Server.

   Some confidentiality is lost when an insecure scheme is used to
   access a Configuration Server, as then the device's unique identifier
   is in the clear.

   Given the fairly regular format for unique identifiers, it is
   possible that an adversary to guess unique identifiers and access a
   device's Configlet.  Configlets that have been encrypted do not
   disclose any confidential information.

8.4.  Entropy loss over time

   Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that
   IDevID certificate should never expire (i.e. having a notAfter
   99991231235959Z).  Given the long-lived nature of these certificates,
   it is paramount to use a strong key length (e.g., 512-bit ECC).
   Vendors SHOULD deploy Online Certificate State Protocol (OCSP)
   responders or CRL Distribution Points (CDP) to revoke certificates in
   case necessary.

8.5.  Serial Numbers

   This draft mentions using the device's serial number as its unique
   identifier in its IDevID certificate.  This is because serial numbers
   are ubiquitous and prominently contained in invoices and on labels
   affixed to devices and their packaging.  That said, serial numbers
   many times encode revealing information, such as the device's model
   number, manufacture date, and/or sequence number.  Knowledge of this
   information may provide an adversary with details needed to launch an
   attack.  To address this concern, the certificate could contain the
   hash of the serial number instead, which the NMS could also compute,
   but doing so is much less intuitive and raises questions if it is
   just security through obscurity.








Watsen, et al.           Expires April 30, 2015                [Page 22]


Internet-Draft                  ZeroTouch                   October 2014


9.  IANA Considerations

9.1.  ZeroTouch Information DHCP Option

   The following registration is in accordance to RFC 2939 for "BOOTP
   Vendor Extensions and DHCP Options" registry maintained at
   http://www.iana.org/assignments/bootp-dhcp-parameters.

9.1.1.  DHCP v4 Option

      Tag: XXX

      Name: Zero Touch Information

      Description: Returns a list of null-terminated Configuration
                   Server URIs

       Code   Len
      +-----+-----+------+------+----
      | XXX |  n  | url1 | url2 | ...
      +-----+-----+------+------+----

      Reference: RFC XXXX

9.1.2.  DHCP v6 Option

      Tag: YYY

      Name: Zero Touch Information

      Description: Returns a list of null-terminated Configuration
                   Server URIs

       Code   Len
      +-----+-----+------+------+----
      | YYY |  n  | url1 | url2 | ...
      +-----+-----+------+------+----

      Reference: RFC XXXX

9.2.  Media Types for Boot Images and Configurations

   The following registrations are in accordance to RFC 6838.








Watsen, et al.           Expires April 30, 2015                [Page 23]


Internet-Draft                  ZeroTouch                   October 2014


9.2.1.  application/zerotouch-configlet


      Type name: application

      Subtype name: zerotouch-configlet

      Required parameters: None

      Optional parameters: None

      Encoding considerations: 8-bit

      Security considerations: See Security Considerations in RFC XXXX

      Interoperability considerations: None

      Published specification: RFC XXXX

      Applications that use this media type:

         Configuration servers and NETCONF servers.

      Fragment identifier considerations: None

      Additional information:

        Deprecated alias names for this type: N/A
        Magic number(s): None
        File extension(s): xml
        Macintosh file type code(s): 'TEXT'

      Person & email address to contact for further information:
         Kent Watsen <kwatsen@juniper.net>

      Intended usage: COMMON

      Restrictions on usage: None

      Author:
        This specification is a work item of the IETF NETCONF working
        group, with mailing list address <netconf@ietf.org>.

      Change controller: The IESG <iesg@ietf.org>

      Provisional registration? (standards tree only): No





Watsen, et al.           Expires April 30, 2015                [Page 24]


Internet-Draft                  ZeroTouch                   October 2014


9.2.2.  application/zerotouch-bootimage


      Type name: application

      Subtype name: zerotouch-bootimage

      Required parameters: None

      Optional parameters: None

      Encoding considerations: binary

      Security considerations: See Security Considerations in RFC XXXX

      Interoperability considerations: None

      Published specification: RFC XXXX

      Applications that use this media type:

         Configuration servers and NETCONF servers.

      Fragment identifier considerations: None

      Additional information:

        Deprecated alias names for this type: N/A
        Magic number(s): None
        File extension(s): None
        Macintosh file type code(s): N/A

      Person & email address to contact for further information:
         Kent Watsen <kwatsen@juniper.net>

      Intended usage: COMMON

      Restrictions on usage: None

      Author:
        This specification is a work item of the IETF NETCONF working
        group, with mailing list address <netconf@ietf.org>.

      Change controller: The IESG <iesg@ietf.org>

      Provisional registration? (standards tree only): No





Watsen, et al.           Expires April 30, 2015                [Page 25]


Internet-Draft                  ZeroTouch                   October 2014


10.  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, Wes Hardaker, Russ Mundy, Reinaldo
   Penno, Randy Presuhn, Juergen Schoenwaelder.

   Special thanks goes to Russ Mundy and Wes Hardaker for brainstorming
   the original I-D's solution during the IETF 87 meeting in Berlin.

11.  References

11.1.  Normative References

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

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
              Shell Authentication", RFC 6187, March 2011.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, August 2014.

   [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>.

   [XMLENC]   "XML Encryption Syntax and Processing", April 2013,
              <http://www.w3.org/TR/xmlenc-core1>.

   [XMLSIG]   "XML Signature Syntax and Processing", April 2013,
              <http://www.w3.org/TR/xmldsig-core1>.







Watsen, et al.           Expires April 30, 2015                [Page 26]


Internet-Draft                  ZeroTouch                   October 2014


11.2.  Informative References

   [TR069]    The Broadband Forum, , "TR-069 Amendment 3, CPE WAN
              Management Protocol", November 2010,
              <http://www.broadband-forum.org/technical/download/
              TR-069_Amendment-3.pdf>.













































Watsen, et al.           Expires April 30, 2015                [Page 27]


Internet-Draft                  ZeroTouch                   October 2014


Appendix A.  Examples

A.1.  Unsigned Configlet

   This example illustrates a Configlet configuring both a local user
   account and call home using SSH.  Note, this is not a valid Configlet
   because it isn't signed.

<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
  <target-requirements>
    <unique-identifier>0123456789</unique-identifier>
    <software-version>14.1R3.5</software-version>
  </target-requirements>
  <configuration>

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



Watsen, et al.           Expires April 30, 2015                [Page 28]


Internet-Draft                  ZeroTouch                   October 2014


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

  </configuration>
</configlet>

A.2.  Signed Configlet

   This example illustrates the above unsigned Configlet signed as if by
   a Configuration Signer.  Note that in addition to the signature
   itself, the signed Configlet embeds two certificates, the chain of
   certificates from the signer's certificate up to but not including
   the trust anchor certificate.

<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
  <target-requirements>
    <unique-identifier>0123456789</unique-identifier>
    <software-version>14.1R3.5</software-version>
  </target-requirements>
  <configuration>

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



Watsen, et al.           Expires April 30, 2015                [Page 29]


Internet-Draft                  ZeroTouch                   October 2014


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

  </configuration>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference>
        <Transforms>
          <Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        </Transforms>
        <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>t9OdNsxPsjyzrKu7kO0ydcFK6xU=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>
AS/dlRNk/DDy2baDfQXspstvQzOxZo/goZ+Z9iiW5dbOZ+wiZwxMlJuMYlxuNrfL
o38JzJ+KnY1XexfRkFmSaaShyMJ0N9kianxaYWJgvF7+/lx5U6isFxpfIwvo9YkQ
27w/i9xb5e/tl+PzVr+FMKyUuyitdy5yjVGpa3y8Gqlk7YSo4df4LWzmR4hAYWTN



Watsen, et al.           Expires April 30, 2015                [Page 30]


Internet-Draft                  ZeroTouch                   October 2014


P7cuV516tHakKpyTi9FweBrqEUNT7W7BNb6Js0Q1twrEIR4lFwpQn/iWUM5KqxAu
QzP7YG/d58oWzdILeCXZ2CX3RHhhtm/Brwa9UFN9TFS3D9WLIx1pO+L0HNt5gIiu
eOMq1vN6sazkMtm6Z1NMqg==
    </SignatureValue>
    <KeyInfo>
      <X509Data>
        <X509Certificate>
MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1
M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF
wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH
/gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW
PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d
x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX
glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h
8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz
rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d
rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ
HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI
AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5
        </X509Certificate>
        <X509Certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4



Watsen, et al.           Expires April 30, 2015                [Page 31]


Internet-Draft                  ZeroTouch                   October 2014


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==
        </X509Certificate>
      </X509Data>
    </KeyInfo>
  </Signature>
</configlet>

A.3.  Encrypted Configlet

   This example illustrates the above unsigned Configlet that has been
   encrypted using the device's public key.  Note, this is not a valid
   Configlet because it isn't signed.

   <?xml version="1.0"?>
   <configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
     <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                    Type="http://www.w3.org/2001/04/xmlenc#Content">
       <EncryptionMethod
           Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
       <CipherData>
         <CipherValue>
   +H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs
   W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO
   yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU
   5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2
   WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u
   fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG
   a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf
   vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp
   xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k
   484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr
   6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6
   tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY
   C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc



Watsen, et al.           Expires April 30, 2015                [Page 32]


Internet-Draft                  ZeroTouch                   October 2014


   cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj
   UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE
   2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc
   OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu
   Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5
   urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf
   GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP
   KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF
   QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387
   HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3
   BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d
   M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B
   lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+
   i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo
   MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE
   02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD
   G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG
   Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R
   Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK
   om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7
   lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk
   UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp
   ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf
   v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL
   5gk2DiSiffIpB/IJuTBQZQ==
         </CipherValue>
       </CipherData>
     </EncryptedData>
   </configlet>

A.4.  Signed Encrypted Configlet

   This example illstrates the above encrypted Configlet that has been
   signed by a Configuration Signer's private key.

   <?xml version="1.0"?>
   <configlet xmlns="urn:ietf:params:xml:ns:ietf-netconf-zerotouch">
     <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                    Type="http://www.w3.org/2001/04/xmlenc#Content">
       <EncryptionMethod
           Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
       <CipherData>
         <CipherValue>
   +H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs
   W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO
   yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU
   5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2
   WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u



Watsen, et al.           Expires April 30, 2015                [Page 33]


Internet-Draft                  ZeroTouch                   October 2014


   fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG
   a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf
   vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp
   xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k
   484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr
   6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6
   tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY
   C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc
   cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj
   UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE
   2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc
   OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu
   Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5
   urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf
   GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP
   KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF
   QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387
   HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3
   BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d
   M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B
   lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+
   i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo
   MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE
   02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD
   G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG
   Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R
   Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK
   om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7
   lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk
   UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp
   ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf
   v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL
   5gk2DiSiffIpB/IJuTBQZQ==
         </CipherValue>
       </CipherData>
     </EncryptedData>
     <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
       <SignedInfo>
         <CanonicalizationMethod
   Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <SignatureMethod
   Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
         <Reference>
           <Transforms>
             <Transform
   Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
           </Transforms>
           <DigestMethod



Watsen, et al.           Expires April 30, 2015                [Page 34]


Internet-Draft                  ZeroTouch                   October 2014


   Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
           <DigestValue>c7b+PFEoC9cVoQKKuLUQMhuHZik=</DigestValue>
         </Reference>
       </SignedInfo>
       <SignatureValue>
   G0vUKL9FZYu7YIk88+wvHRRAFoKjdU7Mqp8CZvTSrKHTErjPGuJCMOUpvE9uCdpq
   5U8Y6LmpZxz7gUIFhWdSk0rpGpEsG7sRrrl64ZuSb4y0Z3lVVg/4CuaYpoLDGrNn
   JpupwKI4DlfexXt/a9TyIWvb3gjBuN+4wPc87nQRqkX6uwOP8Qh7sKpB8lGDrbTT
   AORhuzitJA9I3DI89he8IrLn6AF7YXYrE97RuP51eZ0/lIVn1M2fDQJtNqOs1poW
   mPf9+TDjgELOMKhW2GF/UNXvM+QP5lInFU8mHxV62qx4NVvmoABzj11P7WM/BEqm
   Lwlk1Qow470JH1xOyDeAuQ==
       </SignatureValue>
       <KeyInfo>
         <X509Data>
           <X509Certificate>
   MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
   VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1
   M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
   AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
   x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF
   wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH
   /gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW
   PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d
   x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX
   glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
   HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
   Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
   BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
   MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw
   CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
   YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
   Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
   SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
   cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
   EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
   A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
   emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
   SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h
   8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz
   rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d
   rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ
   HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI
   AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5
           </X509Certificate>
           <X509Certificate>
   MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
   EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
   ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu



Watsen, et al.           Expires April 30, 2015                [Page 35]


Internet-Draft                  ZeroTouch                   October 2014


   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==
           </X509Certificate>
         </X509Data>
       </KeyInfo>
     </Signature>
   </configlet>

Appendix B.  Change Log

B.1.  ID to 00

   o  Major structural update; the essence is the same.  Most every
      section was rewritten to some degree.

   o  Added a Use Cases section

   o  Added diagrams for "Actors and Roles" and "NMS Precondition"
      sections, and greatly improved the "Device Boot Sequence" diagram

   o  Removed support for physical presence or any ability for
      Configlets to not be signed.

   o  Defined the ZeroTouch Information DHCP option

   o  Added an ability for devices to also download images from
      Configuration Servers



Watsen, et al.           Expires April 30, 2015                [Page 36]


Internet-Draft                  ZeroTouch                   October 2014


   o  Added an ability for Configlets to be encrypted

   o  Now Configuration Servers only have to support HTTP/S - no other
      schemes possible

B.2.  00 to 01

   o  Added boot-image and validate-owner annotations to the "Actors and
      Roles" diagram.

   o  Fixed 2nd paragrph in section 7.1 to reflect current use of
      anyxml.

   o  Added encrypted and signed-encrypted examples

   o  Replaced YANG module with XSD schema

   o  Added IANA request for the ZeroTouch Information DHCP Option

   o  Added IANA request for media types for boot-image and
      configuration

Authors' Addresses

   Kent Watsen
   Juniper Networks

   EMail: kwatsen@juniper.net


   Stephen Hanna
   Juniper Networks

   EMail: shanna@juniper.net


   Joe Marcus Clarke
   Cisco Systems

   EMail: jclarke@cisco.com


   Mikael Abrahamsson
   T-Systems

   EMail: "mikael.abrahamsson@t-systems.se





Watsen, et al.           Expires April 30, 2015                [Page 37]


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