Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)
draft-ietf-netconf-zerotouch-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8572.
|
|
|---|---|---|---|
| Authors | Kent Watsen , Joe Clarke , Mikael Abrahamsson | ||
| Last updated | 2015-03-09 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8572 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-netconf-zerotouch-02
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]