One document matched: draft-ietf-netconf-zerotouch-02.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6187 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6187.xml">
<!ENTITY rfc7317 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-netconf-zerotouch-02">
<front>
<title abbrev="ZeroTouch">Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<author initials="J.C." surname="Clarke" fullname="Joe Clarke">
<organization>Cisco Systems</organization>
<address>
<email>jclarke@cisco.com</email>
</address>
</author>
<author initials="M.A." surname="Abrahamsson" fullname="Mikael Abrahamsson">
<organization>T-Systems</organization>
<address>
<email>"mikael.abrahamsson@t-systems.se</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>zerotouch</keyword>
<abstract>
<t>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).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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 <xref target="draft-ietf-netconf-call-home"/>.</t>
<t>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.</t>
<t>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.</t>
<!--
<t><vspace blankLines="3"/></t>
-->
<section title="Use Cases" anchor="use-cases">
<t>
<list style="symbols">
<t>Connecting to a remotely administered network
<list style="empty">
<t>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.</t>
</list>
</t>
<t>Connecting to a locally administered network
<list style="empty">
<t>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.</t>
</list>
</t>
</list>
</t>
<!--
<t><vspace blankLines="30"/></t>
-->
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Tree Diagrams">
<t>A simplified graphical representation of the data models
is used in this document. The meaning of the symbols in
these diagrams is as follows:
<list style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Braces "{" and "}" enclose feature names, and indicate
that the named feature must be present for the subtree
to be present.</t>
<t>Abbreviations before data node names: "rw" means
configuration (read-write) and "ro" state data
(read-only).</t>
<t>Symbols after data node names: "?" means an optional
node, "!" means a presence container, and "*" denotes a
list and leaf-list.</t>
<t>Parentheses enclose choice and case nodes, and case
nodes are also marked with a colon (":").</t>
<t>Ellipsis ("...") stands for contents of subtrees that
are not shown.</t>
</list>
</t>
</section>
</section> <!-- end Introduction -->
<section title="High-level Design">
<section title="Design Overview" anchor="com-diag">
<t>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.</t>
<t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
<t>The boxes in this diagram are described next. A sequence diagram
explaining the various calls follows in <xref target="seq-diag"/>.</t>
<t>
<list style="symbols">
<t>Vendor
<list style="empty">
<t>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.</t>
<!--
More information about Vendors is in <xref target="vendor"/>.</t>
-->
</list>
</t>
<t>Device
<list style="empty">
<t>The devices supporting NETCONF ZeroTouch will only attempt the
bootstrapping process when booting with its factory default
configuration. As illustrated above, the bootstrapping process
consists of three interactions:
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>Assuming the bootstrapping information configures the device
appropriately, the device will initiate a NETCONF Call Home
connection <xref target="draft-ietf-netconf-call-home"/>.</t>
</list>
</t>
<t>More information about Devices is in <xref target="device"/>.</t>
</list>
</t>
<t>DHCP Server
<list style="empty">
<t>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.</t>
<t>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
<xref target="zerotouch-info-option"/>.</t>
</list>
</t>
<t>Bootstrap Server
<list style="empty">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>More information about Bootstrap Servers is
in <xref target="bootstrap-server"/>.</t>
</list>
</t>
<t>Network Management System
<list style="empty">
<t>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 <xref target="nms"/>.</t>
</list>
</t>
</list>
</t>
<!--
<t>Not captured in the diagram, but is described in sections
below, the solution presented herein is totally secure. Every
networking connection is encrypted and authenticated, and all
of the bootstrapping information is cryptographically signed
and verified.</t>
-->
</section>
<section title="Interactions" anchor="seq-diag">
<t>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.</t>
<t>
<figure>
<artwork><![CDATA[
+------+ +------+ +---+ +---------+ +------+
|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
]]></artwork>
</figure>
</t>
<t>These interactions are described below.
<list style="numbers">
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>At some point, the device powers on and, when having its
factory default configuration, initiates the ZeroTouch
process.</t>
<t>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.</t>
<t>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.</t>
<t>Assuming the bootstrapping information configures the device
appropriately, the device will initiate a NETCONF Call Home
<xref target="draft-ietf-netconf-call-home"/> connection to the NMS, which
then takes over the on-going management of the device.</t>
</list>
</t>
</section>
</section>
<section title="Bootstrap Server" anchor="bootstrap-server">
<t>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.</t>
<section title="Northbound Interface">
<t>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:
<list style="symbols">
<t>Enable listing, creation, modification, and deletion of entries</t>
<t>Enable determining a device's current bootstrapping state</t>
<t>Enable alerting external systems when a device sends notifications</t>
</list>
</t>
</section>
<section title="Southbound Interface">
<t>The Bootstrap Server's southbound interface is a REST API that is
described by the YANG <xref target="RFC6020"/> module defined in this
section and presented using RESTCONF <xref target="draft-ietf-netconf-restconf"/>.
Example usage of this API is provided in <xref target="ex-bootstrap-api"/>.</t>
<t>A tree digram describing the Bootstrap Server's southbound interface follows:</t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>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.</t>
<t>The Bootstrap Server's southbound interface is normatively defined
by the following YANG module:</t>
<figure>
<artwork><![CDATA[
<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/>
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
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
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 {
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";
}
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>
]]></artwork>
</figure>
</section>
</section>
<section title="Device" anchor="device">
<t>Devices supporting ZeroTouch MUST have the preconfigured
factory default state and bootstrapping logic described
in the following sections.</t>
<section title="Factory Default State" anchor="device-precondition">
<figure>
<artwork><![CDATA[
+------------------------------------------------------------------+
| <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 | |
| +----------------------+ |
| |
+------------------------------------------------------------------+
]]></artwork>
</figure>
<t>
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Devices MUST be manufactured with an initial
device identifier (IDevID), as defined in <xref target="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
<xref target="draft-ietf-netconf-call-home"/> for more information.</t>
<t>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).</t>
</list>
</t>
</section>
<section title="Boot Sequence" anchor="dev-boot-seq">
<t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
<t>These interactions are described next.
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>If the DHCP server's offer includes the ZeroTouch
Information DHCP option defined in <xref target="zerotouch-info-option"/>,
the device prepends the specified Bootstrap Servers to its factory
default list.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>Following are the actions performed by the device when bootstrap off a
Bootstrap Server (step #4 the in previous diagram).</t>
<t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
<t>These interactions are described next.
<list style="numbers">
<t>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.</t>
<t>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 posts a notification message to
that effect and abandons this Bootstrap Server.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 (<xref target="draft-ietf-netconf-call-home"/>).</t>
<t>The device posts a bootstrap completion notification message to
the Bootstrap Server and exits.</t>
</list>
</t>
<!--
<t>In order to facilitate troubleshooting, the device SHOULD
record into a log information relating to its stepping through
the ZeroTouch sequence. This draft does not define any specific
log messages, for instance, for Syslog or SNMP.
</t>
-->
</section>
</section>
<section title="Network Management System (NMS)" anchor="nms">
<section title="Overview">
<t>It is expected that the bootstrapping configuration will guide
the device to initiate a secure NETCONF connection to the NMS
using NETCONF Call Home <xref target="draft-ietf-netconf-call-home"/>.
This section describes what the NMS needs to do to ensure
security for the device's connection.</t>
</section>
<section title="Precondition">
<t>
<figure>
<artwork><![CDATA[
+-----------------------------------------------------------------+
| <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 | |
| +-----------------------------------------------------+ |
| |
+-----------------------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
<list style="numbers">
<t>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
<xref target="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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Connection Handling">
<t>When receiving a NETCONF call home connection from a
device, the NSM completes the connection as specified
NETCONF Call Home <xref target="draft-ietf-netconf-call-home"/>.</t>
<!-- KENT, fill this in with a nice diagram... -->
</section>
</section>
<!--
<section title="Vendor" anchor="vendor">
<section title="Order Information" anchor="order-information">
<t>In order for a Vendor's customers to configure their
NMSs with what devices are expected, as well as to know how to
set the "unique-identifier" field within a Configlet
when requesting a signing, Vendors need to provide a
mechanism for customers to obtain the unique
identifier value for the devices they have
ordered. For instance, customers could receive emails
containing shipping information for their devices.</t>
<t>Additionally, to facilitate workflows where the
devices are initially received by a customer-specific
warehouse, or moved after having been unboxed, it is
ideal for the unique identifier to be easily tracked
through labels affixed to the device as well as the box
it is packaged in. A device's serial number is commonly
treated this way and would be suitable for this purpose,
so long as it is directly related to its IDevID identity.</t>
</section>
<section title="Ownership Validation">
<t>In order for Configuration Signers to validate that a
requestor is the true owner of a device (i.e. its IDevID
identity), Vendors need to provide a mechanism enabling
a near real-time lookup. The interface used to implement
this lookup is outside the scope of this document.</t>
</section>
</section>
-->
<section title="Security Considerations" anchor="sec-con">
<!--
<section title="Immutable storage for trust anchors">
<t>Devices SHOULD ensure that all its trust anchor
certificates, including those for the Configuration
Signer and Configuration Server, are protected from
external modification. It is for this reason that
the diagram in <xref target="device-precondition"/>
shows them in immutable storage.</t>
<t>However, it may be necessary to update these
certificates over time (e.g., the vendor wants to
delegate trust to a new CA). It is therefore expected
that devices MAY update these trust anchors when
needed through a verifiable process, such as a
software upgrade using signed software images.</t>
</section>
<section title="Substitutions">
<t>It is generally not possible to substitute a
Configlet created for a different device, since
devices assert that the Configlet contains their
unique identifier (e.g., serial number).</t>
<t>However, it is possible to substitute a Configlet
created for a device with a different Configlet
created for the same device. Generally, unless
imposed by the Configuration Signers, there is no
limit to the number of Configlets that may be
generated for a given device. This could be resolved, in
part, by placing a timestamp into the Configlet and
ensuring devices do not load Configlets older than some
amount, but this requires the devices have an accurate
clock when validating a Configlet and for Configuration
Signers to not sign a Configlet when another Configlet
is still active.</t>
</section>
<section title="Confidentiality">
<t>This draft allows devices to use insecure schemes when
doing a Configuration Server lookup. This is deemed
acceptable because the Configlet is tamper-proof, since
it MUST be signed, only confidentiality is lost.</t>
<t>Confidentiality of a Configlet's contents is assured
when either the Configlet is encrypted or when the a
secure scheme is used when accessing the Configuration Server.</t>
<t>Some confidentiality is lost when an insecure scheme is
used to access a Configuration Server, as then the device's
unique identifier is in the clear.</t>
<t>Given the fairly regular format for unique identifiers,
it is possible that an adversary to guess unique identifiers
and access a device's Configlet. Configlets that have been
encrypted do not disclose any confidential information.</t>
</section>
-->
<section title="Entropy loss over time">
<t>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.</t>
</section>
<section title="Serial Numbers">
<t>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.</t>
<!-- To address this concern, the
certificate could contain the hash of the serial number
instead, which the NMS could also compute, but doing so
is much less intuitive and raises questions if it is just
security through obscurity.
-->
</section>
</section>
<section title="IANA Considerations">
<section title="ZeroTouch Information DHCP Options" anchor="zerotouch-info-option">
<t>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.</t>
<section title="DHCP v4 Option">
<figure>
<artwork>
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
</artwork>
</figure>
</section>
<section title="DHCP v6 Option">
<figure>
<artwork>
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
</artwork>
</figure>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6020;
&rfc6187;
<!-- &rfc7317; - why isn't this working! below is the same as fetched by the URL! -->
<!--
<reference anchor="RFC7317">
<front>
<title>A YANG Data Model for System Management</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<date year="2014" month="August"/>
<abstract>
<t>
This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7317"/>
<format type="TXT" octets="60119" target="http://www.rfc-editor.org/rfc/rfc7317.txt"/>
</reference>
-->
<reference anchor="Std-802.1AR-2009" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<reference anchor="draft-ietf-netconf-call-home" target="https://tools.ietf.org/html/draft-ietf-netconf-call-home-04">
<front>
<title>NETCONF Call Home (work in progress)</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="October" year="2014"/>
</front>
</reference>
<reference anchor="draft-ietf-netconf-server-model" target="http://tools.ietf.org/html/draft-ietf-netconf-server-model-06">
<front>
<title>NETCONF Server Model (work in progress)</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<date month="September" year="2014"/>
</front>
</reference>
<reference anchor='draft-ietf-netconf-restconf' target="https://tools.ietf.org/html/draft-ietf-netconf-restconf-04">
<front>
<title>RESTCONF Protocol</title>
<author initials='A.B.' surname='Bierman'
fullname='Andy Bierman'>
<organization>YumaWorks</organization>
</author>
<author initials='M' surname='Bjorklund'
fullname='Martin Bjorklund'>
<organization>Tail-f Systems</organization>
</author>
<author initials='K.W.' surname='Watsen'
fullname='Kent Watsen'>
<organization>Juniper Networks</organization>
</author>
<date year='2014' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-ieft-netconf-restconf-04' />
</reference>
</references>
<!--
<references title="Informative References">
</references>
-->
<section title="Examples" anchor="examples">
<section title="Ownership Voucher" anchor="ex-owner-voucher">
<t>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.</t>
<t>A tree digram describing an Ownership Voucher:</t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>The YANG module for this example voucher:</t>
<figure>
<artwork><![CDATA[
<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
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 {
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>
]]></artwork>
</figure>
</section>
<section title="Bootstrap Server's API" anchor="ex-bootstrap-api">
<figure>
<artwork><![CDATA[
['\' 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
]]></artwork>
</figure>
</section>
<section title="Bootstrap Configuration" anchor="ex-bootstrap-config">
<t>
<figure>
<preamble>
This example illustrates a configuration enabling secure
NETCONF call-home using standards-based YANG modules.
</preamble>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Change Log">
<section title="ID to 00">
<t>
<list style="symbols">
<t>Major structural update; the essence is the same.
Most every section was rewritten to some degree.</t>
<t>Added a Use Cases section</t>
<t>Added diagrams for "Actors and Roles" and
"NMS Precondition" sections, and greatly improved
the "Device Boot Sequence" diagram</t>
<t>Removed support for physical presence or any
ability for Configlets to not be signed.</t>
<t>Defined the ZeroTouch Information DHCP option</t>
<t>Added an ability for devices to also download
images from Configuration Servers</t>
<t>Added an ability for Configlets to be encrypted</t>
<t>Now Configuration Servers only have to support
HTTP/S - no other schemes possible</t>
</list>
</t>
</section>
<section title="00 to 01">
<t>
<list style="symbols">
<t>Added boot-image and validate-owner annotations
to the "Actors and Roles" diagram.</t>
<t>Fixed 2nd paragraph in section 7.1 to reflect
current use of anyxml.</t>
<t>Added encrypted and signed-encrypted examples</t>
<t>Replaced YANG module with XSD schema</t>
<t>Added IANA request for the ZeroTouch Information DHCP Option</t>
<t>Added IANA request for media types for boot-image and configuration</t>
</list>
</t>
</section>
<section title="01 to 02">
<t>
<list style="symbols">
<t>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.</t>
<t>Renamed Configuration Server to Bootstrap Server, a more
representative name given the information devices download from it.</t>
<t>Replaced the concept of a Configlet by defining a southbound
interface for the Bootstrap Server using YANG.</t>
<t>Removed the IANA request for the boot-image and configuration
media types</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:36:45 |