[Docs] [txt|pdf|xml] [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: September 10, 2015                                Cisco Systems
                                                          M. Abrahamsson
                                                               T-Systems
                                                           March 9, 2015


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

Abstract

   This draft presents a technique for establishing a secure NETCONF
   connection between a newly deployed IP-based device, configured with
   just its factory default settings, and its rightful owner's network
   management system (NMS).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Watsen, et al.         Expires September 10, 2015               [Page 1]


Internet-Draft                  ZeroTouch                     March 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   4
   2.  High-level Design . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Design Overview . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Interactions  . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Bootstrap Server  . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Northbound Interface  . . . . . . . . . . . . . . . . . .  10
     3.2.  Southbound Interface  . . . . . . . . . . . . . . . . . .  10
   4.  Device  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     4.1.  Factory Default State . . . . . . . . . . . . . . . . . .  16
     4.2.  Boot Sequence . . . . . . . . . . . . . . . . . . . . . .  18
   5.  Network Management System (NMS) . . . . . . . . . . . . . . .  22
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  22
     5.2.  Precondition  . . . . . . . . . . . . . . . . . . . . . .  22
     5.3.  Connection Handling . . . . . . . . . . . . . . . . . . .  23
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     6.1.  Entropy loss over time  . . . . . . . . . . . . . . . . .  23
     6.2.  Serial Numbers  . . . . . . . . . . . . . . . . . . . . .  23
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  ZeroTouch Information DHCP Options  . . . . . . . . . . .  24
       7.1.1.  DHCP v4 Option  . . . . . . . . . . . . . . . . . . .  24
       7.1.2.  DHCP v6 Option  . . . . . . . . . . . . . . . . . . .  24
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  25
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  26
     A.1.  Ownership Voucher . . . . . . . . . . . . . . . . . . . .  26
     A.2.  Bootstrap Server's API  . . . . . . . . . . . . . . . . .  28
     A.3.  Bootstrap Configuration . . . . . . . . . . . . . . . . .  28
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  30
     B.1.  ID to 00  . . . . . . . . . . . . . . . . . . . . . . . .  30
     B.2.  00 to 01  . . . . . . . . . . . . . . . . . . . . . . . .  30
     B.3.  01 to 02  . . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   A fundamental business requirement is to reduce costs where possible.
   For network operators, deploying devices to many locations can be a
   significant cost, as sending trained specialists to each site to do
   installations is both cost prohibitive and does not scale.





Watsen, et al.         Expires September 10, 2015               [Page 2]


Internet-Draft                  ZeroTouch                     March 2015


   The solution presented herein enables a device to securely obtain a
   bootstrapping configuration from the network without any operator
   input.  Significantly, this configuration may configure the device to
   securely call home using NETCONF Call Home
   [draft-ietf-netconf-call-home].

   Central to this solution is the device being able to process a set of
   files locally, without any need to reach out to the network again.
   As consequence, how the files are obtained is not critical to the
   security of the solution.  The files can be read over any networking
   layer or medium.  By example, the files could be loaded using a USB
   flash drive physically plugged into a device.

   The solution presented below focuses on supporting IP networks that
   may have a DHCP server.  Solutions for other deployment scenarios may
   be defined by drafts in the future.

1.1.  Use Cases

   o  Connecting to a remotely administered network

         This use-case involves scenarios, such as a remote branch
         office or convenience store, whereby the device connects an
         access gateway device to an ISP's network.  In this case, the
         device receives only generic networking settings provided by
         the ISP's DHCP server, with no site-specific customizations
         possible.  In such a case, the device has no recourse but to
         reach out to the public Internet its initial configuration.

   o  Connecting to a locally administered network

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

1.2.  Terminology

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






Watsen, et al.         Expires September 10, 2015               [Page 3]


Internet-Draft                  ZeroTouch                     March 2015


1.3.  Tree Diagrams

   A simplified graphical representation of the data models is used in
   this document.  The meaning of the symbols in these diagrams is as
   follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Braces "{" and "}" enclose feature names, and indicate that the
      named feature must be present for the subtree to be present.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write) and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

2.  High-level Design

2.1.  Design Overview

   The following diagram illustrates the overall solution presented in
   this draft.  Note that some of the interactions illustrated below
   occur at different times, only the numbered interactions (1-3) occur
   at the time a device is bootstrapping itself.




















Watsen, et al.         Expires September 10, 2015               [Page 4]


Internet-Draft                  ZeroTouch                     March 2015


            manufactures
         +----------------------------------+
         |                                  |
         |              1.discover          |
         |                bootstrap         |   2.fetch bootstrap
         |                information       v     data and provide
         |                (optional)    +------+  confirmation
         |              +---------------|Device|----------------+
         |              |               +------+                |
         |              |                   |                   |
         |              v                   |                   v
      +------+       +------+               |              +---------+
      |Vendor|       | DHCP |               |3.netconf     |Bootstrap|
      +------+       |Server|               | callhome     | Server  |
        |  ^         +------+               |              +---------+
        |  |            ^                   |                   ^
        |  |            | stage             |                   |
        |  |            | bootstrap         |      stage        |
        |  |            | information       v      bootstrap    |
        |  |            | (optional)    +-------+  data         |
        |  |            +---------------|  NMS  |---------------+
        |  |                            +-------+
        |  |  imports trust anchor,        | ^
        |  |  signups for owner cert,      | |
        |  |  and orders devices           | |
        |  +-------------------------------+ |
        +------------------------------------+
          ships devices, provides
          serial-numbers and/or IDevID
          certs, and ownership vouchers

   The boxes in this diagram are described next.  A sequence diagram
   explaining the various calls follows in Section 2.2.

   o  Vendor

         Vendors manufacture the devices supporting NETCONF ZeroTouch.
         To support this solution, Vendors must support a one-time
         enrollment process per business organization owning the NMS.
         Vendors must also support sending additional information to the
         business organization about the devices that have been shipped
         for device orders it places.

   o  Device

         The devices supporting NETCONF ZeroTouch will only attempt the
         bootstrapping process when booting with its factory default




Watsen, et al.         Expires September 10, 2015               [Page 5]


Internet-Draft                  ZeroTouch                     March 2015


         configuration.  As illustrated above, the bootstrapping process
         consists of three interactions:

         1.  When joining the network, the device will attempt to
             configure IP networking from a DHCP server.  If the device
             is able to reach a DHCP server, it may discover additional
             bootstrapping information.  The additional bootstrapping
             information consists of one or more additional Bootstrap
             Servers the device should try to connect to.

         2.  The device sequentially processes its list of Bootstrap
             Servers, prioritizing any that might have been learned from
             the DHCP server.  Once the device has successfully
             configured itself using the bootstrapping information, it
             notifies the bootstrapping server for monitoring purposes.

         3.  Assuming the bootstrapping information configures the
             device appropriately, the device will initiate a NETCONF
             Call Home connection [draft-ietf-netconf-call-home].

         More information about Devices is in Section 4.

   o  DHCP Server

         This draft assumes the use of a DHCP server but, in reality,
         the solution is not intrinsically tied to using a DHCP server.
         Any mechanism or combination of mechanisms that can provide
         dynamic networking assignment would equally do.

         Assuming the use of DHCP, this draft defines a specific DHCP
         Option for the discovering of addition bootstrapping
         information.  More information about the ZeroTouch DHCP Option
         is in Section 7.1.

   o  Bootstrap Server

         Bootstrap Servers host the bootstrapping information staged by
         NMSs for the devices to find.  The Bootstrap Server presents a
         simple REST interface for devices to obtain both their
         bootstrapping information as well as notify the Bootstrapping
         Server when it has successfully completed the bootstrapping
         process.

         Bootstrap Servers may be deployed on the public Internet or on
         a local network.  Devices may be preconfigured with a list of
         well-known Bootstrap Servers.  Additional Bootstrap Servers
         (i.e. not in the device's preconfigured list) must be
         discovered from a DHCP server.



Watsen, et al.         Expires September 10, 2015               [Page 6]


Internet-Draft                  ZeroTouch                     March 2015


         How Bootstrap Servers are deployed is out of scope of this
         draft, but there are a couple points worth noting.  Firstly, it
         is expected that Internet based Bootstrap Servers will
         initially be hosted by Vendors, whilst waiting for 3rd-party
         servers to become available.  Secondly, it is expected that
         locally administrated networks with in-house solutions might
         bundle the Bootstrap Server into another system (e.g., the
         NMS), where having the features integrated can streamline
         various workflows.

         More information about Bootstrap Servers is in Section 3.

   o  Network Management System

         The NMS is a term used here loosely to represent any system, or
         collection of systems, deployed by a business organization to
         manage its devices.  An NMS being able to establish a secure
         NETCONF connection with devices purchased by its organization
         is the ultimate goal of this solution presented by this draft.
         More information about the Network Management System is in
         Section 5.

2.2.  Interactions

   The following diagram illustrates the interactions between the
   entities described in the previous section.  Note that the
   interactions can be roughly categorized as those that occur before a
   device powers on and those that occur after a device powers on.























Watsen, et al.         Expires September 10, 2015               [Page 7]


Internet-Draft                  ZeroTouch                     March 2015


+------+        +------+         +---+        +---------+       +------+
|Vendor|        |Device|         |NMS|        |Bootstrap|       | DHCP |
+------+        +------+         +---+        | Server  |       |Server|
   |               |               |          +---------+       +------+
   |               |               |               |               |
   |  1. imports trust anchor      |               |               |
   |<------------------------------|               |               |
   |               |               |               |               |
   |  2. signs up for owner cert   |               |               |
   |<------------------------------|               |               |
   |               |               |               |               |
   |  3. orders devices            |               |               |
   |<------------------------------|               |               |
   |               |               |               |               |
   |  4. ships     |               |               |               |
   |-------------->|               |               |               |
   |               |               |               |               |
   |  5. provides serial-numbers   |               |               |
   |     and/or IDevID cert(s),    |               |               |
   |     and ownership vouchers    |               |               |
   |------------------------------>|               |               |
   |               |               |  6.stage      |               |
   x               |               |    bootstrap  |               |
                   |               |    data       |               |
                   |               |-------------->|               |
                   |               |               |               |
                   |               |  7. stage bootstrap           |
                   |               |     info (optional)           |
                   |               |------------------------------>|
     8. power on   |               |               |               |
    -------------->|               |               |               |
                   | 9. get networking settings and|               |
                   |    staged bootstrap info (if any)             |
                   |---------------------------------------------->|
                   |               |               |               |
                   |               |               |               x
                   | 10. update boot-image, if     |
                   |     needed, and install       |
                   |     config, if valid          |
                   |------------------------------>|
                   |               |               |
                   |               |               x
                   | 11. netconf   |
                   |     call-home |
                   |+------------->|
                   |               |
                   v               v




Watsen, et al.         Expires September 10, 2015               [Page 8]


Internet-Draft                  ZeroTouch                     March 2015


   These interactions are described below.

   1.   An organization, upon deciding to deploy a Vendor's devices for
        NETCONF ZeroTouch, would import into its NMS the IDevID trust
        anchor certificate from the Vendor.  This certificate is later
        used by the NMS to authenticate device identities during NETCONF
        call home connections.

   2.   An organization needs to sign up to a Vendor-provided ZeroTouch
        program.  This program entails the Vendor providing a signed
        Owner certificate to the organization (depicted here), as well
        as a commitment to sign Ownership Vouchers for future device
        orders (interaction #5).

   3.   Subsequently, the organization may place orders to the Vendor
        for devices supporting ZeroTouch.  The ordering process may
        entail an explicit request for ZeroTouch support, as the Vendor
        providing the files in step #5 may not be enabled by default.

   4.   The Vendor ships the devices to the various addresses specified
        in the device order.  For example, to an organization's
        inventory warehouse, where the devices are stored in batches to
        supply internal requests.  In another example, the devices may
        be shipped to their final deployment destinations.

   5.   In order to support ZeroTouch, the Vendor sends to the
        organization information about the devices it shipped.  This
        information may be sent to the organization via email or a
        portal site.  The information includes the serial-number and/or
        IDevID certificate, for each device, as well as one more
        Ownership Vouchers, assigning ownership for the devices to the
        organization.

   6.   In anticipation for the devices performing the ZeroTouch
        process, the NMS configures the Bootstrap Server.  This This
        configuration includes everything a device needs to securely
        connect to the NMS.

   7.   For deployments where the DHCP server can be customized, the NMS
        may configure the DHCP server to provide the device a list of
        additional Bootstrap Servers to consider, in addition to those
        the device knows of by default.  This customization can be
        configured at a global level in the DHCP server, as it is not
        dependent on the type of device in any way.

   8.   At some point, the device powers on and, when having its factory
        default configuration, initiates the ZeroTouch process.




Watsen, et al.         Expires September 10, 2015               [Page 9]


Internet-Draft                  ZeroTouch                     March 2015


   9.   The device obtains from the DHCP server a dynamic network
        assignment.  The device may also at this time discover a list of
        additional bootstrap servers, as optionally configured by the
        NMS in step #7.

   10.  The device iterates over its list of Bootstrap Servers, until it
        can successfully bootstrap its initial configuration.  If it is
        unable to bootstrap an initial configuration, the device boots
        as normal.  If the staged information directs the device to load
        a new image, it does so and reboots.  If the device reboots, it
        continues to have a factory default configuration state, which
        then bring it back to this state, when it would then have the
        correct image.  The device then loads the staged configuration
        into its running datastore, after validating that the
        configuration was signed by its rightful owner, as designated by
        the Ownership Voucher.

   11.  Assuming the bootstrapping information configures the device
        appropriately, the device will initiate a NETCONF Call Home
        [draft-ietf-netconf-call-home] connection to the NMS, which then
        takes over the on-going management of the device.

3.  Bootstrap Server

   A Bootstrap Server MUST implement the southbound interface defined
   below.  In order to support the southbound interface, the Bootstrap
   Server will also need to have a northbound interface, which is
   described in general terms below.

3.1.  Northbound Interface

   The Bootstrap Server will need to provide a northbound interface of
   some sort to enable configuration of the bootstrapping information
   for the devices.  Defining this interface is out of scope for this
   document, but it northbound interface is generally expected to:

   o  Enable listing, creation, modification, and deletion of entries

   o  Enable determining a device's current bootstrapping state

   o  Enable alerting external systems when a device sends notifications

3.2.  Southbound Interface

   The Bootstrap Server's southbound interface is a REST API that is
   described by the YANG [RFC6020] module defined in this section and
   presented using RESTCONF [draft-ietf-netconf-restconf].  Example
   usage of this API is provided in Appendix A.2.



Watsen, et al.         Expires September 10, 2015              [Page 10]


Internet-Draft                  ZeroTouch                     March 2015


   A tree digram describing the Bootstrap Server's southbound interface
   follows:

   module: ietf-zerotouch-bootstrap-server
      +--ro devices
         +--ro device* [unique-id]
            +--ro unique-id            string
            +--ro ownership-voucher
            |  +--ro voucher       binary
            |  +--ro issuer-crl?   string
            +--ro owner-certificate
            |  +--ro certificate    string
            |  +--ro issuer-crl?    string
            +--ro boot-image!
            |  +--ro name         string
            |  +--ro path         string
            |  +--ro signature    string
            +--ro configuration
               +--ro config
               +--ro signature    string
   rpcs:
      +---x notification
         +---w input
            +---w unique-id    string
            +---w type         enumeration
            +---w message?     string

   In the above diagram, notice that the entire data model is read-only,
   as devices can only pull data from the Bootstrap Server.  The data
   model also defines a single RPC, which is used by the device to
   provide asynchronous notifications.

   The Bootstrap Server's southbound interface is normatively defined by
   the following YANG module:

<CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2015-03-09.yang"

module ietf-zerotouch-bootstrap-server {

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
  prefix "ztbs";

  organization
   "IETF NETCONF (Network Configuration) Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/netconf/>



Watsen, et al.         Expires September 10, 2015              [Page 11]


Internet-Draft                  ZeroTouch                     March 2015


    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 ZeroTouch
    Bootstrap Servers.

    Copyright (c) 2014 IETF Trust and the persons identified as
    authors of the code. All rights reserved.

    Redistribution and use in source and binary forms, with or
    without modification, is permitted pursuant to, and subject
    to the license terms contained in, the Simplified BSD
    License set forth in Section 4.c of the IETF Trust's
    Legal Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info).

    This version of this YANG module is part of RFC XXXX; see
    the RFC itself for full legal notices.";

  revision "2015-03-09" {
    description
     "Initial version";
    reference
     "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
  }


  // top-level container
  container devices {
    config false;
    description
      "A list of device entries";
    list device {
      key unique-id;
      leaf unique-id {
        type string;
      }

      container ownership-voucher {
        description
          "This container contains the Ownership Voucher that the



Watsen, et al.         Expires September 10, 2015              [Page 12]


Internet-Draft                  ZeroTouch                     March 2015


           device uses to ascertain the identity of its rightful
           owner, as certified by its Vendor.";
        leaf voucher {
          type binary;
          mandatory true;
          description
            "A Vendor-specific encoding binding unique device
             identifiers to an owner identifier value matching the
             value encoded in the owner-certificate below.  An
             example format for a voucher is presented in the
             Appendix of RFC XXXX.";
        }
        leaf issuer-crl {
          type string;
          description
            "An absolute path to a CRL for the issuer used by the
             Vendor to sign Ownership Vouchers.  The CRL should be
             as up to date as possible.  This leaf is optional as
             it is primarily to support deployments where the device
             is unable to download the CRL from the CRL distribution
             point URLs listed in the Vendor's trust anchor
             certificate.";
        }
      }

      container owner-certificate {
        description
          "It is intended that the device will fetch this container
           as a whole, as it contains values that need to be
           processed together.";
        leaf certificate {
          type string;
          mandatory true;
          description
            "This is an X.509 certificate, signed by a Vendor, for
             a business organization.  This certificate must encode a
             Vendor-assigned value identifying the organization. This
             identifier must match the owner identifier encoded in
             the Ownership Voucher.";
        }
        leaf issuer-crl {
          type string;
          description
            "An absolute path to a CRL for the issuer used by the
             Vendor to sign Owner Certificates.  The CRL should be
             as up to date as possible.  This leaf is optional as
             it is primarily to support deployments where the device
             is unable to download the CRL from the CRL distribution



Watsen, et al.         Expires September 10, 2015              [Page 13]


Internet-Draft                  ZeroTouch                     March 2015


             point URLs listed in the Vendor's trust anchor
             certificate.";
        }
      }

      container boot-image {
        presence
          "Only present when boot image information has been configured";
        description
          "It is intended that the device will fetch this container
           as a whole, as it contains values that need to be
           processed together.";
        leaf name {
          type string;
          mandatory true;
          description
            "The name of the image of software the device is expected
             to be running.";
        }
        leaf path {
          type string;
          mandatory true;
          description
            "An absolute path to the boot-image file hosted on this
             Bootstrap server.";
        }
        leaf signature {
          type string;
          mandatory true;
          description
            "The signature over the concatenation of the previous two
             leafs using the organization's private key.";
        }
      }

      container configuration {
        description
          "It is intended that the device will fetch this container
           as a whole, as its contents need to be processed together.";
        anyxml config {
          mandatory true;
          description
            "Any configuration data model known to the device.  It may
             contain Vendor-specific and/or standards-based data models.
             An example configuration using a couple IETF-defined data
             models is presented the Appendix of RFC XXXX.";
        }
        leaf signature {



Watsen, et al.         Expires September 10, 2015              [Page 14]


Internet-Draft                  ZeroTouch                     March 2015


          type string;
          mandatory true;
          description
            "The signature over the config leaf using the
             organization's private key.";
        }
      }

    }
  }

  rpc notification {
    input {
      leaf unique-id {
        type string;
        mandatory true;
      }
      leaf type {
        type enumeration {
          enum boot-image-missing {
            description
             "Indicates that the device got an error when trying to
              access the provided URL";
          }
          enum boot-image-invalid {
            description
             "Indicates that the device had a problem processing the
              boot-image file (corruption)";
          }
          enum image-name-mismatch {
            description
             "Indicates that the processed boot-image contains a name
              other than provided";
          }
          enum voucher-invalid {
            description
             "Indicates that the device had a problem processing the
              voucher (chain verification failed, revoked crl)";
          }
          enum owner-cert-invalid {
            description
             "Indicates that the device had a problem processing the
              voucher (chain verification failed, revoked crl)";
          }
          enum owner-id-mismatch {
            description
              "Indicates that the owner-id in the voucher does not
               match the one inside the owner-cert";



Watsen, et al.         Expires September 10, 2015              [Page 15]


Internet-Draft                  ZeroTouch                     March 2015


          }
          enum signature-invalid {
            description
              "Indicates that the signature could not be verified
               using the owner-cert";
          }
          enum bootstrap-complete {
            description
              "Indicates that the device successfully processed the
               bootstrap data.  At this point, the device is running
               the required boot-image and configuration.  A device
               is expected to only send this notification once,
               assuming it does not receive an error in the HTTP
               response from the Bootstrap Server.";
          }
        }
        mandatory true;
      }
      leaf message {
        type string;
        description
          "A human-readable value that might provide useful information";
      }
    }
  }

}

<CODE ENDS>


4.  Device

   Devices supporting ZeroTouch MUST have the preconfigured factory
   default state and bootstrapping logic described in the following
   sections.

4.1.  Factory Default State













Watsen, et al.         Expires September 10, 2015              [Page 16]


Internet-Draft                  ZeroTouch                     March 2015


    +------------------------------------------------------------------+
    |                             <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 MUST be manufactured with a list of default Bootstrap
       Servers.  Each Bootstrap Server may be identified via a hostname
       or an IP address.  This may be an empty list if for some reason
       the Vendor prefers to force its devices to have to discover
       Bootstrap Servers from a DHCP server.

   2.  Devices MUST be manufactured with a list of trust anchor
       certificates that can be used to authenticate Bootstrap Server
       connections with.  To support Bootstrap Servers discovered from a
       DHCP server, these certificates SHOULD include public certificate
       authorities, such as those that are included in a web browser.

   3.  Devices MUST be manufactured with the trust anchor certificate
       for Owner certificates that the Vendors provide to business
       organizations when they enroll in the Vendor's ZeroTouch program.
       This trust anchor certificate is later used by the device to
       validate the Owner certificate it downloads from the Bootstrap
       Server.

   4.  Devices MUST be manufactured with the trust anchor certificate
       for the device ownership vouchers that the Vendors provide to
       organizations when it ships out an order of ZeroTouch devices.
       This trust anchor certificate is later used by the device to
       validate the Ownership Vouchers it downloads from the Bootstrap
       Server.





Watsen, et al.         Expires September 10, 2015              [Page 17]


Internet-Draft                  ZeroTouch                     March 2015


   5.  Devices MUST be manufactured with an initial device identifier
       (IDevID), as defined in [Std-802.1AR-2009].  The IDevID is an
       X.509 certificate, encoding a globally unique device identifier
       (e.g., serial number).  The device MUST also possess any
       intermediate certificates between the IDevID certificate and the
       Vendor's IDevID trust anchor certificate.  These certificates are
       later used by the device to identify itself when it calls home.
       In particular, these certificates are to be used by the device's
       NETCONF server, either as its SSH host-key or its TLS server
       certificate.  Please see NETCONF Call Home
       [draft-ietf-netconf-call-home] for more information.

   6.  Device MUST be manufactured with a private key that corresponds
       to the public key encoded in its IDevID certificate.  This
       private key SHOULD be securely stored, ideally by a cryptographic
       processor (e.g., a TPM).

4.2.  Boot Sequence

     Power On
         |
         v                        No
  1. Running default config?   -------->  Boot normally
         |
         | Yes
         v                          No
  2. Able to reach DHCP server?  -------->  Boot normally
         |
         | Yes
         v
  3. Prepend any additional Bootstrap Servers discovered
         |
         v                                           No
  4. Able to bootstrap off any Bootstrap Server?  -------> Boot normally
     (see next diagram for drill-down details)
         |
         | Yes
         v
  5. Run with new configuration

   These interactions are described next.

   1.  When the device powers on, it first checks to see if it is
       running the factory default configuration.  If it is running a
       modified configuration, then it boots normally.






Watsen, et al.         Expires September 10, 2015              [Page 18]


Internet-Draft                  ZeroTouch                     March 2015


   2.  The device tries to obtain a dynamic network assignment from a
       DHCP server.  If it is unable to reach a DHCP server, it boots
       normally.

   3.  If the DHCP server's offer includes the ZeroTouch Information
       DHCP option defined in Section 7.1, the device prepends the
       specified Bootstrap Servers to its factory default list.

   4.  The device iterates over its list of Bootstrap Servers, as
       described in the next section.  If it is unable to bootstrap
       itself off any of the servers, it boots normally.

   5.  If the device was able to bootstrap itself off any of the
       Bootstrap Servers, it runs with the new configuration merged into
       its running datastore.

   Following are the actions performed by the device when bootstrap off
   a Bootstrap Server (step #4 the in previous diagram).

































Watsen, et al.         Expires September 10, 2015              [Page 19]


Internet-Draft                  ZeroTouch                     March 2015


    Connect to port 443
        |
        v                                  No
 1. Able to validate server certificate? ------> Exit
        |
        | Yes
        v                                   No
 2. Able to validate ownership voucher?  ------> Post notification and exit
        |
        | Yes
        v                                  No
 3. Able to validate owner certificate?  ------> Post notification and exit
        |
        | Yes
        v                                No
 4. Able to validate boot image info?  ------> Post notification and exit
        |
        | Yes
        v                          No
 5. Need to install boot image?  ------> Install and reboot
        |
        | Yes
        v                              No
 6. Able to validate configuration?  ------> Post notification and exit
        |
        | Yes
        v
 7. Merge configuration into running datastore
        |
        v
 8. Post bootstrap complete notification and exit

   These interactions are described next.

   1.  As part of the HTTPS connection, the device will need to
       authenticate the server certificate presented by the Bootstrap
       Server.  The device authenticates the server certificate using
       path-validation to one of its preconfigured Bootstrap Server
       trust anchors.  If the device is unable to authenticate the
       server's certificate, it abandons this Bootstrap Server and
       exits.

   2.  The device downloads the ownership voucher from the Bootstrap
       Server.  The device validates the voucher is signed by its
       Vendor, using its preconfigured trust anchor for device ownership
       vouchers.  The device also validates that its unique identifier
       is listed by the voucher.  If the device is unable to validate
       the voucher or can not find its unique identifier listed, it



Watsen, et al.         Expires September 10, 2015              [Page 20]


Internet-Draft                  ZeroTouch                     March 2015


       posts a notification message to that effect and abandons this
       Bootstrap Server.

   3.  The device downloads the owner certificate from the Bootstrap
       Server.  The device validates that this certificate is signed by
       its Vendor, using path-validation to its preconfigured trust
       anchor for owner certificates.  The device also validates that
       the organization identifier is the same as listed in the
       ownership voucher, validated in step #2.  If the device is unable
       to validate the certificate or the owner identifier does not
       match, it posts a notification message to that effect and
       abandons this Bootstrap Server.

   4.  The device tries to download the boot image information.  If no
       boot image information is available, it skips the remainder of
       this step.  Otherwise, the device validates the boot image
       information using the public key from the owner certificate
       obtained in step #3.  If it is unable to authenticate the boot
       image information, it posts a notification message to that effect
       and abandons this Bootstrap Server.

   5.  The device checks if the specified boot-image name matches what
       the device is currently running.  If there is a mismatch, device
       downloads the new image from the Bootstrap Server and installs
       it.  It is expected that the device will reboot itself in order
       to activate the new image and, further, that doing so preserves
       its factory default state such that it will return to this same
       check again, but then running the correct image.  If the device
       is unable to install the boot-image, it posts a notification
       message to that effect and abandons this Bootstrap Server.

   6.  The device downloads the configuration from the Bootstrap Server
       and validates the configuration using the public key from the
       owner certificate obtained in step #3.  If it is unable to
       authenticate the configuration, it posts a notification message
       to that effect and abandons this Bootstrap Server.

   7.  The device merges the configuration into its running datastore.
       It is expected that this configuration will provide the
       information necessary for the device to establish a secure
       NETCONF connection to its NMS using NETCONF Call Home
       ([draft-ietf-netconf-call-home]).

   8.  The device posts a bootstrap completion notification message to
       the Bootstrap Server and exits.






Watsen, et al.         Expires September 10, 2015              [Page 21]


Internet-Draft                  ZeroTouch                     March 2015


5.  Network Management System (NMS)

5.1.  Overview

   It is expected that the bootstrapping configuration will guide the
   device to initiate a secure NETCONF connection to the NMS using
   NETCONF Call Home [draft-ietf-netconf-call-home].  This section
   describes what the NMS needs to do to ensure security for the
   device's connection.

5.2.  Precondition

     +-----------------------------------------------------------------+
     |                              <nms>                              |
     |                                                                 |
     |     +-----------------------------------------------------+     |
     |     |                 <read-only storage>                 |     |
     |     |                                                     |     |
     |     |  1. list of IDevID trust anchor certificates        |     |
     |     +-----------------------------------------------------+     |
     |                                                                 |
     |     +-----------------------------------------------------+     |
     |     |                   <configuration>                   |     |
     |     |                                                     |     |
     |     |  2. list of expected device unique identifiers      |     |
     |     +-----------------------------------------------------+     |
     |                                                                 |
     |     +-----------------------------------------------------+     |
     |     |                  <secure storage>                   |     |
     |     |                                                     |     |
     |     |  3. map of device identifiers to login credentials  |     |
     |     +-----------------------------------------------------+     |
     |                                                                 |
     +-----------------------------------------------------------------+

   1.  In order to authenticate a device, the NMS MUST possess the
       IDevID trust anchor provided by its Vendor to enable verification
       of the device's IDevID certificate.  Specifically, the NMS uses
       this certificate to validate the identity certificate a device
       presents when negotiating the SSH or TLS transport for the
       NETCONF Call Home connection [draft-ietf-netconf-call-home].
       Because an NMS may interoperate with multiple vendors, and a
       vendor may have more than one trust anchor for signing its
       devices IDevID certificates, this generalizes into the NMS
       needing a list of trust anchor certificates.  These certificates
       SHOULD be stored in a way that prevents tampering, which is why
       they are shown in read-only storage in the diagram.




Watsen, et al.         Expires September 10, 2015              [Page 22]


Internet-Draft                  ZeroTouch                     March 2015


   2.  In order for the NMS to validate that a specific device
       connecting to it is legitimate, it MUST have a list of expected
       unique device identifiers (e.g., serial-numbers).  The unique
       identifier encoded into the device's IDevID certificate MUST
       match one of the expected identifiers in order for a device to be
       considered legitimate.

   3.  The NMS must have login credentials for each device.  These
       credentials may be, for instance, a private key used for SSH or
       TLS client authentication.  It is expected that a device is able
       to authenticate the NMS's credentials by virtue of the
       configuration it downloads from the Bootstrap Server.  These
       private-keys SHOULD be stored securely, such that they can not be
       easily compromised.

5.3.  Connection Handling

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

6.  Security Considerations

6.1.  Entropy loss over time

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

6.2.  Serial Numbers

   This draft suggests using the device's serial number as the unique
   identifier in its IDevID certificate.  This is because serial numbers
   are ubiquitous and prominently contained in invoices and on labels
   affixed to devices and their packaging.  That said, serial numbers
   many times encode revealing information, such as the device's model
   number, manufacture date, and/or sequence number.  Knowledge of this
   information may provide an adversary with details needed to launch an
   attack.








Watsen, et al.         Expires September 10, 2015              [Page 23]


Internet-Draft                  ZeroTouch                     March 2015


7.  IANA Considerations

7.1.  ZeroTouch Information DHCP Options

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

7.1.1.  DHCP v4 Option

      Tag: XXX

      Name: Zero Touch Information

      Description: Returns a list of null-terminated Configuration
                   Server hostnames and/or IP addresses.

       Code   Len
      +-----+-----+------+------+----
      | XXX |  n  | svr1 | svr2 | ...
      +-----+-----+------+------+----

      Reference: RFC XXXX

7.1.2.  DHCP v6 Option

      Tag: YYY

      Name: Zero Touch Information

      Description: Returns a list of null-terminated Configuration
                   Server hostnames and/or IP addresses.

       Code   Len
      +-----+-----+------+------+----
      | YYY |  n  | svr1 | svr2 | ...
      +-----+-----+------+------+----

      Reference: RFC XXXX

8.  Acknowledgements

   The authors would like to thank for following for lively discussions
   on list and in the halls (ordered by last name): David Harrington,
   Dean Bogdanovic, Martin Bjorklund, Stephen Hanna, Wes Hardaker, Russ
   Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder.





Watsen, et al.         Expires September 10, 2015              [Page 24]


Internet-Draft                  ZeroTouch                     March 2015


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

9.  Normative References

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

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

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

   [Std-802.1AR-2009]
              IEEE SA-Standards Board, "IEEE Standard for Local and
              metropolitan area networks - Secure Device Identity",
              December 2009, <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 September 10, 2015              [Page 25]


Internet-Draft                  ZeroTouch                     March 2015


Appendix A.  Examples

A.1.  Ownership Voucher

   Following describes an example data-model for an Ownership Voucher.
   Real vouchers are expected to be encoded in a Vendor-specific format
   outside the of scope for this draft.

   A tree digram describing an Ownership Voucher:

   module: ietf-zerotouch-ownership-voucher
      +--rw voucher
         +--rw unique-id*    string
         +--rw owner-id      string
         +--rw created-on    yang:date-and-time
         +--rw expires-on?   yang:date-and-time
         +--rw signature     string

   The YANG module for this example voucher:

<CODE BEGINS> file "ietf-zerotouch-ownership-voucher@2015-03-09.yang"

module ietf-zerotouch-ownership-voucher {

  namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher";
  prefix "ztov";

  import ietf-yang-types { prefix yang; }

  organization
   "IETF NETCONF (Network Configuration) Working Group";

  contact
   "WG Web:   <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
    device to ascertain the identity of its rightful owner, as



Watsen, et al.         Expires September 10, 2015              [Page 26]


Internet-Draft                  ZeroTouch                     March 2015


    certified by its Vendor.

    Copyright (c) 2014 IETF Trust and the persons identified as
    authors of the code. All rights reserved.

    Redistribution and use in source and binary forms, with or
    without modification, is permitted pursuant to, and subject
    to the license terms contained in, the Simplified BSD
    License set forth in Section 4.c of the IETF Trust's
    Legal Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info).

    This version of this YANG module is part of RFC XXXX; see
    the RFC itself for full legal notices.";

  revision "2015-03-09" {
    description
     "Initial version";
    reference
     "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
  }

  // top-level container
  container voucher {
    leaf-list unique-id {
      type string;
      min-elements 1;
      description
        "The unique identifier (e.g., serial-number) for a device.
         The value must match the value in the device's IDevID
         certificate.  A device uses this value to determine if
         the voucher applies to it.";
    }
    leaf owner-id {
      type string;
      mandatory true;
      description
        "A Vendor-assigned value for the rightful owner of the
         devices enumerated by this voucher.  The owner-id value
         must match the value in the owner-certificate below";
    }
    leaf created-on {
      type yang:date-and-time;
      mandatory true;
      description
        "The date this voucher was created";
    }
    leaf expires-on {



Watsen, et al.         Expires September 10, 2015              [Page 27]


Internet-Draft                  ZeroTouch                     March 2015


      type yang:date-and-time;
      description
        "The date this voucher expires, if any";
    }
    leaf signature {
      type string;
      mandatory true;
      description
        "The signature over the concatenation of all the previous
         values";
    }
  }
}

<CODE ENDS>


A.2.  Bootstrap Server's API

 ['\' line wrapping added for formatting only]

 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
 devices/device=123456/ownership-voucher

 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
 devices/device=123456/owner-certificate

 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
 devices/device=123456/boot-image

 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
 devices/device=123456/configuration

 POST https://example.com/restconf/operations/ietf-zerotouch-bootstrap-\
 server:notification


A.3.  Bootstrap Configuration

   This example illustrates a configuration enabling secure NETCONF
   call-home using standards-based YANG modules.










Watsen, et al.         Expires September 10, 2015              [Page 28]


Internet-Draft                  ZeroTouch                     March 2015


<?xml version="1.0"?>
<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>
              <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>



Watsen, et al.         Expires September 10, 2015              [Page 29]


Internet-Draft                  ZeroTouch                     March 2015


Appendix B.  Change Log

B.1.  ID to 00

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

   o  Added a Use Cases section

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

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

   o  Defined the ZeroTouch Information DHCP option

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

   o  Added an ability for Configlets to be encrypted

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

B.2.  00 to 01

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

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

   o  Added encrypted and signed-encrypted examples

   o  Replaced YANG module with XSD schema

   o  Added IANA request for the ZeroTouch Information DHCP Option

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

B.3.  01 to 02

   o  Replaced the need for a Configuration Signer with the ability for
      each NMS to be able to sign its own configurations, using Vendor
      signed Ownership Vouchers and Owner certificates.




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


Internet-Draft                  ZeroTouch                     March 2015


   o  Renamed Configuration Server to Bootstrap Server, a more
      representative name given the information devices download from
      it.

   o  Replaced the concept of a Configlet by defining a southbound
      interface for the Bootstrap Server using YANG.

   o  Removed the IANA request for the boot-image and configuration
      media types

Authors' Addresses

   Kent Watsen
   Juniper Networks

   EMail: kwatsen@juniper.net


   Joe Clarke
   Cisco Systems

   EMail: jclarke@cisco.com


   Mikael Abrahamsson
   T-Systems

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























Watsen, et al.         Expires September 10, 2015              [Page 31]


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