| NETCONF Working Group | K. Watsen |
| Internet-Draft | Juniper Networks |
| Intended status: Standards Track | M. Abrahamsson |
| Expires: January 9, 2017 | T-Systems |
| July 8, 2016 |
Zero Touch Provisioning for NETCONF or RESTCONF based Management
draft-ietf-netconf-zerotouch-09
This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS).
This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document.
This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments:
Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements:
Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement:
The following one Appendix section is to be removed prior to publication:
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 January 9, 2017.
Copyright (c) 2016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A fundamental business requirement for any network operator is to reduce costs where possible. For network operators, deploying devices to many locations can be a significant cost, as sending trained specialists to each site to do installations is both cost prohibitive and does not scale.
This document defines bootstrapping strategies enabling devices to securely obtain bootstrapping data with no installer input, beyond physical placement and connecting network and power cables. The ultimate goal of this document is to enable a secure NETCONF [RFC6241] or RESTCONF [draft-ietf-netconf-restconf] connection to the deployment specific network management system (NMS).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the sections below are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms:
A simplified graphical representation of the data models is used in this document. The meaning of the symbols in these diagrams is as follows:
This section provides overarching principles guiding the solution presented in this document.
A trust anchor is used in cryptography to represent an entity in which trust is implicit and not derived. In public key infrastructure using X.509 certificates, a root certificate is the trust anchor, from which a chain of trust is derived. The solution presented in this document requires that all the entities involved (e.g., devices, bootstrap servers, NMSs) possess specific trust anchors in order to ensure mutual authentication throughout the zero touch bootstrapping process.
A device in its factory default state possesses a limited set of manufacturer specified trust anchors. In this document, there are two types of trust anchors of interest. The first type of trust anchor is used to authenticate a secure (HTTPS) connection to, for instance, a manufacturer-hosted Internet-based bootstrap server. The second type of trust anchor is used to authenticate manufacturer-signed data, such as the owner certificate and ownership voucher artifacts described in this document.
Using the first type of trust anchor, trust is conveyed by the device first authenticating the secure connection to the bootstrap server and then by the device trusting that the server would only provide data that its rightful owner staged for it to find. Thereby the device can trust any information returned from the server.
Using the second type of trust anchor, trust is conveyed by the device first authenticating the owner certificate and ownership voucher and then, using the public key in the owner certificate, the device can authenticate an owner-signed artifact, such as redirect information. Thereby the device can trust any information held within the artifact.
Notably, the server or artifact may contain redirect information that may include include another trust anchor certificate, for a deployment-specific bootstrap server. Since the device is able to trust the data, using one of its preconfigured trust anchors, it can then use the discovered trust anchor to authenticate a secure connection to the deployment-specific bootstrap server.
The goal of this document is to enable a device to connect with its rightful owner's NMS. This entails the manufacturer being able to track who owns which devices (out of the scope of this document), as well as an ability to convey that information to devices (in scope).
Matching the two ways to convey trust, this document provides two ways to convey ownership, by using a bootstrap server or by using an ownership voucher.
When a device connects to a bootstrap server configured into its factory default configuration, it implicitly trusts that the bootstrap server would only provide data that its rightful owner staged for it to find. That is, ownership is conveyed by the administrator of the bootstrap server (e.g., a manufacturer) taking the onus of ensuring that only data configured by a device's rightful owner is made available to the device. With this approach, the assignment of a device to an owner is ephemeral, as the administrator can reassign a device to another owner at any time.
When a device is presented signed artifacts, it authenticates that its rightful owner provided the artifact by verifying the signature over the artifact using additional artifacts, the owner certificate and ownership voucher. With this approach, ownership is conveyed by the the manufacturer (or delegate) taking the onus of ensuring that the ownership vouchers it issues are accurate. With this approach, the assignment of a device to an owner may be permanent, as the ability to reassign a device to another owner entails revoking the prior assignment, which requires the device having an accurate and securely set clock, which may not be possible for all devices (see Section 8 for information about this).
This document presumes there exists two types of zero touch information: redirect information and bootstrap information.
Both information types MAY be signed or unsigned, though in some contexts, as described below, the bootstrap information type MUST be signed, as there is not otherwise possible for a device to process it, even in a degraded manner.
Both information types MAY be encoded using various technologies. This document only tries to support the encodings supported by RESTCONF, namely XML and JSON, while leaving extensibility mechanisms in place to support future extensions.
Redirect information provides a list of bootstrap servers, where each list entry includes the bootstrap server's hostname or IP address, an optional port, and an optional trust anchor certificate. The redirect information type is formally defined by the "redirect-information" grouping defined in Section 7.4.
As its name suggests, redirect information guides the device to attempt to connect to the specified bootstrap servers, until finding one that it can bootstrap itself off of. Redirect information is primarily distinguished from standard HTTP redirect by its optional inclusion of trust anchors, in which case it may be referred to as a "secure redirect".
Redirect information may be trusted or untrusted. That is, when the redirect information is obtained via a secure connection to a trusted bootstrap server or a signed artifact, it is trusted. In all other cases (e.g., an unsigned artifact obtain via DHCP, DNS, or removable storage), the redirect information is untrusted.
Trusted redirect information is useful for enabling a device to establish a secure connection to a bootstrap server. Untrusted redirect information is useful for directing a device to a bootstrap server where signed data has been staged for it to obtain.
When the redirect information is trusted and conveys trust anchors, and the device is able establish a secured connection to the specified bootstrap server, using X.509 certificate path validation ([RFC6125], Section 6) to the trust anchor provided in the redirect information, then the device MUST trust the bootstrap server.
When the redirect information is untrusted, the device MUST discard any presented trust anchors and the device MUST connect to the bootstrap server by blindly accepting the bootstrap server's TLS certificate. In this case, the device MUST NOT trust the bootstrap server.
Implications of a device trusting or not trusting a bootstrap server are discussed in Section 4.4.
Bootstrap information provides all the data necessary for the device to bootstrap itself, in order to be considered ready to be managed. This data includes criteria about the boot image the device MUST be running, an initial configuration the device MUST commit, and an optional script that, if specified, the device MUST successfully execute. Descriptions for these follow:
It is always permitted for bootstrap information to be signed, even if it was obtained in a secure fashion. If the device is accessing the bootstrap server in an unsecured manner (e.g., from a removable storage device or from an untrusted server), then the bootstrap information MUST be signed.
Devices MUST process bootstrap information as is specified in Section 6.6.
The bootstrap information type is formally defined by the "bootstrap-information" grouping defined in Section 7.4.
Following are the sources of bootstrapping data that are referenced by the workflows presented in Section 5.3. Other sources of bootstrapping data may be defined in future documents, so long as the principles for when the bootstrapping data needs to be signed are enforced.
Each of the descriptions below show how the bootstrapping data needs to be handled in a manner consistent with the guiding principles in Section 2.
For devices supporting more than one source for bootstrapping data, no particular sequencing order has to be observed, as each source is equally secure, in that the chain of trust always goes back to the same root of trust, the manufacturer. That said, from a privacy perspective, it is RECOMMENDED that a device try to leverage local sources before remote source. For this reason, all the examples used in this document assume a removable storage device is accessed before a DHCP server, which itself is accessed before an Internet-based bootstrap server.
A device MAY attempt to acquire bootstrapping data from a directly attached removable storage device. The bootstrapping data MAY be either redirect information or bootstrap information.
If redirect information is provided, it SHOULD be signed, as removable storage devices are not trustworthy. Section 3.1 defines how a device processes signed and unsigned redirect information.
If bootstrap information is provided, it MUST be signed, as removable storage devices are not trustworthy and there is no option to process the data in a degraded manner, unlike as with redirect information.
For the case when the signed bootstrap information is provided, it is notable that even the raw boot image file itself can be on the removable storage device, by letting the URL reference a local file (e.g., file:///path/to/file), making use of the removable storage device a fully self-standing bootstrapping solution.
Note: details such as the format of the filesystem and the naming of the files are left to the device's manufacturer to define. However, in order to facilitate interoperability, it is RECOMMENDED to support open/standards based filesystems and to have a filenaming convention that is not likely to have collisions with files from other vendors.
A device MAY attempt to acquire bootstrapping data from a DNS server using DNS-based service discovery (DNS-SD) [RFC6763]. Due to DNS packet size limitations the bootstrapping data provided using DNS-SD can only be redirect information (not bootstrap information).
The redirect information provided via DNS-SD SHOULD be signed (i.e., using the owner's private key), as this document does not define a solution to secure the DNS records using DNSSEC [RFC6698], and therefore the DNS records are not trustworthy. Section 3.1 defines how a device processes signed and unsigned redirect information.
To use this approach, the device MAY perform DNS-SD via multicast DNS [RFC6762] searching for the service "_zerotouch._tcp.local.". Alternatively the device MAY perform DNS-SD via normal DNS operation, using the domain returned to it from the DHCP server, searching for the service "_zerotouch._tcp.example.com".
The mapping of redirect information onto DNS SRV [RFC2782] and DNS TXT [RFC1035] records is as follows:
The applicability of this approach across vendors is limited due to the ownership voucher being a manufacturer-specific format. This limitation only impacts signed data, when the ownership voucher is used; there is no such limitation when unsigned data is communicated.
A device MAY attempt to acquire bootstrapping data from a DHCP server (e.g., using one of the DHCP options defined in Section 9.1). The bootstrapping data MAY be either redirect information or bootstrap information.
If redirect information is provided, it SHOULD be signed, as the DHCP protocol is not a secure protocol. However, if the redirect information is not signed, then the device MUST NOT trust any included trust anchor certificates, which means that the device would have to establish an unsecured connection to the specified bootstrap servers. See Section 3.1 for more about this case.
If bootstrap information is provided, it MUST be signed, as the DHCP protocol is not a secure protocol and there is no option to process the data in a degraded manner, unlike as with redirect information.
For the case when the signed bootstrap information is provided, it is notable that the URL would have to point to another file server (e.g., http://, ftp://, etc.), as DHCP servers do not themselves distribute files.
It is expected that DHCP servers will provide redirect information more often than bootstrap information, since redirect information is more generic, potentially applicable to a large number of devices, with the number limited only by the number of devices listed by the associated ownership voucher. Still, because the ownership voucher is a manufacturer specific format, it is advisable for devices to send the Vendor Class Identifier (option 60) field in their DHCP lease requests, so that the DHCP server doesn't accidentally hand it another manufacturer's voucher format.
If it is desired for the DHCP server to return bootstrap information, care should be taken to ensure that bootstrap information is applicable to all the devices that might connect to the DHCP server. The device SHOULD again pass the Vendor Class Identifier (option 60) field in its DHCP lease request. However, if it is desired to return device-specific bootstrap information, then the device SHOULD also send the Client Identifier (option 61) field in its DHCP lease request so that the DHCP server can select the specific bootstrap information that has been staged for that one device.
A device MAY attempt to acquire bootstrapping data from a trusted Internet-based bootstrap server, a server implementing the RESTCONF API defined by the YANG module provided in Section 7.4. The bootstrapping data provided by the server MAY be either redirect information or bootstrap information.
Notably, when using the "notification" action defined in Section 7.4, a bootstrap server is not only a source for bootstrapping data, but can also be the consumer of notification messages from devices. These notification messages both enable visibility into the bootstrapping process (e.g., reporting warnings and errors) and well as provide potentially useful completion status information (e.g., the device's SSH host-keys).
If the device is able to trust the bootstrap server, by verifying its TLS server certificate using a preconfigured or learned trust anchor, then the data the device obtains from the bootstrap server MAY be unsigned. Notably, this is the only mechanism defined in this document whereby unsigned bootstrap information (not redirect information) can be used. When the device is able to trust the bootstrap server, it MUST send its IDevID certificate in the form of a client certificate, and MUST send notifications to the bootstrap server, using the "notification" action defined in Section 7.4.
If the device is unable to trust the bootstrap server, then the data the device obtains from the bootstrap server MUST be signed. When the device connects to an untrusted bootstrap server, the device MUST NOT send its IDevID certificate in the form of a client certificate, and MUST NOT send any notifications to the bootstrap server, using the "notification" action defined in Section 7.4.
The zero touch solution presented in this document is conceptualized to be composed of the workflows described in this section. Implementations MAY vary in details. Each diagram is followed by a detailed description of the steps presented in the diagram, with further explanation on how implementations may vary.
The following diagram illustrates key interactions that occur from when a prospective owner enrolls in a manufacturer's zero touch program to when the manufacturer ships devices for an order placed by the prospective owner.
+-----------+
+------------+ |Prospective| +---+
|Manufacturer| | Owner | |NMS|
+------------+ +-----------+ +---+
| | |
| | |
| 1. initiate enrollment | |
#<-----------------------------| |
# | |
# | |
# IDevID trust anchor | |
#-----------------------------># set IDevID trust anchor |
# #--------------------------->|
# | |
# (optional) bootstrap server | |
# account credentials | |
#-----------------------------># (optional) set credentials |
# #--------------------------->|
# | |
# | |
# (optional) owner certificate | |
#-----------------------------># (optional) set certificate |
| #--------------------------->|
| | |
| | |
| 2. place device order | |
|<-----------------------------# model devices |
| #--------------------------->|
| | |
| 3. ship devices and send | |
| device identifiers and | |
| ownership vouchers | |
|-----------------------------># set device identifiers |
| # and ownership vouchers |
| #--------------------------->|
| | |
| | |
The interactions in the above diagram are described below.
The following diagram illustrates how an owner stages the network for bootstrapping devices.
+----------+ +------------+
|Deployment| |Manufacturer| +------+ +------+
| Specific | | Hosted | |Local?| | Local| +---------+
+---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable|
|NMS| | Server | | Server | |Server| |Server| | Storage |
+---+ +----------+ +------------+ +------+ +------+ +---------+
| | | | | |
activate | | | | | |
modeled | | | | | |
1. device | | | | | |
----------->| | | | | |
| | | | | |
| 2. (optional) configure | | |
| bootstrap server | | | |
|------->| | | | |
| | | | | |
| 3. (optional) configure | | |
| redirect server | | | |
|--------------------->| | | |
| | | | | |
| | | | | |
| 4. (optional) configure DNS server| | |
|---------------------------------->| | |
| | | | | |
| | | | | |
| 4. (optional) configure DHCP server | |
|------------------------------------------->| |
| | | | | |
| | | | | |
| 5. (optional) store bootstrapping artifacts on media |
|----------------------------------------------------->|
| | | | | |
| | | | | |
The interactions in the above diagram are described below.
The following diagram illustrates how a device might behave when powered on. Note that this is merely exemplary, subject to which bootstrapping strategies the device supports, which may be more or less than depicted below.
This diagram sequences the sources of bootstrapping information (see Section 4) based on locality, or how "close" the data is to the device, which is RECOMMENDED. Whether this sequence makes sense for a specific type of device needs to be determined by the manufacturer.
+------------+ +----------+
+------+ |Manufacturer| |Deployment|
+---------+ | Local| | Hosted | | Specific |
+------+ |Removable| | DHCP | | Bootstrap | |Bootstrap | +---+
|Device| | Storage | |Server| | Server | | Server | |NMS|
+------+ +---------+ +------+ +------------+ +----------+ +---+
| | | | | |
| | | | | |
| 1. if not factory default, then exit. | | |
| | | | | |
| | | | | |
| 2. (optional) check | | | |
#----------->| | | | |
# if signed redirect information found | | |
#------------------------------------------------------># webhook |
# either NMS-initiated NC or RC connection #--------->#
#<-----------------------------------------------------------------#
# or device-initiated NC or RC call home connection | |
#----------------------------------------------------------------->|
# else if signed bootstrap information found (call home)| |
#----------------------------------------------------------------->|
# if bootstrapped then exit, else move to next step. | |
| | | | | |
| | | | | |
| 3. (optional) check | | | |
#------------------------>| | | |
# if signed redirect information found | | |
#------------------------------------------------------># webhook |
# either NMS-initiated NC or RC connection #--------->#
#<-----------------------------------------------------------------#
# or device-initiated NC or RC call home connection | |
#----------------------------------------------------------------->|
# else if signed bootstrap information found (call home)| |
#----------------------------------------------------------------->|
# if bootstrapped then exit, else move to next step. | |
| | | | | |
| | | | | |
| 4. (optional) check | | | |
#-------------------------------------->| | |
# if signed or unsigned redirect information found | |
#------------------------------------------------------># webhook |
# either NMS-initiated NC or RC connection #--------->#
#<-----------------------------------------------------------------#
# or device-initiated NC or RC call home connection | |
#----------------------------------------------------------------->|
# else if signed or unsigned bootstrap info found (call home) |
#----------------------------------------------------------------->|
# if bootstrapped then exit, else move to next step. | |
| | | | | |
|
| 5. loop and/or wait for manual provisioning.
|
[Key: NC==NETCONF, RC==RESTCONF]
The interactions in the above diagram are described below.
If the device is unable to bootstrap using any of the information on the removable storage device, it would proceed to the next source of bootstrapping information, if any.
Devices supporting Zero Touch MUST have the preconfigured factory default state and bootstrapping logic described in the following sections.
+------------------------------------------------------------------+ | <device> | | | | +----------------------------------------------------------+ | | | <read-only storage> | | | | | | | | 1. list of trusted Internet based 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 | | | +----------------------+ | | | +------------------------------------------------------------------+
Each numbered item below corresponds to a numbered item in the diagram above.
A device claiming to support Zero Touch MUST support the boot sequence described in this section.
Power On
|
v No
1. Running default config? --------> Boot normally
|
| Yes
v
2. For each supported source for bootstrapping data,
try to load bootstrapping data from the source
|
|
v Yes
3. Able to bootstrap off any source? -----> Run with new configuration
|
| No
v
4. Loop or wait for manual provisioning.
These interactions are described next.
This section describes a recursive algorithm that a device claiming to support Zero Touch MUST use to authenticate bootstrapping data. A device enters this algorithm for each new source of bootstrapping data. The first time the device enters this algorithm, it MUST initialize a conceptual trust state variable, herein referred to as "trust-state", to FALSE. The ultimate goal of this algorithm is for the device to process bootstrap information (not redirect information) while the trust-state variable is TRUE.
If the data source is a bootstrap server, and the device is able to authenticate the server using X.509 certificate path validation ([RFC6125], Section 6) to one of the the device's preconfigured trust anchors, or to a trust anchor that it learned from a previous step, then the device MUST set trust-state to TRUE. If trust-state is TRUE, when connecting to the bootstrap server, the device MUST use its IDevID certificate for a client-certificate based authentication and MUST POST progress notifications using the bootstrap server's "notification" action. Otherwise, if trust-state is FALSE, when connecting to the bootstrap server, the device MUST NOT use its IDevID certificate for a client-certificate based authentication and MUST NOT POST progress notifications using the bootstrap server's "notification" action. When accessing a bootstrap server, the device MUST only access its top-level resource, to obtain all the data staged for it in one GET request, so that it can determine if the data is signed or not, and thus act accordingly.
For any data source, if the data is signed (i.e. the data includes a 'signature' field) and the device is able to validate the signed data using the algorithm described in Section 6.4, then the device MUST set trust-state to TRUE, else the device MUST set trust-state to FALSE. Note, this is worded to cover the special case when signed data is returned even from a trusted bootstrap server.
If the data is bootstrap information (not redirect information), and trust-state is FALSE, the device MUST exit the recursive algorithm, returning to the state machine described in Section 6.2. Otherwise, the device MUST attempt to process the bootstrap information as described in Section 6.6. In either case, success of failure, the device MUST exit the recursive algorithm, returning to the state machine described in Section 6.2, the only difference being in how it responds to the "Able to bootstrap off any source?" conditional described in that state machine.
If the data is redirect information, the device MUST process the redirect information as described in Section 6.5. This is the recursion step, it will cause to device to reenter this algorithm, but this time the data source will most definitely be a bootstrap server, as that is all redirect information is able to do, though it's interesting to note that the bootstrap server's response MAY be more redirect information.
Whenever a device is presented signed data, it MUST validate the signed data as described in this section.
Whenever there is signed data, the device MUST also be provided an ownership voucher and an owner certificate. How all the needed records are provided for each source of bootstrapping data is defined in Section 4
The device MUST first authenticate the ownership voucher by validating the signature on it to one of its preconfigured trust anchors (see Section 6.1) and verify that the voucher contains the device's unique identifier (e.g., serial number). If the authentication of the voucher is successful, the device extracts the Rightful owner's identity from the voucher for use in the next step.
Next the device MUST authenticate the owner certificate by performing X.509 certificate path validation on it to one of its preconfigured trust anchors (see Section 6.1) and by verifying that the Subject contained in the certificate matches the Rightful owner identity extracted from the voucher in the previous step. If the authentication of the certificate is successful, the device extracts the owner's public key from the certificate for use in the next step.
Finally the device MUST authenticate the signed data by verifying the signature on it was generated by the private key matching the public key extracted from the owner certificate in the previous step.
If any of these steps fail, then the device MUST mark the data as invalid and not perform any of the subsequent steps.
In order to process redirect information (Section 3.1), the device MUST follow the steps presented in this section.
Processing redirect information is straightforward. Essentially the device MUST immediately attempt to establish a RESTCONF connection to the provided bootstrap server IP address or hostname.
If a hostname is provided, and its DNS resolution is to more than one IP address, the device MUST attempt to try to connect to all of them, sequentially, until it is able to successfully bootstrap off one of them.
If the redirect information includes a trust anchor, and the redirect information can be trusted (e.g., trust-state is TRUE), then the device MUST authenticate the bootstrap server using X.509 certificate path validation ( [RFC6125], Section 6) using the specified trust anchor.
In order to process bootstrap information (Section 3.2), the device MUST follow the steps presented in this section.
When processing bootstrap information, the device MUST first process the boot image information, then commit the initial configuration, and then execute the script, if any, in that order. If the device encounters an error at any step, it MUST NOT proceed to the next step.
First the device MUST determine if the image it is running satisfies the specified "boot-image" criteria. If it does not, the device MUST download, verify, and install the specified boot image, and the reboot. To verify the boot image, the device MUST check that the boot image file matches both the MD5 and SHA fingerprints supplied by the bootstrapping information. Upon rebooting, the device MUST still be in its factory default state, causing the bootstrapping process to run again, which will eventually come to this very point, but this time the device's running image will satisfy the specified criteria, and thus the device moves to processing the next step.
Next the device commits the provided initial configuration. Assuming no errors, the device moves to processing the next step.
Next, for devices that support executing scripts, if a script has been specified, the device executes the script, checking its exit status code to determine if it succeeded, had warning, or had errors. In the case of errors, the device MUST reset itself in such a way that force the reinstallation of its boot image, thereby wiping out any bad state the script might have left behind.
At this point, the device has completely processed the bootstrapping data and is ready to be managed. If the configuration configured the device it initiate a call home connection, it should proceed to do so now. Otherwise, the device should wait for a NETCONF or RESTCONF client to connect to it.
Central to the solution presented in this document is the use of a YANG module [RFC6020] to simultaneously define a RESTCONF based API for a bootstrap/redirect server as well as the encoding for signed artifacts that can be conveyed outside of the RESTCONF protocol (DHCP, FTP, TFTP, etc.).
The module defined in this section makes extensive use of data types defined in [RFC2315], [RFC5280], and [RFC6991].
The following tree diagram Section 1.3 provides an overview for both the API and artifacts that can be used outside of RESTCONF.
module: ietf-zerotouch-bootstrap-server
+--ro devices
+--ro device* [unique-id]
+--ro unique-id string
+--ro (type)?
| +--:(redirect-information)
| | +--ro redirect-information
| | +--ro bootstrap-server* [address]
| | +--ro address inet:host
| | +--ro port? inet:port-number
| | +--ro trust-anchor binary
| +--:(bootstrap-information)
| +--ro bootstrap-information
| +--ro boot-image
| | +--ro modules
| | | +--ro module*
| | | +--ro name? yang:yang-identifier
| | | +--ro revision? string
| | +--ro name string
| | +--ro md5 string
| | +--ro sha1 string
| | +--ro uri* inet:uri
| +--ro configuration-handling? enumeration
| +--ro pre-configuration-script? script
| +--ro configuration?
| +--ro post-configuration-script? script
+--ro owner-certificate
| +--ro certificate binary
| +--ro issuer-crl? binary
+--ro ownership-voucher
| +--ro voucher binary
| +--ro issuer-vrl? binary
+--ro signature? binary
+---x notification
+---w input
+---w notification-type enumeration
+---w message? string
+---w ssh-host-keys
| +---w ssh-host-key*
| +---w format enumeration
| +---w key-data string
+---w trust-anchors
+---w trust-anchor*
+---w protocol* enumeration
+---w certificate binary
In the above diagram, notice that all of the protocol accessible node are read-only, to assert that devices can only pull data from the bootstrap server.
Also notice that the module defines an action statement, which devices may use to provide progress notifications to the bootstrap server.
This section presents some examples illustrating device interactions with a bootstrap server to access Redirect and Bootstrap information, both unsigned and signed, as well as to send a progress notification. These examples show the bootstrap information containing configuration defined by [RFC7317] and [draft-ietf-netconf-server-model].
The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives unsigned redirect information. This example is representative of a response a trusted redirect server might return.
REQUEST
-------
['\' line wrapping added for formatting only]
GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456 HTTP/1.1
HOST: example.com
Accept: application/yang.data+xml
RESPONSE
--------
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<device
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<unique-id>123456789</unique-id>
<redirect-information>
<bootstrap-server>
<address>phs1.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</trust-anchor>
</bootstrap-server>
<bootstrap-server>
<address>phs2.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</trust-anchor>
</bootstrap-server>
</redirect-information>
</device>
The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives signed redirect information. This example is representative of a response that redirect server might return if concerned the device might not be able to authenticate its TLS certificate.
REQUEST
-------
['\' line wrapping added for formatting only]
GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456 HTTP/1.1
HOST: example.com
Accept: application/yang.data+xml
RESPONSE
--------
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<device
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<unique-id>123456789</unique-id>
<redirect-information>
<bootstrap-server>
<address>phs1.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</trust-anchor>
</bootstrap-server>
<bootstrap-server>
<address>phs2.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</trust-anchor>
</bootstrap-server>
</redirect-information>
<owner-certificate>
<certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\
AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\
2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\
z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\
Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\
96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ==
</certificate>
<issuer-crl>
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO==
</issuer-crl>
</owner-certificate>
<ownership-voucher>
<voucher>
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO
</voucher>
<issuer-crl>
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
</issuer-crl>
</ownership-voucher>
<signature>
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
</signature>
</device>
The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives unsigned bootstrapping information. This example is representative of a response a locally deployed bootstrap server might return.
REQUEST
-------
['\' line wrapping added for formatting only]
GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456 HTTP/1.1
HOST: example.com
Accept: application/yang.data+xml
RESPONSE
--------
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<device
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<unique-id>123456789</unique-id>
<bootstrap-information>
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<uri>
ftp://ftp.example.com/path/to/file
</uri>
</boot-image>
<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>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\
jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\
E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\
WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\
vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\
EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\
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>
</bootstrap-information>
</device>
The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives signed bootstrap information. This example is representative of a response that bootstrap server might return if concerned the device might not be able to authenticate its TLS certificate.
REQUEST
-------
['\' line wrapping added for formatting only]
GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456 HTTP/1.1
HOST: example.com
Accept: application/yang.data+xml
RESPONSE
--------
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<device
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<unique-id>123456789</unique-id>
<bootstrap-information>
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<uri>
/path/to/on/same/bootserver
</uri>
</boot-image>
<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>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\
jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\
E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\
WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\
vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\
EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\
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>
</bootstrap-information>
<owner-certificate>
<certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\
AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\
2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\
z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\
Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\
96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ==
</certificate>
<issuer-crl>
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO==
</issuer-crl>
</owner-certificate>
<ownership-voucher>
<voucher>
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO
</voucher>
<issuer-vrl>
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
</issuer-vrl>
</ownership-voucher>
<signature>
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
</signature>
</device>
The following example illustrates a device using the API to post a notification to the server. The device may send more than one notification to the server (e.g., to provide status updates).
The bootstrap server MUST NOT process a notification from a device without first authenticating the device. This is in contrast to when a device is fetching data from the server, a read-only operation, in which case device authentication is not strictly required.
In this example, the device sends a notification indicating that it has completed bootstrapping off the data provided by the server. This example also illustrates the device sending its SSH host keys to the bootstrap server, which it might, for example, forward onto a downstream NMS component, so that the NMS can subsequently authenticate the device when establishing a NETCONF over SSH connection to it.
Note that the need for a device to provide its SSH host key (or TLS server certificate) in the "bootstrap-complete" message is unnecessary when the device is able to present its IDevID certificate [Std-802.1AR-2009] as its SSH host key or TLS server certificate, when subsequently establishing a NETCONF or RESTCONF connection with the deployment-specific NMS.
REQUEST
-------
['\' line wrapping added for formatting only]
POST https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456/notification HTTP/1.1
HOST: example.com
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<notification-type>bootstrap-complete</notification-type>
<message>example message</message>
<ssh-host-keys>
<ssh-host-key>
<format>ssh-rsa</format>
<key-data>
AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\
zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\
zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\
9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\
QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\
LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\
VOZZgQ8929uWjCWlGlqn2mPibp2Go1
</key-data>
</ssh-host-key>
<ssh-host-key>
<format>ssh-dsa</format>
<key-data>
zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\
zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\
9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\
AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\
QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\
LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\
VOZZgQ8929uWjCWlGlqn2mPibp2Go1
</key-data>
</ssh-host-key>
</ssh-host-keys>
<trust-anchors>
<trust-anchor>
<protocol>netconf-ssh</protocol>
<protocol>netconf-tls</protocol>
<protocol>restconf-tls</protocol>
<protocol>netconf-ch-ssh</protocol>
<protocol>netconf-ch-tls</protocol>
<protocol>restconf-ch-tls</protocol>
<certificate>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</certificate>
</trust-anchor>
</trust-anchors>
</input>
RESPONSE
--------
HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
This section presents some examples for how the same information provided by the API can be packaged into stand alone artifacts. The encoding for these artifacts is the same as if an HTTP GET request had been sent to the RESTCONF URL for the specific resource. These examples show the bootstrap information containing configuration defined by [RFC7317] and [draft-ietf-netconf-server-model].
Encoding these artifacts for use outside of the RESTCONF protocol extends their utility for other deployment scenarios, such as when a local DHCP server or a removable storage device is used. By way of example, this may be done to address an inability for the device to access an Internet facing bootstrap/redirect server, or just for a preference to use locally deployed infrastructure.
The following example illustrates how a redirect can be encoded into an artifact for use outside of the RESTCONF protocol. The redirect information is signed so that it is secure even when no transport-level security is provided.
<!-- '\' line wrapping added for formatting purposes only -->
<redirect-information
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<bootstrap-server>
<address>phs1.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\
RJSUJQFRStS0Cg==
</trust-anchor>
</bootstrap-server>
<bootstrap-server>
<address>phs1.example.com</address>
<port>8443</port>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
</trust-anchor>
</bootstrap-server>
</redirect-information>
The following example illustrates how bootstrapping data can be encoded into an artifact for use outside of the RESTCONF protocol. The bootstrap information is signed so that it is secure when no transport-level security is provided.
<!-- '\' line wrapping added for formatting purposes only -->
<bootstrap-information
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<uri>
file:///some/path/to/raw/file
</uri>
</boot-image>
<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>
</bootstrap-information>
The following example illustrates how the signature can be encoded into an artifact for use outside of the RESTCONF protocol.
<!-- '\' line wrapping added for formatting purposes only --> <signature xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"> MIIB3wYJKoZIhvcNAQcCoIIB0DCCAcwCAQExDzANBglghkgBZQMEAgEFADALBgkq\ hkiG9w0BBwExggGnMIIBowIBATB8MHcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApD\ YWxpZm9ybmlhMRkwFwYDVQQKDBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLDBRD\ ZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAwwQVFBNX1RydXN0X0FuY2hvcgIB\ AjANBglghkgBZQMEAgEFADANBgkqhkiG9w0BAQEFAASCAQCed5FbjBUKyryN8Zwq\ Oh+8dkwjVXa58uLP1ZCTnULsVkmRDrXBq1hHiGXEa9qyr4xizyXeXHaTfCHd1k0x\ fPnmMeWnfWdhZsCF4tBc07yDfTprjv7jlqEMd/79vdyh3cxvOLoc/Yq3MYLe2vq/\ 84UkBvY2XVCB/d/l9QboeEMMsazEwCNeIOp+LYah7um+lCkAXtPmc8qg2B4D/Tx4\ xVqB4U0HR1JnobKuunjHQeiKtbJWeaa1/ORIWU2zdwUa7x4Bt0vNtCL1V7fIU/6n\ /nSjs6zqMklsayXNwp9bLjkoRP+mHDKDlf0umlqRN8ljWueBeSQTPUNFdVxtk3JF\ ocTw </signature>
The following example illustrates how the owner certificate, along with its CRL, can be encoded into an artifact for use outside of the RESTCONF protocol. Note that the inclusion of the CLR is optional, and only present to support cases where the device is deployed on a private network, such that it would be unable to validate the revocation status of the certificate using an online lookup of the CRL or using OCSP. As the owner certificate and CRL are already signed by the manufacturer, an additional owner signature is unnecessary.
<!-- '\' line wrapping added for formatting purposes only -->
<owner-certificate
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<certificate>
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\
AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\
2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\
z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\
Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\
96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ==
</certificate>
<issuer-crl>
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO==
</issuer-crl>
</owner-certificate>
The following example illustrates how the ownership voucher, along with its CRL, can be encoded into an artifact for use outside of the RESTCONF protocol. Note that the inclusion of the CLR is optional, and only present to support cases where the device is deployed on a private network, such that it would be unable to validate the revocation status of the certificate using an online lookup of the CRL or using OCSP. As the ownership voucher and CRL are already signed by the manufacturer, an additional owner signature is unnecessary.
<!-- '\' line wrapping added for formatting purposes only -->
<ownership-voucher
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<voucher>
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\
MjAO
</voucher>
<issuer-crl>
QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\
RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\
KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\
8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\
WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\
NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX=
</issuer-crl>
</ownership-voucher>
The bootstrap server's device-facing interface is normatively defined by the following YANG module:
<CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2016-07-08.yang"
module ietf-zerotouch-bootstrap-server {
yang-version "1.1";
namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
prefix "ztbs";
import ietf-yang-types { // RFC 6991
prefix yang;
}
import ietf-inet-types { // RFC 6991
prefix inet;
}
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 Zero Touch
bootstrap servers.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision "2016-07-08" {
description
"Initial version";
reference
"RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
}
container devices {
config false;
description
"This is the top-level container for a device-facing protocol.
As such it is read-only, how this data is configured is outside
the scope of this data-model. Further, it is expected that
devices would only be able to access their data and not the
data for any other device.";
list device {
key unique-id;
description
"A device's record entry. This is the only RESTCONF resource
that a device is expected to GET. Getting this just this
top-level provides the device with all the data it needs in
a single request, which is ideal from both a performance and
a resiliency perspectives..";
leaf unique-id {
type string;
description
"A unique identifier for the device (e.g., serial number).
Each device accesses its bootstrapping record by its unique
identifier.";
}
choice type {
description
"This choice statement ensures the response only contains
redirect-information or bootstrap-information.";
container redirect-information {
description
"This is redirect information data. Its purpose is to
redirect the device to another bootstrap server. It
contains a list of bootstrap servers.";
list bootstrap-server {
key address;
description
"A bootstrap server entry.";
leaf address {
type inet:host;
description
"The IP address or hostname of the bootstrap server
the device should redirect to.";
}
leaf port {
type inet:port-number;
default 443;
description
"The port number the bootstrap server listens on.";
}
leaf trust-anchor {
type binary;
mandatory true;
description
"An X.509 v3 certificate structure as specified by RFC
5280, Section 4 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690. A
certificate that a device can use as a trust anchor to
authenticate the bootstrap server it is being redirected
to.";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
}
}
container bootstrap-information {
description
"This is bootstrap information data. Its purpose is to
provide the device everything it needs to bootstrap
itself.";
container boot-image {
description
"Specifies criteria for the boot image the device MUST be
running.";
container modules {
description
"Specifies a list of YANG modules that the device MUST
support. This node is optional. When this node is
specified, the remaining nodes MUST be processed only
in case the currently running image does not support
any of the YANG modules, as a means to obtain a valid
image. When this node is not specified, then the
device MUST ensure it is running the exact image, as
specified by the remaining 'boot-image' nodes.";
list module {
description
"Specifies a specific YANG modules, by its name and
revision date. The revision date is provided as a
minimal revision date, and supported revision
thereafter is considered sufficient";
leaf name {
type yang:yang-identifier;
description
"The YANG module's name.";
}
leaf revision {
type string {
pattern '\d{4}-\d{2}-\d{2}';
}
description
"Represents a specific date in 2016-07-08 format.";
}
}
}
leaf name {
type string;
mandatory true;
description
"The name of a software image that either the device
MUST be running, or MUST install only if its currently
running image cannot support any of the required YANG
modules.";
}
// Please see https://github.com/netconf-wg/zero-touch/issues/17
// regarding the following two leafs!
leaf md5 {
type string;
mandatory true;
description
"The hex-encoded MD5 hash over the boot-image file.";
}
leaf sha1 {
type string;
mandatory true;
description
"The hex-encoded SHA-1 hash over the boot-image file.";
}
leaf-list uri {
type inet:uri;
min-elements 1;
description
"An ordered list of URIs to where the boot-image file
may be obtained. When the bootstrap information is
obtained from a bootstrap server, it is RECOMMENDED
that the list begins with absolute paths (e.g.,
beginning with '/') to the bootstrap server, so as
to leverage the existing secure connection. If remote
URLs are also present in the list, deployments MUST
know in advance which URI schemes (https, http, ftp,
file, etc.) a device supports. If a secure scheme
(e.g., https) is provided, devices MAY blindly accept
the server's credentials (e.g., TLS certificate).
Regardless how obtained, the device MUST ensure that
the boot-image is valid, either by leveraging a
signature embedded in the boot-image itself, if it
exists, or by first comparing the downloaded image to
both the MD5 and SHA1 fingerprints provided above.";
}
}
leaf configuration-handling {
type enumeration {
enum merge {
description
"Merge configuration into existing running configuration.";
}
enum replace {
description
"Replace existing running configuration with passed
configuration.";
}
enum edit-config {
description
"Process configuration as an <edit-config> document.";
}
enum yang-patch {
description
"Process configuration as a YANG Patch document.";
}
}
description
"This value indicates how the server should process the
provided configuration.";
}
leaf pre-configuration-script {
type script;
description
"A script that, when present, is executed after the
boot-image is verified but before the configuration
has been processed.";
}
anyxml configuration { // pyang validation doesn't support anydata yet
must "../configuration-handling";
description
"Any configuration data model known to the device. It may
contain manufacturer-specific and/or standards-based data
models.";
}
leaf post-configuration-script {
type script;
description
"A script that, when present, is executed after the
configuration has been processed.";
}
}
}
container owner-certificate {
when "../ownership-voucher" {
description
"The owner certificate is only configurable when there
also exists an ownership voucher.";
}
description
"It is intended that the device will fetch this container
as a whole, as it contains values that need to be
processed together.";
// Please see https://github.com/netconf-wg/zero-touch/issues/16
// regarding the following leaf!
leaf certificate {
type binary;
mandatory true;
description
"An X.509 v3 certificate structure as specified by RFC
5280, Section 4 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.
This certificate, signed by a manufacturer or delegate,
for an owner, must encode a manufacturer-assigned value
identifying the organization. This identifier must match
the owner identifier encoded in the ownership voucher.";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
leaf issuer-crl {
type binary;
description
"An CRL structure as specified by RFC 5280, Section 5
encoded using the ASN.1 distinguished encoding rules
(DER), as specified in ITU-T X.690. The CRL for the
CA that signed the owner certificate. The CRL should
be as up to date as possible. This leaf is optional
as it is only needed to support deployments where the
device is unable to download the CRL from and of the
distribution points listed in the owner certificate.";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
}
container ownership-voucher {
when "../signature" {
description
"An ownership voucher is only configurable when there
also exists a signature.";
}
must "../owner-certificate" {
description
"An owner certificate must be present whenever an
ownership voucher is present.";
}
description
"This container contains the ownership voucher that the
device uses to ascertain the identity of its rightful
owner, as certified by its manufacturer.";
leaf voucher {
type binary;
mandatory true;
description
"A manufacturer-specific encoding binding unique device
identifiers to an owner identifier value matching the
value encoded in the owner-certificate below.";
}
leaf issuer-vrl {
type binary;
description
"An manufacturer-specific encoding of a voucher revocation
list (VRL) for the issuer used by the manufacturer or
delegate to sign ownership vouchers. The VRL should be
as up to date as possible. This leaf is optional as it
is only needed to support deployments where the device
is unable to download the VRL from the manufacturer or
delegate using some manufacturer-specific mechanism.";
}
}
leaf signature {
type binary;
must "../ownership-voucher" {
description
"An ownership voucher must be present whenever an
signature is present.";
}
description
"A PKCS #7 SignedData structure as specified by RFC
2315, Section 9.1 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.
This signature is generated using the owner's private
private key and an owner-selected digest algorithm over
the redirect-information or the bootstrap-information
nodes, which ever is present, and in whatever encoding
they are presented in (e.g., XML, JSON, etc.).";
// is there a canonical format?
reference
"RFC 2315:
PKCS #7: Cryptographic Message Syntax Version 1.5
ITU-T X.690:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
action notification { // pyang validation doesn't support actions yet
input {
leaf notification-type {
type enumeration {
enum bootstrap-initiated {
description
"Indicates that the device has just accessed
the bootstrap server. The 'message' field
below SHOULD contain any additional information
that the manufacturer thinks might be useful,
or omitted entirely.";
}
enum validation-error {
description
"Indicates that the device had an issue validating
the response from the bootstrap server. The
'message' field below SHOULD indicate the specific
error. This message also indicates that the device
has abandoned trying to bootstrap off this bootstrap
server.";
}
enum signature-validation-error {
description
"Indicates that the device had an issue validating
the bootstrapping data. For instance, this could
be due to the device expecting signed data, but
only found unsigned data, or because the ownership
voucher didn't include its unique identifier, or
because the signature didn't match, or and other
relevant error. This 'message' field below SHOULD
indicate the specific error. This message also
indicates that the device has abandoned trying to
bootstrap off this bootstrap server.";
}
enum image-mismatch {
description
"Indicates that the device has determined that
its running image does not meet the specified
criteria. The 'message' field below SHOULD
indicate both what image the device is currently
running as well as the criteria that failed.";
}
enum image-download-error {
description
"Indicates that the device had an issue downloading
the image, which could be anything from the file
server being unreachable to the downloaded file
being the incorrect file (signature mismatch). The
'message' field about SHOULD indicate the specific
error. This message also indicates that the device
has abandoned trying to bootstrap off this bootstrap
server.";
}
enum config-warning {
description
"Indicates that the device obtained warning messages
when it committed the initial configuration. The
'message' field below SHOULD indicate the warning
messages that were generated.";
}
enum config-error {
description
"Indicates that the device obtained error messages
when it committed the initial configuration. The
'message' field below SHOULD indicate the error
messages that were generated. This message also
indicates that the device has abandoned trying to
bootstrap off this bootstrap server.";
}
enum script-warning {
description
"Indicates that the device obtained a greater than
zero exit status code from the script when it was
executed. The 'message' field below SHOULD indicate
both the resulting exit status code and well as
capture any stdout/stderr messages the script may
have produced.";
}
enum script-error {
description
"Indicates that the device obtained a less than zero
exit status code from the script when it was executed.
The 'message' field below SHOULD indicate both the
resulting exit status code and well as capture any
stdout/stderr messages the script may have produced.
This message also indicates that the device has
abandoned trying to bootstrap off this bootstrap
server.";
}
enum bootstrap-complete {
description
"Indicates that the device successfully processed the
all the bootstrapping data and that it is ready to
be managed. The 'message' field below SHOULD contain
any additional information that the manufacturer
thinks might be useful, or omitted entirely. At
this point, the device is not expected to access
the bootstrap server again.";
}
enum informational {
description
"Provided any additional information not captured by
any of the other notification-type. The 'message'
field below SHOULD contain any additional information
that the manufacturer thinks might be useful, or
omitted entirely.";
}
}
mandatory true;
description
"The type of notification provided.";
}
leaf message {
type string;
description
"An optional human-readable value.";
}
container ssh-host-keys {
description
"A list of SSH host keys an NMS may use to authenticate
a NETCONF connection to the device with.";
list ssh-host-key {
when "../type = bootstrap-complete" {
description
"SSH host keys are only sent when the notification
type is 'bootstrap-complete'.";
}
description
"An SSH host-key";
leaf format {
type enumeration {
enum ssh-dss { description "ssh-dss"; }
enum ssh-rsa { description "ssh-rsa"; }
}
mandatory true;
description
"The format of the SSH host key.";
}
leaf key-data {
type string;
mandatory true;
description
"The key data for the SSH host key";
}
}
}
container trust-anchors {
description
"A list of trust anchor certificates an NMS may use to
authenticate a NETCONF or RESTCONF connection to the
device with.";
list trust-anchor {
when "../type = bootstrap-complete" {
description
"Trust anchors are only sent when the notification
type is 'bootstrap-complete'.";
}
description
"A list of trust anchor certificates an NMS may use to
authenticate a NETCONF or RESTCONF connection to the
device with.";
leaf-list protocol {
type enumeration {
enum netconf-ssh { description "netconf-ssh"; }
enum netconf-tls { description "netconf-tls"; }
enum restconf-tls { description "restconf-tls"; }
enum netconf-ch-ssh { description "netconf-ch-ssh"; }
enum netconf-ch-tls { description "netconf-ch-tls"; }
enum restconf-ch-tls { description "restconf-ch-tls"; }
}
min-elements 1;
description
"The protocols that this trust anchor secures.";
}
leaf certificate {
type binary;
mandatory true;
description
"An X.509 v3 certificate structure as specified by RFC
5280, Section 4 encoded using the ASN.1 distinguished
encoding rules (DER), as specified in ITU-T X.690.";
reference
"RFC 5280:
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile.
ITU-T X.690:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).";
}
}
}
}
} // end action
}
}
typedef script {
type binary;
description
"A device specific script that enables the execution of
commands to perform actions not possible thru configuration
alone.
No attempt is made to standardize the contents, running
context, or programming language of the script. The
contents of the script are considered specific to the
vendor, product line, and/or model of the device.
If a script is erroneously provided to a device that
does not support the execution of scripts, the device
SHOULD send a 'script-warning' notification message,
but otherwise continue processing the bootstrapping
data as if the script had not been present.
The script returns exit status code '0' on success
and non-zero on error, with accompanying stderr/stdout
for logging purposes. In the case of an error, the exit
status code will specify what the device should do.
If the exit status code is greater than zero, then the
device should assume that the script had a soft error,
which the script believes does not affect manageability.
If the device obtained the bootstrap information from
a bootstrap server, it SHOULD send a 'script-warning'
notification message.
If the exit status code is less than zero, the device
should assume the script had a hard error, which the
script believes will affect manageability. In this
case, the device should try to send a 'script-error'
notification message followed by a reset that will
force a new boot-image install (wiping out anything
the script may have done) and restart the entire
bootstrapping process again.";
}
}
<CODE ENDS>
Devices MUST ensure that all their trust anchor certificates, including those for the owner certificate and ownership voucher, are protected from external modification.
It may be necessary to update these certificates over time (e.g., the manufacturer wants to delegate trust to a new CA). It is therefore expected that devices MAY update these trust anchors when needed through a verifiable process, such as a software upgrade using signed software images.
The solution in this document relies on TLS certificates, owner certificates, ownership vouchers, and CRLs, all of which require an accurate clock in order to be processed correctly. Devices implementations should take care to ensure the devices have a reliable clock when processing signed data, ideally be using a built-in real time clock (RTC). If a device does not have an RTC, then it SHOULD try to use NTP to initialize its clock before processing any time-sensitive bootstrapping data. It is understood that NTP is itself unsecured, not enabling the client to authenticate the server, and therefore easily spoofed. In the case that NTP is spoofed, it is possible for a replay attack to occur where an ownership voucher assignment from a previous owner is replayed on a device that has since been claimed by a new owner. For this reason, for devices that do not contain an RTC, it is RECOMMENDED that manufacturers only issue a single ownership voucher for the lifetime of a device.
This document allows a device to blindly authenticate a bootstrap server's TLS certificate. It does so to allow for cases where the redirect information may be obtained in an unsecured manner (e.g., via a DNS service discovery lookup, where only a hostname or IP address is returned).
To compensate for this, this document requires that devices do not send their IDevID certificate for client authentication, and that they do not POST any progress notifications, and that they assert that data downloaded from the server is signed, just as bootstrapping data would need to be signed if read from a removable storage device.
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).
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.
The following registrations are in accordance to RFC 2939 [RFC2939] for "BOOTP Manufacturer Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
EDITOR NOTE: This section needs to be fixed, it currently only supports unsigned redirect information. However the complete solution needs to support the full matrix of redirect/bootstrap x signed/unsigned x IPv4/IPv6.
Tag: XXX
Name: Zero Touch Redirect Information
Returns a YANG-defined redirect-information object, encoded in
the encoding specified by 'encoding'. Currently only "xml"
and "json" are supported.
Code Len
+-----+-----+----------+---------------------+
| XXX | n | encoding |redirect-information |
+-----+-----+----------+---------------------+
Reference: RFC XXXX
Tag: YYY
Name: Zero Touch Redirect Information
Returns a YANG-defined redirect-information object, encoded in
the encoding specified by 'encoding'. Currently only "xml"
and "json" are supported.
Code Len
+-----+-----+----------+---------------------+
| XXX | n | encoding |redirect-information |
+-----+-----+----------+---------------------+
Reference: RFC XXXX
This document registers one URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested:
URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace.
This document registers one YANG module in the YANG Module Names registry [RFC6020]. Following the format defined in [RFC6020], the the following registration is requested:
name: ietf-zerotouch-bootstrap-server namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server prefix: ztbs reference: RFC XXXX
Both this document and [draft-pritikin-anima-bootstrapping-keyinfra] define bootstrapping mechanisms. The authors have collaborated on both solutions and believe that each solution has merit and, in fact, can work together. That is, it is possible for a device to support both solutions simultaneously.
The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): David Harrington, Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael Richardson, Phil Shafer, Juergen Schoenwaelder.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original I-D's solution during the IETF 87 meeting in Berlin.
| [draft-pritikin-anima-bootstrapping-keyinfra] | Pritikin, M., Behringer, M. and S. Bjarnason, "Bootstrapping Key Infrastructures", Internet-Draft draft-pritikin-anima-bootstrapping-keyinfra-03, 2016. |
| [RFC2939] | Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000. |
| [RFC3688] | Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
| [RFC6698] | Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012. |
| [RFC7317] | Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014. |
Following describes an example data-model for an ownership voucher. Real vouchers are expected to be encoded in a manufacturer-specific format outside the of scope for this draft.
A tree diagram describing an ownership voucher:
module: example-zerotouch-ownership-voucher
+--rw voucher
+--rw owner-id string
+--rw unique-id* string
+--rw created-on yang:date-and-time
+--rw expires-on? yang:date-and-time
+--rw signature string
The YANG module for this example voucher:
file "example-zerotouch-ownership-voucher@2016-07-08.yang"
module example-zerotouch-ownership-voucher {
namespace
"http://example.com/zerotouch-ownership-voucher";
prefix "ztov";
import ietf-yang-types { prefix yang; }
organization
"Example. Inc.";
contact
"Web Page: <http://example.com/>";
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.";
revision "2016-07-08" {
description
"Initial version";
reference
"RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
}
// top-level container
container voucher {
description
"A voucher, containing the owner's identifier, a list of
device's unique identifiers, information on when the
voucher was created, when it might expire, and the
vendor's signature over the above values.";
leaf owner-id {
type string;
mandatory true;
description
"A Vendor-assigned value for the rightful owner of the
devices enumerated by this voucher. The owner-id value
must match the value in the owner-certificate below";
}
leaf-list unique-id {
type string;
min-elements 1;
description
"The unique identifier (e.g., serial-number) for a device.
The value must match the value in the device's IDevID
certificate. A device uses this value to determine if
the voucher applies to it.";
}
leaf created-on {
type yang:date-and-time;
mandatory true;
description
"The date this voucher was created";
}
leaf expires-on {
type yang:date-and-time;
description
"The date this voucher expires, if at all. Use of this
value requires that the device has access to a trusted
real time clock";
}
leaf signature {
type string;
mandatory true;
description
"The signature over the concatenation of all the previous
values";
}
}
}