| NETCONF Working Group | K. Watsen |
| Internet-Draft | Juniper Networks |
| Intended status: Standards Track | J. Clarke |
| Expires: April 21, 2016 | Cisco Systems |
| M. Abrahamsson | |
| T-Systems | |
| October 19, 2015 |
Zero Touch Provisioning for NETCONF Call Home
draft-ietf-netconf-zerotouch-04
This draft presents a technique for establishing a secure NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its rightful owner's network management system (NMS).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A fundamental business requirement is to reduce costs where possible. For network operators, deploying devices to many locations can be a significant cost, as sending trained specialists to each site to do installations is both cost prohibitive and does not scale.
This document defines bootstrapping strategies enabling a device to securely obtain bootstrapping data with no installer input beyond racking the device and applying power. This bootstrapping data directs the device to install a boot image and an initial configuration, which enables the establishment of a NETCONF [RFC6241] or RESTCONF [draft-ietf-netconf-restconf] connection to its rightful owner's network management system (NMS).
In order to enable a NETCONF or RESTCONF connection to be established, the initial configuration should include settings such as enabling the NETCONF/RESTCONF service, including parameters needed to support an NMS-initiated or device-initiated connection, and configuring a local administrator account. Examples used in this draft illustrate this using models defined by [RFC7317] and [draft-ietf-netconf-server-model].
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 defines 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 device in its factory default state can only trust remote keys for which it has preconfigured trust anchors. For instance, the device may have a trust anchor (e.g., a X.509 certificate) for when authenticating a very specific HTTPS server, and another trust anchor for when validating boot-image files, and yet another trust anchor for when verifying software licenses.
Trust can be conveyed by either transport level security or artifact signing. For instance, if a device connects to an HTTPS server, authenticating the TLS certificate to a known trust anchor, then any data the device receives from the HTTPS server can also be trusted. Likewise, if a device can authenticate the signature over some data to a known trust anchor, then that data can also be trusted. In general, any data obtained from a trusted source MAY be trusted and, any data obtained from an untrusted source MUST NOT be trusted.
It is possible but unnecessary to provide signed data over a secure connection. For instance, a device connecting to a trusted HTTPS server may retrieve data that has been signed by its rightful owner, but this is not required, as the device is already assured by the server that its data was staged by its rightful owner. That said, when an insecure connection is used (e.g., DHCP), the device has no choice but to require that the data be signed, in order to trust the data.
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 both a protocol-oriented solution as well as an artifact based solution for conveying ownership.
The protocol based solution conveys ownership by API contract, in that the server asserts that it will only return data that it is sure was staged by that device's rightful owner. How ownership for a device is assured is out of scope of this document.
The artifact based solution involves the manufacturer signing an owner key and then later, when the ownership for devices is established, the manufacturer signing a voucher that assigns those devices to the owner, and then the owner using their private key to sign the artifacts. Thus, from the device's perspective, it can use the presented "ownership voucher" to validate the presented "owner certificate", which it can then use to validate the signature over the presented artifact.
The YANG module in Section 6.4 includes grouping statements defining the format for the owner certificates and ownership vouchers used by the bootstrapping solution presented in this document.
This document presumes there exists two types of zero touch information: redirect information and bootstrapping information. Either type of data may by accessed as unsigned data over a secure connection to a trusted server (e.g., HTTPS), or as signed artifacts obtained via an insecure method (DHCP server, removable storage device, etc.).
The redirect information type of data provides two bits of information: bootstrap server locations and trust anchors. The trust anchors are provided to enable the device to authentic the specified bootstrap servers (TLS certificate-based authentication). This is what distinguishes this technique from a standard HTTP Redirect and why it may sometimes be called "secure redirect".
The bootstrap information type of data provides information describing the boot-image and configuration the device should be running, in order to be considered bootstrapped. The boot-image information is optional but, if it is provided, the device should install the boot image prior to installing the configuration.
The YANG module in Section 6.4 includes grouping statements defining the format for redirect and bootstrap information types used by the bootstrapping solution presented in this document.
Following are the sources of bootstrapping data that are referenced by the workflow presented in Section 4.3. Other sources for bootstrapping information may be described in other documents, so long as the principles for when the bootstrapping data needs to be signed or not 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.
A device may attempt to read bootstrapping information from a directly attached removable storage device. This information would most likely have to be signed, as removable storage devices are generally not trustworthy.
The information loaded from a removable storage device may redirect the device to a bootstrap server (i.e., redirect information) or it may provide the boot image and configuration (i.e., bootstrapping information) directly. For when providing the information directly, even the raw boot image file could be on the removable storage device, making it a fully self-standing solution.
A device may attempt to read bootstrapping information from a DHCP server (e.g., DHCP options). This information would have to be signed, as the DHCP protocol is not a secure protocol.
The information may again be either redirect or bootstrapping information. If bootstrapping information is provided, the URI to the boot image would have to specify a file server (e.g., ftp://, tftp://, etc.), as DHCP servers do not themselves distribute files. Note that it is acceptable for boot images to be fetched using an insecure protocol when having an embedded signature, as is commonly the case.
A device may attempt to read bootstrapping information from a trusted Internet based service. The hosted information would not have to be signed, as the device would authenticate the service when establishing a secure connection to it, using trust anchors the device is manufactured with in its factory default state.
This document defines a RESTCONF API for a bootstrap server that may be hosted on the Internet. The YANG module describing this API is provided in Section 6.4.
The information may again redirect the device to a bootstrap server (i.e., redirect information) or it may direct the device to load a boot image and a configuration (i.e., bootstrapping information). If bootstrapping information is provided, the URI to the boot image would not have to be to a server the device has a trust anchor for, assuming the boot image has an embedded signature, as is commonly the case.
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.
The following diagram illustrates key interactions that occur from when a manufacturer or delegate onboards a prospective device owner to when the manufacturer ships devices for an order placed by the prospective device owner.
+-----------+
+------------+ |Prospective| +---+
|Manufacturer| | Owner | |NMS|
+------------+ +-----------+ +---+
| | |
| | |
| 1. enroll me please | |
#<----------------------------| |
# | |
# account credentials and/or | |
# and/or owner certificate | |
#---------------------------->| |
| | |
| | |
| | |
| 2. get IDevID trust anchor | |
|<----------------------------# set IDevID trust anchor |
| #------------------------->|
| | |
| | |
| 3. place device order | |
|<----------------------------# model devices |
| #------------------------->|
| | |
| 4. 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| +---------+
+---+ |Bootstrap | | Redirect | | DHCP | |Removable|
|NMS| | Server | | Server | |Server| | Storage |
+---+ +----------+ +------------+ +------+ +---------+
| | | | |
activate | | | | |
modeled | | | | |
1. device | | | | |
----------->| | | | |
| | | | |
| 2. stage bootstrap | | |
| information | | |
|---------->| | | |
| | | | |
| 3. (optional) configure | | |
| redirect 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 example sequences the sources of information (see Section 3) based on locality, or how "close" to the device the data is. 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 | | Redirect | |Bootstrap | +---+
|Device| | Storage | |Server| | Server | | Server | |NMS|
+------+ +---------+ +------+ +------------+ +----------+ +---+
| | | | | |
| | | | | |
| 1. if not factory default, then exit. | | |
| | | | | |
| | | | | |
| 2. check | | | | |
#----------->| | | | |
# if signed redirect information found | | web- |
#------------------------------------------------------># hook |
# either NMS-initiated connection | #--------->#
#<-----------------------------------------------------------------#
# or device-initiated connection | | |
#----------------------------------------------------------------->|
# else if signed bootstrap information found (call home)| |
#----------------------------------------------------------------->|
| | | | | |
| | | | | |
| | | | | |
| 3. Get IP assignment | | | |
#------------------------>| | | |
# if signed redirect information found | web- |
#------------------------------------------------------># hook |
# either NMS-initiated connection | #--------->#
#<-----------------------------------------------------------------#
# or device-initiated connection | | |
#----------------------------------------------------------------->|
| | | | | |
| | | | | |
| | | | | |
| 4. check | | | | |
#-------------------------------------->| | |
# if signed or unsigned redirect information found | web- |
#------------------------------------------------------># hook |
# either NMS-initiated connection | #--------->#
#<-----------------------------------------------------------------#
# or device-initiated connection | | |
#----------------------------------------------------------------->|
| | | | | |
|
| 5. loop or wait for manual provisioning.
|
The interactions in the above diagram are described below.
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 public Internet Bootstrap Servers | | | | 2. list of trust anchor certs for Bootstrap Servers | | | | 3. trust anchor cert for owner certificates | | | | 4. trust anchor cert for device ownership vouchers | | | | 5. IDevID cert & associated intermediate certificate(s) | | | +----------------------------------------------------------+ | | | | +----------------------+ | | | <secure storage> | | | | | | | | 6. private key | | | +----------------------+ | | | +------------------------------------------------------------------+
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 information,
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.
When the source is a removable storage device, the device MUST be able to read from it signed data (see term) and validate that the data was signed by its rightful owner, using the algorithm in Section 5.3.
When the source is a DHCP server, the device MUST be able to read from it signed data (see term) and validate that the data was signed by its rightful owner, using the algorithm in Section 5.3.
When the source is a bootstrap server, that is, using the RESTCONF API presented in Section 6.4, the device MUST be able to authenticate the server using one of the the device's preconfigured trust anchors. Once done authenticating the bootstrap server, the device MUST attempt to fetch the bootstrapping data hosted for it there, using its unique identifier (e.g., serial number) as the key into the "device" list. If bootstrapping data is found and it is signed, then the device MUST first validate that the data was signed by its rightful owner using the algorithm in Section 5.3. The device then processes the bootstrapping data as described in Section 5.4. The device MAY post progress notification messages to the server, but SHOULD only do so if it has first authenticated itself to the server (e.g., client authentication).
If the device is ever 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.
The device MUST first authenticate the Ownership Voucher by validating the signature on it to one of its preconfigured trust anchors (see Section 5.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 5.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 bootstrapping data, the device MUST follow the steps presented in this section.
If the data is redirect-information (see Section 2.4), 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 DNS resolves it to more than one IP address, the device MUST attempt to try to connect to all of them, until it is able to successfully bootstrap off one of them. The device MUST authenticate the bootstrap server's TLS certificate using the X.509 certificate provided by the redirect information.
If the data is bootstrap-information (see Section 2.4), the device MUST first check if it contains any boot-image information and, if so, check to see if it differs from what the device is currently running and, if so, install the boot-image using the provided URI and reboot (Note, it is assumed that the boot-image contains an embedded signature that the installation step will verify). This will cause the device's bootstrap logic to restart, which will again come to this point, though with a matching boot-image, thus letting the device to proceed past this step. Next the device MUST process the configuration contained in the bootstrapping information, by merging it into its running configuration.
At this point, the device has completely processed the bootstrapping data and is "bootstrap complete". If the configuration configured the device it initiate a call home connection, it would proceed to do so now. Otherwise, the device would 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 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 address inet:host
| | +--ro trust-anchor binary
| | +--ro signature? string
| +--:(bootstrap-information)
| +--ro bootstrap-information
| +--ro boot-image
| | +--ro name string
| | +--ro md5 string
| | +--ro sha1 string
| | +--ro path string
| | +--ro signature? string
| +--ro configuration
| +--ro config
| +--ro signature? string
+--ro ownership-voucher
| +--ro voucher binary
| +--ro issuer-crl? string
+--ro owner-certificate
| +--ro certificate string
| +--ro issuer-crl? string
+---x notification
+---w input
+---w type enumeration
+---w message? string
+---w ssh-host-keys
+---w ssh-host-key*
+---w format enumeration
+---w key-data string
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.
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 well-known Internet facing redirect service might return.
REQUEST
-------
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
<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<device>
<unique-id>123456789</unique-id>
<redirect-information>
<address>phs.example.com</address>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RJSUJQFRStS0Cg==
</trust-anchor>
</redirect-information>
</device>
</devices>
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 service might return if concerned the device might not be able to authenticate its TLS certificate.
REQUEST
-------
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
<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<device>
<unique-id>123456789</unique-id>
<redirect-information>
<address>phs.example.com</address>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RJSUJQFRStS0Cg==
</trust-anchor>
<signature>
SomeSignatureString
</signature>
</redirect-information>
<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>
<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>
</device>
</devices>
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
-------
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
<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<device>
<unique-id>123456789</unique-id>
<bootstrap-information>
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<path>
/some/path/to/raw/file
</path>
</boot-image>
<configuration>
<config>
<!-- 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>
</config>
</configuration>
</bootstrap-information>
</device>
</devices>
The following example illustrates a device using the API to fetch its bootstrapping data. In this example, the device receives signed bootstrapping information. This example is representative of a response that bootstrap service might return if concerned the device might not be able to authenticate its TLS certificate.
REQUEST
-------
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
<devices xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<device>
<unique-id>123456789</unique-id>
<bootstrap-information>
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<path>
/some/path/to/raw/file
</path>
<signature>
SomeSignatureString
</signature>
</boot-image>
<configuration>
<config>
<!-- 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>
</config>
<signature>
SomeSignatureString
</signature>
</configuration>
</bootstrap-information>
<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>
<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>
</device>
</devices>
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 YANG module defines only one notification type, bootstrap-complete. Other notification types may be defined through YANG augmentation.
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 it can subsequently authenticate the device when establishing a NETCONF over SSH connection to it.
A device providing its SSH host key or TLS server certificate is not needed when the device has an IDevID certificate [Std-802.1AR-2009] and is able to present the IDevID certificate as its SSH host key or TLS server certificate, when establishing a NETCONF or RESTCONF connection.
REQUEST
-------
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
<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>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
</ssh-host-key>
<ssh-host-key>
<format>ssh-dsa</format>
<key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
</ssh-host-key>
</ssh-host-keys>
</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.
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.
<redirect-information xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<address>phs.example.com</address>
<trust-anchor>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RJSUJQFRStS0Cg==
</trust-anchor>
<signature>
SomeSignatureString
</signature>
</redirect-information>
The following example illustrates how bootstrapping data can be encoded into an artifact for use outside of the RESTCONF protocol. The bootstrapping information is signed so that it is secure when no transport-level security is provided.
<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>
<path>
/some/path/to/raw/file
</path>
<signature>
SomeSignatureString
</signature>
</boot-image>
<configuration>
<config>
<!-- 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>
</config>
<signature>
SomeSignatureString
</signature>
</configuration>
</bootstrap-information>
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. As the Owner Certificate and CRL are already signed by the manufacturer, an additional owner signature is unnecessary.
<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. As the Ownership Voucher and CRL are already signed by the manufacturer, an additional owner signature is unnecessary.
<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@2015-10-19.yang"
module ietf-zerotouch-bootstrap-server {
namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
prefix "ztbs";
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 "2015-10-19" {
description
"Initial version";
reference
"RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
}
grouping redirect-information-grouping {
description
"This container contains information the device may use
to redirect it to another bootstrap server.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the bootstrap server
the device should redirect to.";
}
leaf trust-anchor {
type binary;
mandatory true;
description
"A certificate that a device can use as a trust anchor to
authenticate the bootstrap server it is being redirected
to. The binary certificate structure as specified by RFC
5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
";
reference
"RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2";
}
leaf signature {
type string;
must "../../ownership-voucher";
description
"The signature over the concatenation of the previous leafs
using the organization's private key. Specifically,
sign(name+md5+sha1+path), where simple string concatenation
to join values is used, resulting in a single null-terminated
string.";
}
}
grouping bootstrap-information-grouping {
container boot-image {
description
"It is intended that the device will fetch this container
as a whole, as it contains values that need to be
processed together.";
leaf name {
type string;
mandatory true;
description
"The name of the image of software the device is expected
to be running.";
}
leaf md5 {
type string;
mandatory true;
description
"The output of the MD5 hash algorithm over the image file.";
}
leaf sha1 {
type string;
mandatory true;
description
"The output of the SHA-1 hash algorithm over the image file.";
}
leaf path {
type string;
mandatory true;
description
"An absolute path to the boot-image file hosted on this
Bootstrap server.";
}
leaf signature {
type string;
must "../../../ownership-voucher";
description
"The signature over the concatenation of the previous leafs
using the organization's private key. Specifically,
sign(name+md5+sha1+path), where simple string concatenation
to join values is used, resulting in a single null-terminated
string.";
}
}
container configuration {
description
"It is intended that the device will fetch this container
as a whole, as its contents need to be processed together.";
anyxml config {
mandatory true;
description
"Any configuration data model known to the device. It may
contain Vendor-specific and/or standards-based data models.
An example configuration using a couple IETF-defined data
models is presented the Appendix of RFC XXXX.";
}
leaf signature {
type string;
must "../../../ownership-voucher";
description
"The signature over the concatenation of the previous leaf
using the organization's private key. Specifically,
sign(config), where 'config' is treated as a single null-
terminated string.";
}
}
}
grouping owner-certificate-grouping {
leaf certificate {
type string;
mandatory true;
description
"This is an X.509 certificate, signed by a Vendor, for
a business organization. This certificate must encode a
Vendor-assigned value identifying the organization. This
identifier must match the owner identifier encoded in
the Ownership Voucher.";
}
leaf issuer-crl {
type string;
description
"An optional CRL for the issuer used by the
Vendor to sign Owner Certificates. The CRL should be
as up to date as possible. This leaf is optional as
it is primarily to support deployments where the device
is unable to download the CRL from the CRL distribution
point URLs listed in the Vendor's trust anchor
certificate.";
}
}
grouping ownership-voucher-grouping {
leaf voucher {
type binary;
mandatory true;
description
"A Vendor-specific encoding binding unique device
identifiers to an owner identifier value matching the
value encoded in the owner-certificate below. An
example format for a voucher is presented in the
Appendix of RFC XXXX.";
}
leaf issuer-crl {
type string;
description
"An optional CRL for the issuer used by the
Vendor to sign Ownership Vouchers. The CRL should be
as up to date as possible. This leaf is optional as
it is primarily to support deployments where the device
is unable to download the CRL from the CRL distribution
point URLs listed in the Vendor's trust anchor
certificate.";
}
}
container devices {
config false;
description
"A read-only list of device entries";
list device {
key unique-id;
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 {
container redirect-information {
uses redirect-information-grouping;
}
container bootstrap-information {
uses bootstrap-information-grouping;
}
}
container ownership-voucher {
description
"This container contains the Ownership Voucher that the
device uses to ascertain the identity of its rightful
owner, as certified by its Vendor.";
when "../redirect-information/signature or ../bootstrap-information/*/signature";
//must "../owner-certificate and ../redirect-information/signature or ../bootstrap-information/*/signature";
must "../owner-certificate";
uses ownership-voucher-grouping;
}
container owner-certificate {
description
"It is intended that the device will fetch this container
as a whole, as it contains values that need to be
processed together.";
when "../ownership-voucher";
//must "../ownership-voucher and ../redirect-information/signature or ../bootstrap-information/*/signature";
uses owner-certificate-grouping;
}
action notification {
input {
leaf type {
type enumeration {
enum bootstrap-complete {
description
"Indicates that the device successfully processed the
bootstrap data, that is currently running the specified
boot image and has committed the configuration. At
this point, the device is ready to be managed by an
external NMS system. The device is never expected
access the bootstrap server again, unless reset to
its factory default again.";
}
}
mandatory true;
}
leaf message {
type string;
description
"A human-readable value.";
}
container ssh-host-keys {
list ssh-host-key {
when "../type = bootstrap-complete";
leaf format {
type enumeration {
enum ssh-dss;
enum ssh-rsa;
}
mandatory true;
}
leaf key-data {
type string;
mandatory true;
}
}
}
}
} // end action
}
}
}
<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 for signed data includes validating Owner Certificates and Ownership Vouchers, each of which may contain expirations. Further, the solution includes using a CRLs, which also require freshness. Device implementations should take care to ensure the devices have a reliable clock when processing signed data.
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). Manufacturers SHOULD deploy Online Certificate State Protocol (OCSP) responders or CRL Distribution Points (CDP) to revoke certificates in case necessary.
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.
Editor Note: this section needs to be rewritten to use the redirect and bootstrap information types (see Section 2.4).
The following registrations are in accordance to RFC 2939 for "BOOTP Manufacturer Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
Tag: XXX
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server hostnames and/or IP addresses.
Code Len
+-----+-----+------+------+----
| XXX | n | svr1 | svr2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
Tag: YYY
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server hostnames and/or IP addresses.
Code Len
+-----+-----+------+------+----
| YYY | n | svr1 | svr2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): David Harrington, Dean Bogdanovic, Martin Bjorklund, Max Pritikin, Stephen Hanna, Wes Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, 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-ietf-netconf-call-home] | Watsen, K., "NETCONF Call Home (work in progress)", October 2014. |
| [draft-ietf-netconf-restconf] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ieft-netconf-restconf-04, 2014. |
| [draft-ietf-netconf-server-model] | Watsen, K., "NETCONF Server Model (work in progress)", September 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [Std-802.1AR-2009] | IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
| [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: ietf-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:
<CODE BEGINS> file "ietf-zerotouch-ownership-voucher@2015-10-19.yang"
module ietf-zerotouch-ownership-voucher {
namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher";
prefix "ztov";
import ietf-yang-types { prefix yang; }
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines the format for a ZeroTouch ownership voucher,
which is produced by Vendors, relayed by Bootstrap Servers, and
consumed by devices. The purpose of the voucher is to enable a
device to ascertain the identity of its rightful owner, as
certified by its Vendor.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision "2015-10-19" {
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";
}
}
}
<CODE ENDS>