idnits 2.17.1 draft-ietf-netconf-zerotouch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1323 has weird spacing: '...-anchor bin...' == Line 1338 has weird spacing: '...ificate bin...' == Line 1346 has weird spacing: '...on-type enu...' == Line 1351 has weird spacing: '...ey-data str...' == Line 1355 has weird spacing: '...ificate bin...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When redirect information is signed, then the device MUST establish a secure connection to the specified bootstrap server using X.509 certificate path validation ([RFC6125], Section 6) to the specified trust anchor, and MUST send its IDevID certificate in the form of a client certificate, and MUST POST notifications to the bootstrap server. Furthermore, in this case, any data obtained from the bootstrap server MAY NOT be signed, as it is already trusted by virtue of the secure connection. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If the device is able to authenticate the bootstrap server, using X.509 certificate path validation ([RFC6125], Section 6) to a trust anchor the device was manufactured with, or it securely learned from another source of bootstrapping data, then the data the device obtains from the bootstrap server MAY NOT be signed. 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 authenticate the bootstrap server's TLS certificate, the device MUST send its IDevID certificate in the form of client-certificate and it MUST POST notifications to the bootstrap server. -- The document date (March 16, 2016) is 2935 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Abrahamsson 5 Expires: September 17, 2016 T-Systems 6 March 16, 2016 8 Zero Touch Provisioning for NETCONF or RESTCONF based Management 9 draft-ietf-netconf-zerotouch-06 11 Abstract 13 This draft presents a secure technique for establishing a NETCONF or 14 RESTCONF connection between a newly deployed device, configured with 15 just its factory default settings, and its deployment specific 16 network management system (NMS). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 17, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 56 2. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 7 57 2.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 7 58 2.2. Conveying Trust . . . . . . . . . . . . . . . . . . . . . 7 59 2.3. Ownership . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Information Types . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. Redirect Information . . . . . . . . . . . . . . . . . . 9 62 3.2. Bootstrap Information . . . . . . . . . . . . . . . . . . 9 63 4. Sources for Bootstrapping Data . . . . . . . . . . . . . . . 10 64 4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 11 65 4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 14 68 5. Workflow Overview . . . . . . . . . . . . . . . . . . . . . . 14 69 5.1. Onboarding and Ordering Devices . . . . . . . . . . . . . 15 70 5.2. Owner Stages the Network for Bootstrap . . . . . . . . . 17 71 5.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 19 72 6. Device Details . . . . . . . . . . . . . . . . . . . . . . . 22 73 6.1. Factory Default State . . . . . . . . . . . . . . . . . . 23 74 6.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 24 75 6.3. Processing a Source of Boostrapping Data . . . . . . . . 25 76 6.4. Validating Signed Data . . . . . . . . . . . . . . . . . 26 77 6.5. Processing Redirect Information . . . . . . . . . . . . . 27 78 6.6. Processing Bootstrap Information . . . . . . . . . . . . 27 79 7. YANG-defined API and Artifacts . . . . . . . . . . . . . . . 28 80 7.1. Module Overview . . . . . . . . . . . . . . . . . . . . . 28 81 7.2. API Examples . . . . . . . . . . . . . . . . . . . . . . 30 82 7.2.1. Unsigned Redirect Information . . . . . . . . . . . . 30 83 7.2.2. Signed Redirect Information . . . . . . . . . . . . . 31 84 7.2.3. Unsigned Bootstrap Information . . . . . . . . . . . 34 85 7.2.4. Signed Bootstrap Information . . . . . . . . . . . . 36 86 7.2.5. Progress Notifications . . . . . . . . . . . . . . . 40 87 7.3. Artifact Examples . . . . . . . . . . . . . . . . . . . . 42 88 7.3.1. Signed Redirect Information . . . . . . . . . . . . . 42 89 7.3.2. Signed Bootstrap Information . . . . . . . . . . . . 44 90 7.3.3. Owner Certificate . . . . . . . . . . . . . . . . . . 45 91 7.3.4. Ownership Voucher . . . . . . . . . . . . . . . . . . 47 92 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 47 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 60 94 8.1. Immutable storage for trust anchors . . . . . . . . . . . 60 95 8.2. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 60 96 8.3. Blindly authenticating a bootstrap server . . . . . . . . 60 97 8.4. Entropy loss over time . . . . . . . . . . . . . . . . . 61 98 8.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 61 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 100 9.1. Zero Touch Redirect Information DHCP Options . . . . . . 61 101 9.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 61 102 9.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 62 103 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 62 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 63 107 12.2. Informative References . . . . . . . . . . . . . . . . . 64 108 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 66 109 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 66 110 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 68 111 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 68 112 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 69 113 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 69 114 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 69 115 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 69 116 B.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 70 117 B.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 70 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 120 1. Introduction 122 A fundamental business requirement for any network operator is to 123 reduce costs where possible. For network operators, deploying 124 devices to many locations can be a significant cost, as sending 125 trained specialists to each site to do installations is both cost 126 prohibitive and does not scale. 128 This document defines bootstrapping strategies enabling devices to 129 securely obtain bootstrapping data with no installer input, beyond 130 physical placement and connecting network and power cables. The 131 ultimate goal of this document is to enable a secure NETCONF 132 [RFC6241] or RESTCONF [draft-ietf-netconf-restconf] connection to the 133 deployment specific network management system (NMS). 135 1.1. Use Cases 137 o Connecting to a remotely administered network 139 This use-case involves scenarios, such as a remote branch 140 office or convenience store, whereby a device connects as an 141 access gateway to an ISP's network. Assuming it is not 142 possible to customize the ISP's network to provide any 143 bootstrapping support, and with no other nearby device to 144 leverage, the device has no recourse but to reach out to an 145 Internet-based bootstrap server to bootstrap off of. 147 o Connecting to a locally administered network 149 This use-case covers all other scenarios and differs only in 150 that the device may additionally leverage nearby devices, which 151 may direct it to use a local service to bootstrap off of. If 152 no such information is available, or the device is unable to 153 use the information provided, it can then reach out to network 154 just as it would for the remotely administered network use- 155 case. 157 1.2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 161 sections below are to be interpreted as described in RFC 2119 162 [RFC2119]. 164 This document uses the following terms: 166 Artifact: The term "artifact" is used throughout to represent the 167 encoded form of any of Bootstrap Information, Redirect 168 Information, Owner Certificate, and Ownership Voucher. The 169 Bootstrap Server defined in this document is purposed to provide 170 these artifacts, but they can also be provided by any other 171 mechanism (removable storage, DHCP server, etc.), secure or not, 172 so long as the principles for when the bootstrapping data needs 173 to be signed is enforced. 175 Bootstrapping Data: The term "bootstrapping data" is used throughout 176 this document to refer to the collection of data that a device 177 may obtain from any source of bootstrapping data, including a 178 removable storage device, a DHCP server, a DNS server, a Redirect 179 Server, and/or a Bootstrap Server. This data includes both 180 Redirect Information as well as Bootstrap Information. 182 Bootstrap Information: The term "bootstrap information" is used 183 herein to refer to bootstrapping data that is used to guide a 184 device to install a specific boot-image and commit a specific 185 configuration. This data is formally defined by the "bootstrap- 186 information" container in the YANG module defined in Section 7.4. 188 Bootstrap Server: The term "bootstrap server" is used within this 189 document to mean any RESTCONF server implementing the YANG module 190 defined in Section 7.4. 192 Device: The term "device" is used throughout this document to refer 193 to the network element that needs to be bootstrapped. The device 194 is the RESTCONF client to a Bootstrap Server (see above) and, at 195 the end of bootstrapping process, the device is the NETCONF or 196 RESTCONF server to a deployment-specific NMS. See Section 6 for 197 more information about devices. 199 Initial Secure Device Identifier (IDevID): The term "IDevID" is 200 defined in [Std-802.1AR-2009] as "the Secure Device Identifier 201 (DevID) installed on the device by the manufacturer". By 202 example, an IDevID certificate, signed by the manufacturer may 203 encode a manufacturer assigned unique identifier (e.g., serial 204 number) and a public key matching a private key held within a TPM 205 chip embedded within the device. 207 Network Management System (NMS): The acronym "NMS" is used 208 throughout this document to refer to the deployment specific 209 management system that the bootstrapping process is responsible 210 for introducing devices to. From a device's perspective, when 211 the bootstrapping process has completed, the NMS is a NETCONF or 212 RESTCONF client. 214 Owner: See Rightful Owner. 216 Owner Certificate: The term "owner certificate" is used in this 217 document to represent an X.509 certificate, signed by the 218 device's manufacturer or delegate, that binds an owner identity 219 to the owner's private key, which the owner can subsequently use 220 to sign artifacts. The owner certificate is used by devices only 221 when validating owner signatures on signed data. This data is 222 formally defined by the "owner-certificate" container in the YANG 223 module defined in Section 7.4. 225 Ownership Voucher: The term "ownership voucher" is used in this 226 document to represent manufacturer-specific artifact, signed by 227 the device's manufacturer or delegate, binding an owner identity 228 (same as in the Owner Certificate) to one or more device 229 identities (e.g., serial numbers). The ownership voucher is used 230 by devices only when validating owner signatures on signed data. 231 This data is formally defined by the "ownership-voucher" 232 container in the YANG module defined in Section 7.4. 234 Redirect Information: The term "redirect information" is used herein 235 to refer to bootstrapping data that redirects a device to connect 236 to another Bootstrap Server. This data is formally defined by 237 the "redirect-information" container in the YANG module defined 238 in Section 7.4. 240 Redirect Server: The term "redirect server" is used to refer to a 241 Bootstrap Server that only returns Redirect Information. A 242 Redirect Server is particularly useful when hosted by a 243 manufacturer, to redirect devices to a deployment-specific 244 bootstrap server. 246 Rightful Owner: The term "rightful owner" is used herein to refer to 247 the person or organization that purchased a device. Ownership is 248 conveyed by a chain of trust established by a sequence of 249 authenticated secure connections and/or Signed Data, as described 250 in Section 2.3. 252 Signed Data: The term "signed data" is used throughout to mean 253 either Redirect Information or Bootstrap Information that has 254 been signed by a device's Rightful Owner's private key. These 255 artifacts MUST be signed whenever communicated using an unsecured 256 mechanism. Any time data is signed, it MUST be presented along 257 with an Owner Certificate and Ownership Voucher, which themselves 258 do not need to be signed by the Rightful Owner's private key, as 259 they already are signed by the manufacturer. 261 Unsigned Data: The term "unsigned data" is used throughout to mean 262 either Redirect Information or Bootstrap Information that has not 263 been signed by a device's Rightful Owner's private key. The 264 option to use unsigned data MUST only be available only when the 265 data is obtained over an authenticated secure connection, such as 266 to a Bootstrap Server. 268 1.3. Tree Diagrams 270 A simplified graphical representation of the data models is used in 271 this document. The meaning of the symbols in these diagrams is as 272 follows: 274 o Brackets "[" and "]" enclose list keys. 276 o Braces "{" and "}" enclose feature names, and indicate that the 277 named feature must be present for the subtree to be present. 279 o Abbreviations before data node names: "rw" (read-write) represents 280 configuration data and "ro" (read-only) represents state data. 282 o Symbols after data node names: "?" means an optional node, "!" 283 means a presence container, and "*" denotes a list and leaf-list. 285 o Parentheses enclose choice and case nodes, and case nodes are also 286 marked with a colon (":"). 288 o Ellipsis ("...") stands for contents of subtrees that are not 289 shown. 291 2. Guiding Principles 293 This section provides overarching principles guiding the solution 294 presented in this document. 296 2.1. Trust Anchors 298 A trust anchor is used in cryptography to represent an entity in 299 which trust is implicit and not derived. In public key 300 infrastructure using X.509 certificates, a root certificate is the 301 trust anchor from which the chain of trust is derived. The solution 302 presented in this document requires that all the entities involved 303 possess specific trust anchors in order to ensure mutual 304 authentication throughout the zero touch bootstrapping process. 306 2.2. Conveying Trust 308 A device in its factory default state possesses a limited set of 309 manufacturer specified trust anchors. In this document, there are 310 two types of trust anchors of interest. The first type of trust 311 anchor is used to authenticate a secure connection to, for instance, 312 a manufacturer-hosted Internet-based bootstrap server. The second 313 type of trust anchor is used to authenticate manufacturer-signed 314 data, such as the owner certificate and ownership voucher described 315 in this document. 317 In the first case, trust is conveyed by the device first 318 authenticating the secure connection to the server and then by the 319 device trusting that the server would only provide data that its 320 rightful owner staged for it to find. For instance, the staged data 321 may be redirect information that includes the IP address and another 322 trust anchor certificate for the deployment-specific bootstrap 323 server. The device can then use the discovered trust anchor to 324 authenticate a secure connection to the deployment-specific bootstrap 325 server. 327 In the second case, trust is conveyed by the device first 328 authenticating the owner certificate and ownership voucher and then, 329 using the public key in the owner certificate, authenticate a signed 330 artifact, such as redirect information. And again the device can use 331 the discovered trust anchor to authenticate a secure connection to 332 the deployment-specific bootstrap server. 334 2.3. Ownership 336 The goal of this document is to enable a device to connect with its 337 rightful owner's NMS. This entails the manufacturer being able to 338 track who owns which devices (out of the scope of this document), as 339 well as an ability to convey that information to devices (in scope). 340 Matching the two ways to convey trust, this document provides both a 341 protocol oriented solution as well as an artifact based solution for 342 conveying ownership. 344 The protocol based solution conveys ownership by the device first 345 authenticating a secure connection to a bootstrap server and then 346 trusting that the server would only provide data that its rightful 347 owner staged for it to find. In the case of a manufacturer-hosted 348 bootstrap server, the manufacturer takes the onus of ensuring that 349 only data configured by the device's rightful owner is made available 350 to the device. With this approach, the assignment of a device to an 351 owner is ephemeral, with the manufacturer being able is reassign the 352 device at any time. 354 The artifact based solution, which is ideal for when a secure 355 connection cannot be established (e.g., loading data off a removable 356 storage device), involves the manufacturer signing an owner 357 certificate and then later, when the ownership for devices is 358 established, the manufacturer signing a voucher that assigns those 359 devices to the owner, and then the owner using their private key to 360 sign the artifacts. Thus, from the device's perspective, it can use 361 the presented ownership voucher to validate the presented owner 362 certificate, which it can then use to validate the signature over the 363 presented artifact. With this approach, the assignment of a device 364 to an owner is somewhat permanent, as the ability for the 365 manufacturer to reliably distribute CRLs to revoke assignments not 366 possible when the devices do not contain a real time clock (see 367 Section 8 for information about this). 369 3. Information Types 371 This document presumes there exists two types of zero touch 372 information: redirect information and bootstrap information. 374 Both information types MAY be signed or unsigned, though in some 375 contexts, as described below, the bootstrap information type MUST be 376 signed, as there is not otherwise possible for a device to process 377 it, even in a degraded manner. 379 Both information types MAY be encoded using various technologies. 380 This document only tries to support the encodings supported by 381 RESTCONF, namely XML and JSON, while leaving extensibility mechanisms 382 in place to support future extensions. 384 3.1. Redirect Information 386 Redirect information provides a list of bootstrap servers, where each 387 list entry includes the bootstrap server's hostname or IP address, an 388 optional port, and an optional trust anchor certificate. The 389 redirect information type is formally defined by the "redirect- 390 information" grouping defined in Section 7.4. 392 As its name suggests, redirect information guides the device to 393 attempt to connect to the specified bootstrap servers, until finding 394 one that it can bootstrap itself off of. Redirect information is 395 primarily distinguished from standard HTTP redirect by its optional 396 inclusion of trust anchors, in which case it may be referred to as a 397 "secure redirect". 399 Redirect information may be signed or unsigned. If the redirect 400 information is not signed, then the device MUST NOT trust any 401 included trust anchor certificates, equivalent to had they not been 402 specified at all. 404 When redirect information is signed, then the device MUST establish a 405 secure connection to the specified bootstrap server using X.509 406 certificate path validation ([RFC6125], Section 6) to the specified 407 trust anchor, and MUST send its IDevID certificate in the form of a 408 client certificate, and MUST POST notifications to the bootstrap 409 server. Furthermore, in this case, any data obtained from the 410 bootstrap server MAY NOT be signed, as it is already trusted by 411 virtue of the secure connection. 413 When redirect information is unsigned, or doesn't specify a trust 414 anchor certificate, and the device connects to the bootstrap server 415 by blindly accepting the bootstrap server's TLS certificate, the 416 device MUST NOT send its IDevID certificate in the form of a client 417 certificate, and MUST NOT POST notifications to the bootstrap server. 418 Furthermore, the device MUST assert that any data obtained from the 419 bootstrap server is signed, much as it would assert bootstrap 420 information loaded from a removable storage device is signed. 422 3.2. Bootstrap Information 424 Bootstrap information provides all the data neccessary for the device 425 to bootstrap itself, in order to be considered ready to be managed. 426 This data includes criteria about the boot image the device MUST be 427 running, an initial configuration the device MUST commit, and an 428 optional script that, if specified, the device MUST successfully 429 execute. Descriptions for these follow: 431 o The boot image creteria is used to ensure the device is running a 432 version of software that will be able to understand the 433 configuration and script, if any. The criteria is flexible in 434 that it allows for both an absolute specification of the boot 435 image a device MUST be running, or just a list of YANG modules 436 that the device MUST be able to understand. 438 o The configuration can configure any aspect of the device but, in 439 order to fulfill the goal of the zero touch bootstrapping process, 440 to establish a NETCONF or RESTCONF connection to the device's 441 deployment specific NMS, the configuration MUST minimally 442 configure an administrator account (e.g., username, SSH public 443 key) that the NMS can use to log into the device with, and 444 configure the device to either listen for inbound NETCONF/RESTCONF 445 connections, or for the device to initiate an outbound NETCONF/ 446 RESTCONF call home connection [draft-ietf-netconf-call-home]. The 447 bootstrap information examples provided in Section 7.2.3, 448 Section 7.2.4, and Section 7.3.2 all illustrate a minimal initial 449 configuration. 451 o The script, if any, is used to perform non-configuration related 452 activities deemed necessary. The script format is manufacturer 453 specific. Requirements for scripts, such as exit status codes, 454 are defined in the "script" node's description statement provided 455 in the YANG module defined in Section 7.4. 457 Bootstrap information may be signed or unsigned. If the device is 458 accessing the bootstrap server in an unsecured manner (e.g., from a 459 removable storage device or from an untrusted server), then the 460 bootstrap information MUST be signed, otherwise it MAY be signed. 462 Devices MUST process bootstrap information as is specified in 463 Section 6.6. 465 The bootstrap information type is formally defined by the "bootstrap- 466 information" grouping defined in Section 7.4. 468 4. Sources for Bootstrapping Data 470 Following are the sources of bootstrapping data that are referenced 471 by the workflows presented in Section 5.3. Other sources of 472 bootstrapping data may be defined in future documents, so long as the 473 principles for when the bootstrapping data needs to be signed are 474 enforced. 476 Each of the descriptions below show how the bootstrapping data needs 477 to be handled in a manner consistent with the guiding principles in 478 Section 2. 480 For devices supporting more than one source for bootstrapping data, 481 no particular sequencing order has to be observed, as each source is 482 equally secure, in that the chain of trust always goes back to the 483 same root of trust, the manufacturer. That said, from a privacy 484 perspective, it is RECOMMENDED that a device try to leverage local 485 sources before remote source. For this reason, all the examples used 486 in this document assume a removable storage device is accessed before 487 a DHCP server, which itself is accessed before an Internet-based 488 bootstrap server. 490 4.1. Removable Storage 492 A device MAY attempt to acquire bootstrapping data from a directly 493 attached removable storage device. The bootstrapping data MAY be 494 either redirect information or bootstrap information. 496 If redirect information is provided, it SHOULD be signed, as 497 removable storage devices are not trustworthy. However, if the 498 redirect information is not signed, then the device MUST NOT trust 499 any included trust anchor certificates, which means that the device 500 would have to establish an unsecured connection to the specified 501 bootstrap servers. See Section 3.1 for more about this case. 503 If bootstrap information is provided, it MUST be signed, as removable 504 storage devices are not trustworthy and there is no option to process 505 the data in a degraded manner, unlike as with redirect information. 507 For the case when the signed bootstrap information is provided, it is 508 notable that even the raw boot image file itself can be on the 509 removable storage device, by letting the URL reference a local file 510 (e.g., file:///path/to/file), making use of the removable storage 511 device a fully self-standing bootstrapping solution. 513 However, regardless if the boot image file resides on the local 514 storage device or if the device must follow the URL to download it 515 from a remote (and unsecured) server, the device MUST authenticate 516 the validity of the boot image file, either by using the MD5 and SHA 517 fingerprints supplied by the bootstrapping information, or by virtual 518 of the boot image containing an embedded signature, if any. 520 4.2. DNS Server 522 A device MAY attempt to acquire bootstrapping data from a DNS server 523 using DNS-based service discovery (DNS-SD) [RFC6763]. Due to DNS 524 packet size limitations the bootstrapping data provided using DNS-SD 525 can only be redirect information, no support for bootstrap 526 information using DNS-SD is provided by this document. 528 The redirect information provided SHOULD be signed, as this document 529 does not define a solution to secure the DNS records using DNSSEC 530 [RFC6698]. However, if the redirect information is not signed, then 531 the device MUST NOT trust any included trust anchor certificates, 532 which means that the device would have to establish an unsecured 533 connection to the specified bootstrap servers. See Section 3.1 for 534 more about this case. 536 To use this approach, the device MAY perform DNS-SD via multicast DNS 537 [RFC6762] searching for the service "_zerotouch._tcp.local.". 538 Alternatively the device MAY perform DNS-SD via normal DNS operation, 539 using the domain returned to it from the DHCP server, searching for 540 the service "_zerotouch._tcp.example.com". 542 The mapping of redirect information onto DNS SRV [RFC2782] and DNS 543 TXT [RFC1035] records as follows: is as follows: 545 o The bootstrap server's hostname or IP address is returned by the 546 "Target" component of the DNS SRV record. 548 o The bootstrap server's port is returned by the "Port" component of 549 the DNS SRV record. 551 o The bootstrap server's trust anchor is returned using the key 552 "anchor" in the DNS TXT record with the binary value being the 553 `gzip` compression over the redirect-information's "trust-anchor" 554 value. To save additional space, it is RECOMMENDED that the trust 555 anchor certificate uses an elliptical curve algorithm, rather than 556 the seemingly ubiquitous RSA algorithm. 558 o The signature over the preceding three values is returned using 559 the key "sig" in the DNS TXT record with the binary value being 560 the `gzip` compression over the redirect-information's "signature" 561 value. 563 o The owner certificate is returned using the key "cert" in the DNS 564 TXT record with the binary value being the `gzip` compression over 565 the redirect-information's "owner-certificate/certificate" value. 566 There isn't enough space to support returning CRLs. To save 567 additional space, it is RECOMMENDED that the owner certificate 568 uses an elliptical curve algorithm, rather than the seemingly 569 ubiquitous RSA algorithm. 571 o The ownership voucher is returned using the key "voucher" in the 572 DNS TXT record binary value being the `gzip` compression over the 573 redirect-information's "ownership-voucher/voucher" value. There 574 isn't enough space to support returning CRLs. 576 The applicability of this approach across vendors is limited due to 577 the ownership voucher being a manufacturer-specific format. This 578 limitation only impacts signed data, when the ownership voucher is 579 used; there is no such limitation when unsigned data is communicated. 581 4.3. DHCP Server 583 A device MAY attempt to acquire bootstrapping data from a DHCP server 584 (e.g., using one of the DHCP options defined in Section 9.1). The 585 bootstrapping data MAY be either redirect information or bootstrap 586 information. 588 If redirect information is provided, it SHOULD be signed, as the DHCP 589 protocol is not a secure protocol. However, if the redirect 590 information is not signed, then the device MUST NOT trust any 591 included trust anchor certificates, which means that the device would 592 have to establish an unsecured connection to the specified bootstrap 593 servers. See Section 3.1 for more about this case. 595 If bootstrap information is provided, it MUST be signed, as the DHCP 596 protocol is not a secure protocol and there is no option to process 597 the data in a degraded manner, unlike as with redirect information. 599 For the case when the signed bootstrap information is provided, it is 600 notable that the URL would have to point to another file server 601 (e.g., http://, ftp://, etc.), as DHCP servers do not themselves 602 distribute files. In this case, the device MUST authenticate the 603 validity of the boot image file, either by using the MD5 and SHA 604 fingerprints supplied by the bootstrapping information, or by virtual 605 of the boot image containing an embedded signature, if any. 607 It is expected that DHCP servers will provide redirect information 608 more often than bootstrap information, since redirect information is 609 more generic, potentially applicable to a large number of devices, 610 with the number limited only by the number of devices listed by the 611 associated ownership voucher. Still, because the ownership voucher 612 is a manufacturer specific format, it is advisable for devices to 613 send the Vendor Class Identifier (option 60) field in its DHCP lease 614 request, so that the DHCP server doesn't accidentally hand it another 615 manufacturer's voucher format. 617 If it is desired for the DHCP server to return bootstrap information, 618 care should be taken to ensure that bootstrap information is 619 applicable to all the devices that might connect to the DHCP server. 620 The device SHOULD again pass the Vendor Class Identifier (option 60) 621 field in its DHCP lease request. However, if it is desired to return 622 device-specific bootstrap information, then the device SHOULD also 623 send the Client Identifier (option 61) field in its DHCP lease 624 request so that the DHCP server can select the specific bootstrap 625 information that has been staged for that one device. 627 4.4. Bootstrap Server 629 A device MAY attempt to acquire bootstrapping data from a trusted 630 Internet-based bootstrap server, a server implementing the RESTCONF 631 API defined by the YANG module provided in Section 7.4. The 632 bootstrapping data provided by the server MAY be either redirect 633 information or bootstrap information. 635 Actually, a bootstrap server is not only a source for bootstrapping 636 data, but it is also the consumer of notification messages from 637 devices. These notification messages both enable visability into the 638 bootstrapping process (e.g., reporting warnings and errors) and well 639 as provide potentially useful completion status information (e.g., 640 the device's SSH host-keys). 642 If the device is able to authenticate the bootstrap server, using 643 X.509 certificate path validation ([RFC6125], Section 6) to a trust 644 anchor the device was manufactured with, or it securely learned from 645 another source of bootstrapping data, then the data the device 646 obtains from the bootstrap server MAY NOT be signed. Notably, this 647 is the only mechanism defined in this document whereby unsigned 648 bootstrap information (not redirect information) can be used. When 649 the device is able to authenticate the bootstrap server's TLS 650 certificate, the device MUST send its IDevID certificate in the form 651 of client-certificate and it MUST POST notifications to the bootstrap 652 server. 654 If the device is unable to authenticate the bootstrap server's TLS 655 certificate, for any reason, then any data it receives from the 656 bootstrap server MUST be signed in order for the device to be able to 657 make use of it. When the device is not able to authenticate the 658 bootstrap server, the device MUST NOT send its IDevID in the form of 659 a client-certificate and it MUST NOT POST any notifications to the 660 bootstrap server. 662 5. Workflow Overview 664 The zero touch solution presented in this document is conceptualized 665 to be composed of the workflows described in this section. 666 Implementations MAY vary in details. Each diagram is followed by a 667 detailed description of the steps presented in the diagram, with 668 further explanation on how implementations may vary. 670 5.1. Onboarding and Ordering Devices 672 The following diagram illustrates key interactions that occur from 673 when a prospective owner enrolls in a manufacturer's zero touch 674 program to when the manufacturer ships devices for an order placed by 675 the prospective owner. 677 +-----------+ 678 +------------+ |Prospective| +---+ 679 |Manufacturer| | Owner | |NMS| 680 +------------+ +-----------+ +---+ 681 | | | 682 | | | 683 | 1. initiate enrollment | | 684 #<-----------------------------| | 685 # | | 686 # | | 687 # IDevID trust anchor | | 688 #-----------------------------># set IDevID trust anchor | 689 # #--------------------------->| 690 # | | 691 # (optional) bootstrap server | | 692 # account credentials | | 693 #-----------------------------># (optional) set credentials | 694 # #--------------------------->| 695 # | | 696 # | | 697 # (optional) owner certificate | | 698 #-----------------------------># (optional) set certificate | 699 | #--------------------------->| 700 | | | 701 | | | 702 | 2. place device order | | 703 |<-----------------------------# model devices | 704 | #--------------------------->| 705 | | | 706 | 3. ship devices and send | | 707 | device identifiers and | | 708 | ownership vouchers | | 709 |-----------------------------># set device identifiers | 710 | # and ownership vouchers | 711 | #--------------------------->| 712 | | | 713 | | | 715 The interactions in the above diagram are described below. 717 1. A prospective owner of a manufacturer's devices, or an existing 718 owner that wishes to start using zero touch for future device 719 orders, would initiate an enrollment process with the 720 manufacturer, or the manufacturer's delegate. 722 2. 724 Regardless how the prospective owner intends to bootstrap 725 their devices, they will always obtain from the manufacturer 726 or delegate the trust anchor certificate needed to 727 authenticate device IDevID certificates. This certificate 728 will need to be installed on the prospective owner's NMS so 729 that the NMS can subsequently authenticate the device's IDevID 730 certificates. 732 If the manufacturer hosts an Internet based bootstrap server, 733 such as described in Section 4.4, then credentials necessary 734 to configure the bootstrap server would be provided to the 735 prospective owner. If the bootstrap server is configurable 736 through an API (outside the scope of this document), then the 737 credentials might be installed on the prospective owner's NMS 738 so that the NMS can subsequently configure the manufacturer- 739 hosted bootstrap server directly. 741 If the manufacturer's devices are able to acquire 742 bootstrapping data from sources other than a manufacturer- 743 hosted Internet-based bootstrap server (e.g., removable 744 storage, DHCP server, etc.), then the manufacturer would 745 additionally provide an owner certificate to the prospective 746 owner. How the owner certificate is used to enable devices to 747 validate signed bootstrapping data is described in 748 Section 6.4. Not depicted, the owner certificate is generated 749 by the prospective owner previously sending a certificate 750 signing request to the manufacturer for signing, thus 751 resulting in the owner certificate. Assuming the prospective 752 owner's NMS is able to prepare and sign the bootstrapping 753 data, the owner certificate would be installed on the NMS at 754 this time. 756 3. Some time later, the prospective owner places an order with the 757 manufacturer, perhaps with a special flag checked for zero touch 758 handling. At this time, or perhaps before placing the order, the 759 owner may model the devices in their NMS. That is, create 760 virtual objects for the devices with no real-world device 761 associations. For instance the model can be used to simulate the 762 device's location in the network and the configuration it should 763 have when fully operational. 765 4. When the manufacturer ships the devices for the order, the 766 manufacturer notifies the owner of the devices' unique 767 identifiers and shipping destinations, which the owner can use to 768 stage the network for when the devices powers on. Additionally, 769 the manufacturer may send an ownership voucher, assigning 770 ownership of those devices to the rightful owner. The owner sets 771 this information on their NMS, perhaps binding specific device 772 identifiers and ownership vouchers (if supported) to specific 773 modeled devices. 775 5.2. Owner Stages the Network for Bootstrap 777 The following diagram illustrates how an owner stages the network for 778 bootstrapping devices. 780 +----------+ +------------+ 781 |Deployment| |Manufacturer| +------+ +------+ 782 | Specific | | Hosted | |Local?| | Local| +---------+ 783 +---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| 784 |NMS| | Server | | Server | |Server| |Server| | Storage | 785 +---+ +----------+ +------------+ +------+ +------+ +---------+ 786 | | | | | | 787 activate | | | | | | 788 modeled | | | | | | 789 1. device | | | | | | 790 ----------->| | | | | | 791 | | | | | | 792 | 2. (optional) configure | | | 793 | bootstrap server | | | | 794 |------->| | | | | 795 | | | | | | 796 | 3. (optional) configure | | | 797 | redirect server | | | | 798 |--------------------->| | | | 799 | | | | | | 800 | | | | | | 801 | 4. (optional) configure DNS server| | | 802 |---------------------------------->| | | 803 | | | | | | 804 | | | | | | 805 | 4. (optional) configure DHCP server | | 806 |------------------------------------------->| | 807 | | | | | | 808 | | | | | | 809 | 5. (optional) store bootstrapping artifacts on media | 810 |----------------------------------------------------->| 811 | | | | | | 812 | | | | | | 814 The interactions in the above diagram are described below. 816 1. Having previously modeled the devices, including setting their 817 fully operational configurations, associating device identifiers 818 and ownership vouchers (if supported), the owner "activates" one 819 or more modeled devices. That is, tell the NMS to perform the 820 steps necessary to prepare for when the real-world devices are 821 powered up and initiate the bootstrapping process. Note that, in 822 some deployments, this step might be combined with the last step 823 from the previous workflow. Here it is depicted that an NMS 824 performs the steps, but they may be performed manually or through 825 some other mechanism. 827 2. If it is desired to use a deployment specific bootstrap server, 828 it MUST be configured to provide the bootstrapping information 829 for the specific devices. Whenever a deployment specific 830 bootstrap server is used, the NMS MUST also configure some other 831 source of bootstrapping data (i.e. an Internet based redirect 832 server, a local DHCP server, a removable storage device, etc.) 833 with redirect information, so that the device can discover where 834 the deployment specific server is located and how to establish a 835 connection to it. Configuring the bootstrap server MAY occur via 836 a programmatic API not defined by this document. Illustrated 837 here as an external component, the bootstrap server MAY be 838 implemented as an internal component of the NMS itself. 840 3. If it is desired to use a manufacturer or delegate hosted 841 bootstrap server, it MUST be configured to provide the 842 bootstrapping information for the specific devices. The 843 configuration MUST be either redirect or bootstrap information. 844 That is, either the manufacturer hosted bootstrap server will 845 redirect the device to another bootstrap server, or provide the 846 device with its bootstrapping information itself. The types of 847 bootstrapping information the manufacturer hosted bootstrap 848 server supports MAY vary by implementation; some implementations 849 may only support redirect information, or only support bootstrap 850 information, or support both redirect and bootstrap information. 851 Configuring the bootstrap server MAY occur via a programmatic API 852 not defined by this document. 854 4. If it is desired to use a DNS server to supply bootstrapping 855 information, a DNS server needs to be configured. If multicast 856 DNS-SD is desired, then the server MUST reside on the local 857 network, otherwise the MAY reside on a remote network. Please 858 see Section 4.2 for more information about how to configure DNS 859 servers. Configuring the DHCP server MAY occur via a 860 programmatic API not defined by this document. 862 5. If it is desired to use a DHCP server to supply bootstrapping 863 data, the DHCP server MUST be accessible via the network the 864 device is located, either direct or via a DHCP relay. Please see 865 Section 4.3 for more information about how to configure DHCP 866 servers. Configuring the DHCP server MAY occur via a 867 programmatic API not defined by this document. 869 6. If it is desired to use a removable storage device (e.g., USB 870 flash drive) to supply bootstrapping information, the information 871 would need to be placed onto it. Please see Section 4.1 for more 872 information about how to configure a removable storage device. 874 5.3. Device Powers On 876 The following diagram illustrates how a device might behave when 877 powered on. Note that this is merely exemplary, subject to which 878 bootstrapping strategies the device supports, which may be more or 879 less than depicted below. 881 This diagram sequences the sources of bootstrapping information (see 882 Section 4) based on locality, or how "close" the data is to the 883 device, which is RECOMMENDED. Whether this sequence makes sense for 884 a specific type of device needs to be determined by the manufacturer. 886 +------------+ +----------+ 887 +------+ |Manufacturer| |Deployment| 888 +---------+ | Local| | Hosted | | Specific | 889 +------+ |Removable| | DHCP | | Bootstrap | |Bootstrap | +---+ 890 |Device| | Storage | |Server| | Server | | Server | |NMS| 891 +------+ +---------+ +------+ +------------+ +----------+ +---+ 892 | | | | | | 893 | | | | | | 894 | 1. if not factory default, then exit. | | | 895 | | | | | | 896 | | | | | | 897 | 2. (optional) check | | | | 898 #----------->| | | | | 899 # if signed redirect information found | | | 900 #------------------------------------------------------># webhook | 901 # either NMS-initiated NC or RC connection #---------># 902 #<-----------------------------------------------------------------# 903 # or device-initiated NC or RC call home connection | | 904 #----------------------------------------------------------------->| 905 # else if signed bootstrap information found (call home)| | 906 #----------------------------------------------------------------->| 907 # if bootstrapped then exit, else move to next step. | | 908 | | | | | | 909 | | | | | | 910 | 3. (optional) check | | | | 911 #------------------------>| | | | 912 # if signed redirect information found | | | 913 #------------------------------------------------------># webhook | 914 # either NMS-initiated NC or RC connection #---------># 915 #<-----------------------------------------------------------------# 916 # or device-initiated NC or RC call home connection | | 917 #----------------------------------------------------------------->| 918 # else if signed bootstrap information found (call home)| | 919 #----------------------------------------------------------------->| 920 # if bootstrapped then exit, else move to next step. | | 921 | | | | | | 922 | | | | | | 923 | 4. (optional) check | | | | 924 #-------------------------------------->| | | 925 # if signed or unsigned redirect information found | | 926 #------------------------------------------------------># webhook | 927 # either NMS-initiated NC or RC connection #---------># 928 #<-----------------------------------------------------------------# 929 # or device-initiated NC or RC call home connection | | 930 #----------------------------------------------------------------->| 931 # else if signed or unsigned bootstrap info found (call home) | 932 #----------------------------------------------------------------->| 933 # if bootstrapped then exit, else move to next step. | | 934 | | | | | | 935 | 936 | 5. loop and/or wait for manual provisioning. 937 | 939 [Key: NC==NETCONF, RC==RESTCONF] 941 The interactions in the above diagram are described below. 943 1. Upon power being applied, the device's bootstrapping logic first 944 checks to see if it is running in its factory default state. If 945 it has a modified state, then the bootstrapping logic would exit 946 and none to the following interactions would occur. 948 2. If the device is able to load bootstrapping data from a removable 949 storage device (e.g., USB flash drive), it is RECOMMENDED that it 950 try to do so first. Details such as the format of filesystem and 951 the naming of the files are left to the device's manufacturer to 952 define. Assuming a removable storage device is attached to the 953 device, the device would check for bootstrapping data and, if 954 found, validate that it has been signed using the procedure 955 described in Section 6.4. The bootstrapping data MAY either be 956 redirect information or bootstrap information. How the device 957 processes each is follows: 959 * In the case that redirect information is found (e.g., the 960 example depicted in Section 7.3.1), the device would use the 961 redirect information to establish a secure connection to a 962 deployment-specific bootstrap server. In theory this 963 bootstrap server could return a response that redirected the 964 device to yet another bootstrap server (e.g., the example 965 depicted in Section 7.2.1), but in this example it is depicted 966 that it returns bootstrap information (e.g., the example 967 depicted in Section 7.2.3). Using this bootstrap information, 968 the device would set its boot image and its initial 969 configuration. If the bootstrap server supports notifying 970 external systems (e.g., via a webhook) when a device has 971 notified the bootstrap server that it is ready to be managed 972 (e.g., the example depicted in Section 7.2.5), it might do so 973 at this time, which could prompt the NMS to initiate a NETCONF 974 or RESTCONF connection to the device at this time. 975 Alternatively, the initial configuration the device installs 976 could configure the device to initiate a NETCONF or RESTCONF 977 call home [draft-ietf-netconf-call-home] connection to the 978 deployment-specific NMS. All of these sub-steps are depicted 979 in the diagram above. 981 * In the case that bootstrap information is found (e.g., the 982 example depicted in Section 7.2.2), the device would use the 983 bootstrap information to install a boot image, which itself 984 could be located on the same removable storage device, and set 985 its initial configuration. In this case, since there is no 986 easy way to notify the NMS that the device is ready to be 987 managed (e.g., via a webhook), it is RECOMMENDED that the 988 initial configuration directs the device to proactively 989 initiate a NETCONF or RESTCONF call home 990 [draft-ietf-netconf-call-home] connection to the deployment- 991 specific NMS. 993 If the device is unable to bootstrap using any of the information 994 on the removable storage device, it would proceed to the next 995 source of bootstrapping information, if any. 997 3. If the device is able to load bootstrapping data from a DHCP 998 server, when obtaining a DHCP assignment, it may receive a 999 response that includes a Zero Touch Information DHCP option 1000 (Section 9.1). 1002 * If the redirect information contained in the DHCP option is 1003 signed, then it is RECOMMENDED that the device establish a 1004 secure TLS connection to the bootstrap server, by 1005 authenticating its TLS server certificate using the provided 1006 trust anchor, and download any data that has been staged for 1007 it there, which MAY not be signed, since the server's 1008 certificate could be trusted. 1010 * On the other hand, if the redirect information contained in 1011 the DHCP option is unsigned, then it is RECOMMENDED that the 1012 device establish a unsecured TLS connection to the bootstrap 1013 server, by blindly accepting its TLS server certificate, and 1014 download any data that has been staged for it there, which 1015 then MUST be signed, since the server's certificate could not 1016 be trusted. 1018 In either case, the remainder of the device's logic is the same 1019 as described above for when using a removable storage device. If 1020 the device is unable to bootstrap using information provided by a 1021 DHCP server, it would proceed to the next source of bootstrapping 1022 information, if any. 1024 4. If the device is able to load bootstrapping data from a trusted 1025 Internet-based bootstrap server, as preconfigured in its factory 1026 default settings (Section 6.1), it is RECOMMENDED that the device 1027 attempts to establish a secure TLS connection to the bootstrap 1028 server, authenticating its TLS server certificate using the trust 1029 anchors set by its factory default state (Section 6.1), and 1030 download any data that has been staged for it there, which MAY 1031 not be signed, since the server's certificate could be trusted. 1032 In either case, the remainder of the device's logic is the same 1033 as described above for when using a removable storage device. If 1034 the device is unable to bootstrap using information provided by a 1035 DHCP server, it would proceed to the next source of bootstrapping 1036 information, if any. 1038 5. If no more sources of bootstrapping information are available, 1039 the device MAY retry again all sources of bootstrapping data and/ 1040 or MAY provide manageability interfaces for manual configuration 1041 (e.g., CLI, HTTP, NETCONF, etc.). If manual configuration is 1042 allowed, and such configuration is provided, the device MUST 1043 immediately cease trying to obtain bootstrapping data, as it 1044 would then no longer be in its factory default state. 1046 6. Device Details 1048 Devices supporting Zero Touch MUST have the preconfigured factory 1049 default state and bootstrapping logic described in the following 1050 sections. 1052 6.1. Factory Default State 1054 +------------------------------------------------------------------+ 1055 | | 1056 | | 1057 | +----------------------------------------------------------+ | 1058 | | | | 1059 | | | | 1060 | | 1. list of trusted Internet based bootstrap servers | | 1061 | | 2. list of trust anchor certs for bootstrap servers | | 1062 | | 3. trust anchor cert for owner certificates | | 1063 | | 4. trust anchor cert for device ownership vouchers | | 1064 | | 5. IDevID cert & associated intermediate certificate(s) | | 1065 | +----------------------------------------------------------+ | 1066 | | 1067 | +----------------------+ | 1068 | | | | 1069 | | | | 1070 | | 6. private key | | 1071 | +----------------------+ | 1072 | | 1073 +------------------------------------------------------------------+ 1075 Each numbered item below corresponds to a numbered item in the 1076 diagram above. 1078 1. Devices that support loading bootstrapping data from an Internet- 1079 based bootstrap server (see Section 4) MUST be manufactured with 1080 a list of trusted bootstrap servers. Each bootstrap server MAY 1081 be identified by just its hostname or IP address, and an optional 1082 port. Note that it is not necessary to configure URLs, as the 1083 RESTCONF protocol defines how the bootstrap server API specified 1084 in Section 7.4 maps into URLs. 1086 2. Devices that support loading bootstrapping data from an Internet- 1087 based bootstrap server (see Section 4) SHOULD be manufactured 1088 with a list of trust anchor certificates that can be for X.509 1089 certificate path validation [RFC6125], Section 6) on the 1090 bootstrap server's TLS server certificate. 1092 3. Devices that support loading owner signed data (see Section 1.2) 1093 MUST be manufactured with the trust anchor certificate for the 1094 owner certificates that the manufacturer provides to prospective 1095 owners when they enroll in the manufacturer's Zero Touch program 1096 (see Section 5.1). 1098 4. Devices that support loading owner signed data (see Section 1.2) 1099 MUST also be manufactured with the trust anchor certificate for 1100 the device ownership vouchers that the manufacturer provides to 1101 prospective owners when it ships out an order of Zero Touch 1102 devices (see Section 5.1). 1104 5. Devices MUST be manufactured with an initial device identifier 1105 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 1106 X.509 certificate, encoding a unique device identifier (e.g., 1107 serial number). The device MUST also possess any intermediate 1108 certificates between the IDevID certificate and the 1109 manufacturer's IDevID trust anchor certificate. 1111 6. Device MUST be manufactured with a private key that corresponds 1112 to the public key encoded in the device's IDevID certificate. 1113 This private key SHOULD be securely stored, ideally by a 1114 cryptographic processor (e.g., a TPM). 1116 6.2. Boot Sequence 1118 A device claiming to support Zero Touch MUST support the boot 1119 sequence described in this section. 1121 Power On 1122 | 1123 v No 1124 1. Running default config? --------> Boot normally 1125 | 1126 | Yes 1127 v 1128 2. For each supported source for bootstrapping data, 1129 try to load bootstrapping data from the source 1130 | 1131 | 1132 v Yes 1133 3. Able to bootstrap off any source? -----> Run with new configuration 1134 | 1135 | No 1136 v 1137 4. Loop or wait for manual provisioning. 1139 These interactions are described next. 1141 1. When the device powers on, it first checks to see if it is 1142 running the factory default configuration. If it is running a 1143 modified configuration, then it boots normally. 1145 2. The device iterates over its list of sources for bootstrapping 1146 data Section 4. Details for how to processes a source of 1147 bootstrapping data are provided in Section 6.3. 1149 3. If the device is able to bootstrap itself off any of the sources 1150 for bootstrapping data, it runs with the new bootstrapped 1151 configuration. 1153 4. Otherwise the device MAY loop back through the list of 1154 bootstrapping sources again and/or wait for manual provisioning. 1156 6.3. Processing a Source of Boostrapping Data 1158 This section describes a recursive algorithm that a device claiming 1159 to support Zero Touch MUST use to authenticate bootstrapping data. A 1160 device enters this algorithm for each new source of bootstrapping 1161 data. The first time the device enters this algorithm, it MUST 1162 initialize a conceptual trust state variable, herein referred to as 1163 "trust-state", to FALSE. The ultimate goal of this algorithm is for 1164 the device to process bootstrap information (not redirect 1165 information) while its trust-state is TRUE. 1167 If the data source is a bootstrap server, and the device is able to 1168 authenticate the server using X.509 certificate path validation 1169 ([RFC6125], Section 6) to one of the the device's preconfigured trust 1170 anchors, or to a trust anchor that it learned from a previous step, 1171 then the device MUST set trust-state to TRUE. If trust-state is 1172 TRUE, when connecting to the bootstrap server, the device MUST use 1173 its IDevID certificate for a client-certificate based authentication 1174 and MUST POST progress notifications using the bootstrap server's 1175 "notification" action. Otherwise, if trust-state is FALSE, when 1176 connecting to the bootstrap server, the device MUST NOT use its 1177 IDevID certificate for a client-certificate based authentication and 1178 MUST NOT POST progress notifications using the bootstrap server's 1179 "notification" action. When accessing a bootstrap server, the device 1180 MUST only access its top-level resource, to obtain all the data 1181 staged for it in one GET request, so that it can determine if the 1182 data is signed or not, and thus act accordingly. 1184 For any data source, if the data is signed (i.e. the data includes a 1185 'signature' field) and the device is able to validate the signed data 1186 using the algorithm described in Section 6.4, then the device MUST 1187 set trust-state to TRUE, else the device MUST set trust-state to 1188 FALSE. Note, this is worded to cover the special case when signed 1189 data is returned even from a trusted bootstrap server. 1191 If the data is bootstrap information (not redirect information), and 1192 trust-state is FALSE, the device MUST exit the recursive algorithm, 1193 returning to the state machine described in Section 6.2. Otherwise, 1194 the device MUST attempt to process the bootstrap information as 1195 described in Section 6.6. In either case, success of failure, the 1196 device MUST exit the recursive algorithm, returning to the state 1197 machine described in Section 6.2, the only difference being in how it 1198 responds to the "Able to bootstrap off any source?" conditional 1199 described in that state machine. 1201 If the data is redirect information, the device MUST process the 1202 redirect information as described in Section 6.5. This is the 1203 recursion step, it will cause to device to reenter this algorithm, 1204 but this time the data source will most definitely be a bootstrap 1205 server, as that is all redirect information is able to do, though 1206 it's interesting to note that the bootstrap server's response MAY be 1207 more redirect information. 1209 6.4. Validating Signed Data 1211 Whenever a device is presented signed data, it MUST validate the 1212 signed data as described in this section. 1214 Whenever there is signed data, the device MUST also be provided an 1215 ownership voucher and an owner certificate. How all the needed 1216 records are provided for each source of bootstrapping data is defined 1217 in Section 4 1219 The device MUST first authenticate the ownership voucher by 1220 validating the signature on it to one of its preconfigured trust 1221 anchors (see Section 6.1) and verify that the voucher contains the 1222 device's unique identifier (e.g., serial number). If the 1223 authentication of the voucher is successful, the device extracts the 1224 Rightful owner's identity from the voucher for use in the next step. 1226 Next the device MUST authenticate the owner certificate by performing 1227 X.509 certificate path validation on it to one of its preconfigured 1228 trust anchors (see Section 6.1) and by verifying that the Subject 1229 contained in the certificate matches the Rightful owner identity 1230 extracted from the voucher in the previous step. If the 1231 authentication of the certificate is successful, the device extracts 1232 the owner's public key from the certificate for use in the next step. 1234 Finally the device MUST authenticate the signed data by verifying the 1235 signature on it was generated by the private key matching the public 1236 key extracted from the owner certificate in the previous step. 1238 If any of these steps fail, then the device MUST mark the data as 1239 invalid and not perform any of the subsequent steps. 1241 6.5. Processing Redirect Information 1243 In order to process redirect information (Section 3.1), the device 1244 MUST follow the steps presented in this section. 1246 Processing redirect information is straightforward. Essentially the 1247 device MUST immediately attempt to establish a RESTCONF connection to 1248 the provided bootstrap server IP address or hostname. 1250 If a hostname is provided, and its DNS resolution is to more than one 1251 IP address, the device MUST attempt to try to connect to all of them, 1252 sequentially, until it is able to successfully bootstrap off one of 1253 them. 1255 If the redirect information includes a trust anchor, and the redirect 1256 information can be trusted (e.g., trust-state is TRUE), then the 1257 device MUST authenticate the bootstrap server using X.509 certificate 1258 path validation ( [RFC6125], Section 6) using the specified trust 1259 anchor. 1261 6.6. Processing Bootstrap Information 1263 In order to process bootstrap information (Section 3.2), the device 1264 MUST follow the steps presented in this section. 1266 When processing bootstrap information, the device MUST first process 1267 the boot image information, then commit the initial configuration, 1268 and then execute the script, if any, in that order. If the device 1269 encounters an error at any step, it MUST NOT proceed to the next 1270 step. 1272 First the device MUST determine if the image it is running satisfies 1273 the specified "boot-image" criteria. If it does not, the device MUST 1274 download and install the specified boot image, and reboot. Upon 1275 rebooting, the device MUST still be in its factory default state, 1276 causing the bootstrapping process to run again, which will eventually 1277 come to this very point, but this time the device's running image 1278 will satisfy the specified criteria, and thus the device moves to 1279 processing the next step. 1281 Next the device commits the provided initial configuration. Assuming 1282 no errors, the device moves to processing the next step. 1284 Next, for devices that support executing scripts, if a script has 1285 been specified, the device executes the script, checking its exit 1286 status code to determine if it succeeded, had warning, or had errors. 1287 In the case of errors, the device MUST reset itself in such a way 1288 that force the reinstallation of its boot image, thereby wiping out 1289 any bad state the script might have left behind. 1291 At this point, the device has completely processed the bootstrapping 1292 data and is ready to be managed. If the configuration configured the 1293 device it initiate a call home connection, it should proceed to do so 1294 now. Otherwise, the device should wait for a NETCONF or RESTCONF 1295 client to connect to it. 1297 7. YANG-defined API and Artifacts 1299 Central to the solution presented in this document is the use of a 1300 YANG module [RFC6020] to simultaneously define a RESTCONF based API 1301 for a bootstrap/redirect server as well as the encoding for signed 1302 artifacts that can be conveyed outside of the RESTCONF protocol 1303 (DHCP, FTP, TFTP, etc.). 1305 The module defined in this section makes extensive use of data types 1306 defined in [RFC2315], [RFC5280], [RFC6991], and [RFC5280]. 1308 7.1. Module Overview 1310 The following tree diagram Section 1.3 provides an overview for both 1311 the API and artifacts that can be used outside of RESTCONF. 1313 module: ietf-zerotouch-bootstrap-server 1314 +--ro devices 1315 +--ro device* [unique-id] 1316 +--ro unique-id string 1317 +--ro (type)? 1318 | +--:(redirect-information) 1319 | | +--ro redirect-information 1320 | | +--ro bootstrap-server* [address] 1321 | | +--ro address inet:host 1322 | | +--ro port? inet:port-number 1323 | | +--ro trust-anchor binary 1324 | +--:(bootstrap-information) 1325 | +--ro bootstrap-information 1326 | +--ro boot-image 1327 | | +--ro modules 1328 | | | +--ro module* 1329 | | | +--ro name? yang:yang-identifier 1330 | | | +--ro revision? string 1331 | | +--ro name string 1332 | | +--ro md5 string 1333 | | +--ro sha1 string 1334 | | +--ro uri* inet:uri 1335 | +--ro configuration 1336 | +--ro script? string 1337 +--ro owner-certificate 1338 | +--ro certificate binary 1339 | +--ro issuer-crl? binary 1340 +--ro ownership-voucher 1341 | +--ro voucher binary 1342 | +--ro issuer-vrl? binary 1343 +--ro signature? binary 1344 +---x notification 1345 +---w input 1346 +---w notification-type enumeration 1347 +---w message? string 1348 +---w ssh-host-keys 1349 | +---w ssh-host-key* 1350 | +---w format enumeration 1351 | +---w key-data string 1352 +---w trust-anchors 1353 +---w trust-anchor* 1354 +---w protocol* enumeration 1355 +---w certificate binary 1357 In the above diagram, notice that all of the protocol accessible node 1358 are read-only, to assert that devices can only pull data from the 1359 bootstrap server. 1361 Also notice that the module defines an action statement, which 1362 devices may use to provide progress notifications to the bootstrap 1363 server. 1365 7.2. API Examples 1367 This section presents some examples illustrating device interactions 1368 with a bootstrap server to access Redirect and Bootstrap information, 1369 both unsigned and signed, as well as to send a progress notification. 1370 These examples show the bootstrap information containing 1371 configuration defined by [RFC7317] and 1372 [draft-ietf-netconf-server-model]. 1374 7.2.1. Unsigned Redirect Information 1376 The following example illustrates a device using the API to fetch its 1377 bootstrapping data. In this example, the device receives unsigned 1378 redirect information. This example is representative of a response a 1379 trusted redirect server might return. 1381 REQUEST 1382 ------- 1383 ['\' line wrapping added for formatting only] 1385 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1386 devices/device=123456 HTTP/1.1 1387 HOST: example.com 1388 Accept: application/yang.data+xml 1390 RESPONSE 1391 -------- 1393 HTTP/1.1 200 OK 1394 Date: Sat, 31 Oct 2015 17:02:40 GMT 1395 Server: example-server 1396 Content-Type: application/yang.data+xml 1398 1400 1402 123456789 1403 1404 1405
phs1.example.com
1406 8443 1407 1408 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1409 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1410 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1411 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1412 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1413 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1414 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1415 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1416 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1417 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1418 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1419 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1420 RJSUJQFRStS0Cg== 1421 1422
1423 1424
phs2.example.com
1425 8443 1426 1427 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1428 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1429 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1430 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1431 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1432 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1433 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1434 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1435 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1436 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1437 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1438 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1439 RJSUJQFRStS0Cg== 1440 1441
1442
1443
1445 7.2.2. Signed Redirect Information 1447 The following example illustrates a device using the API to fetch its 1448 bootstrapping data. In this example, the device receives signed 1449 redirect information. This example is representative of a response 1450 that redirect server might return if concerned the device might not 1451 be able to authenticate its TLS certificate. 1453 REQUEST 1454 ------- 1455 ['\' line wrapping added for formatting only] 1456 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1457 devices/device=123456 HTTP/1.1 1458 HOST: example.com 1459 Accept: application/yang.data+xml 1461 RESPONSE 1462 -------- 1464 HTTP/1.1 200 OK 1465 Date: Sat, 31 Oct 2015 17:02:40 GMT 1466 Server: example-server 1467 Content-Type: application/yang.data+xml 1469 1471 1473 123456789 1474 1475 1476
phs1.example.com
1477 8443 1478 1479 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1480 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1481 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1482 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1483 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1484 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1485 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1486 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1487 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1488 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1489 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1490 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1491 RJSUJQFRStS0Cg== 1492 1493
1494 1495
phs2.example.com
1496 8443 1497 1498 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1499 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1500 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1501 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1502 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1503 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1504 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1505 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1506 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1507 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1508 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1509 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1510 RJSUJQFRStS0Cg== 1511 1512
1513
1514 1515 1516 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\ 1517 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\ 1518 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 1519 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1520 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1521 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1522 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1523 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1524 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\ 1525 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 1526 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 1527 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\ 1528 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 1529 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1530 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1531 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1532 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1533 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1534 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\ 1535 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\ 1536 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\ 1537 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\ 1538 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\ 1539 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\ 1540 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\ 1541 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1542 1543 1544 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1545 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1546 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1547 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1548 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1549 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1550 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1551 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1552 MjAO== 1553 1554 1555 1556 1557 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 1558 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1559 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1560 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1561 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1562 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1563 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1564 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1565 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1566 MjAO 1567 1568 1569 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1570 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1571 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1572 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1573 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 1574 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 1575 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 1576 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1577 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1578 1579 1580 1581 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1582 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1583 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1584 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1585 1586
1588 7.2.3. Unsigned Bootstrap Information 1590 The following example illustrates a device using the API to fetch its 1591 bootstrapping data. In this example, the device receives unsigned 1592 bootstrapping information. This example is representative of a 1593 response a locally deployed bootstrap server might return. 1595 REQUEST 1596 ------- 1597 ['\' line wrapping added for formatting only] 1598 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1599 devices/device=123456 HTTP/1.1 1600 HOST: example.com 1601 Accept: application/yang.data+xml 1603 RESPONSE 1604 -------- 1606 HTTP/1.1 200 OK 1607 Date: Sat, 31 Oct 2015 17:02:40 GMT 1608 Server: example-server 1609 Content-Type: application/yang.data+xml 1611 1613 1615 123456789 1616 1617 1618 1619 boot-image-v3.2R1.6.img 1620 1621 1622 SomeMD5String 1623 1624 1625 SomeSha1String 1626 1627 1628 ftp://ftp.example.com/path/to/file 1629 1630 1631 1632 1633 1634 1635 1636 admin 1637 1638 admin's rsa ssh host-key 1639 ssh-rsa 1640 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\ 1641 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\ 1642 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\ 1643 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\ 1644 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\ 1645 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\ 1646 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1647 1648 1649 1650 1651 1652 1654 1655 1656 config-mgr 1657 1658 1659 1660 east-data-center 1661
11.22.33.44
1662
1663 1664 west-data-center 1665
55.66.77.88
1666
1667
1668 1669 my-call-home-x509-key 1670 1671
1672
1673
1674
1675
1676
1677
1679 7.2.4. Signed Bootstrap Information 1681 The following example illustrates a device using the API to fetch its 1682 bootstrapping data. In this example, the device receives signed 1683 bootstrap information. This example is representative of a response 1684 that bootstrap server might return if concerned the device might not 1685 be able to authenticate its TLS certificate. 1687 REQUEST 1688 ------- 1690 ['\' line wrapping added for formatting only] 1692 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1693 devices/device=123456 HTTP/1.1 1694 HOST: example.com 1695 Accept: application/yang.data+xml 1697 RESPONSE 1698 -------- 1700 HTTP/1.1 200 OK 1701 Date: Sat, 31 Oct 2015 17:02:40 GMT 1702 Server: example-server 1703 Content-Type: application/yang.data+xml 1705 1707 1709 123456789 1710 1711 1712 1713 boot-image-v3.2R1.6.img 1714 1715 1716 SomeMD5String 1717 1718 1719 SomeSha1String 1720 1721 1722 /path/to/on/same/bootserver 1723 1724 1725 1726 1727 1728 1729 1730 admin 1731 1732 admin's rsa ssh host-key 1733 ssh-rsa 1734 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\ 1735 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\ 1736 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\ 1737 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\ 1738 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\ 1739 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\ 1740 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1741 1742 1743 1744 1745 1746 1748 1749 1750 config-mgr 1751 1752 1753 1754 east-data-center 1755
11.22.33.44
1756
1757 1758 west-data-center 1759
55.66.77.88
1760
1761
1762 1763 my-call-home-x509-key 1764 1765
1766
1767
1768
1769
1770
1771 1772 1773 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\ 1774 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\ 1775 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 1776 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1777 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1778 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1779 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1780 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1781 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\ 1782 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 1783 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 1784 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\ 1785 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 1786 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1787 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1788 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1789 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1790 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1791 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\ 1792 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\ 1793 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\ 1794 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\ 1795 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\ 1796 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\ 1797 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\ 1798 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1799 1800 1801 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1802 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1803 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1804 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1805 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1806 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1807 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1808 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1809 MjAO== 1810 1811 1812 1813 1814 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 1815 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 1816 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1817 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1818 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 1819 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1820 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 1821 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 1822 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 1823 MjAO 1824 1825 1826 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1827 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1828 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 1829 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1830 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 1831 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 1832 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 1833 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 1834 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1835 1837 1838 1839 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 1840 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 1841 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 1842 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1843 1844
1846 7.2.5. Progress Notifications 1848 The following example illustrates a device using the API to post a 1849 notification to the server. The device may send more than one 1850 notification to the server (e.g., to provide status updates). The 1851 YANG module defines only one notification type, bootstrap-complete. 1852 Other notification types may be defined through YANG augmentation. 1854 The bootstrap server MUST NOT process a notification from a device 1855 without first authenticating the device. This is in contrast to when 1856 a device is fetching data from the server, a read-only operation, in 1857 which case device authentication is not strictly required. 1859 In this example, the device sends a notification indicating that it 1860 has completed bootstrapping off the data provided by the server. 1861 This example also illustrates the device sending its SSH host keys to 1862 the bootstrap server, which it might, for example, forward onto a 1863 downstream NMS component, so that the NMS can subsequently 1864 authenticate the device when establishing a NETCONF over SSH 1865 connection to it. 1867 Note that the need for a device to provide its SSH host key (or TLS 1868 server certificate) in the "bootstrap-complete" message is 1869 unnecessary when the device is able to present its IDevID certificate 1870 [Std-802.1AR-2009] as its SSH host key or TLS server certificate, 1871 when subsequently establishing a NETCONF or RESTCONF connection with 1872 the deployment-specific NMS. 1874 REQUEST 1875 ------- 1876 ['\' line wrapping added for formatting only] 1878 POST https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1879 devices/device=123456/notification HTTP/1.1 1880 HOST: example.com 1881 Content-Type: application/yang.data+xml 1883 1884 1886 bootstrap-complete 1887 example message 1888 1889 1890 ssh-rsa 1891 1892 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\ 1893 zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\ 1894 zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\ 1895 9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\ 1896 QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\ 1897 LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\ 1898 VOZZgQ8929uWjCWlGlqn2mPibp2Go1 1899 1900 1901 1902 ssh-dsa 1903 1904 zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\ 1905 zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\ 1906 9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\ 1907 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\ 1908 QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\ 1909 LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\ 1910 VOZZgQ8929uWjCWlGlqn2mPibp2Go1 1911 1912 1913 1914 1915 1916 netconf-ssh 1917 netconf-tls 1918 restconf-tls 1919 netconf-ch-ssh 1920 netconf-ch-tls 1921 restconf-ch-tls 1922 1923 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1924 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1925 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1926 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1927 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1928 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1929 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1930 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1931 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1932 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1933 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1934 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1935 RJSUJQFRStS0Cg== 1936 1937 1938 1940 1942 RESPONSE 1943 -------- 1945 HTTP/1.1 204 No Content 1946 Date: Sat, 31 Oct 2015 17:02:40 GMT 1947 Server: example-server 1949 7.3. Artifact Examples 1951 This section presents some examples for how the same information 1952 provided by the API can be packaged into stand alone artifacts. The 1953 encoding for these artifacts is the same as if an HTTP GET request 1954 had been sent to the RESTCONF URL for the specific resource. These 1955 examples show the bootstrap information containing configuration 1956 defined by [RFC7317] and [draft-ietf-netconf-server-model]. 1958 Encoding these artifacts for use outside of the RESTCONF protocol 1959 extends their utility for other deployment scenarios, such as when a 1960 local DHCP server or a removable storage device is used. By way of 1961 example, this may be done to address an inability for the device to 1962 access an Internet facing bootstrap/redirect server, or just for a 1963 preference to use locally deployed infrastructure. 1965 7.3.1. Signed Redirect Information 1967 The following example illustrates how a redirect can be encoded into 1968 an artifact for use outside of the RESTCONF protocol. The redirect 1969 information is signed so that it is secure even when no transport- 1970 level security is provided. 1972 1974 1976 1977
phs1.example.com
1978 8443 1979 1980 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 1981 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 1982 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 1983 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 1984 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 1985 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 1986 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 1987 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 1988 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 1989 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 1990 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 1991 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 1992 RJSUJQFRStS0Cg== 1993 1994
1995 1996
phs1.example.com
1997 8443 1998 1999 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 2000 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 2001 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 2002 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 2003 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 2004 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 2005 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 2006 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 2007 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 2008 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 2009 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 2010 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 2011
2012 2013 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2014 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2015 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2016 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 2017 2018
2020 7.3.2. Signed Bootstrap Information 2022 The following example illustrates how bootstrapping data can be 2023 encoded into an artifact for use outside of the RESTCONF protocol. 2024 The bootstrap information is signed so that it is secure when no 2025 transport-level security is provided. 2027 2029 2031 2032 2033 boot-image-v3.2R1.6.img 2034 2035 2036 SomeMD5String 2037 2038 2039 SomeSha1String 2040 2041 2042 file:///some/path/to/raw/file 2043 2044 2045 2046 2047 2048 2049 2050 admin 2051 2052 admin's rsa ssh host-key 2053 ssh-rsa 2054 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC\ 2055 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj\ 2056 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC\ 2057 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5\ 2058 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq\ 2059 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6\ 2060 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 2061 2062 2063 2064 2065 2066 2068 2069 2070 config-mgr 2071 2072 2073 2074 east-data-center 2075
11.22.33.44
2076
2077 2078 west-data-center 2079
55.66.77.88
2080
2081
2082 2083 my-call-home-x509-key 2084 2085
2086
2087
2088
2089
2090
2092 7.3.3. Owner Certificate 2094 The following example illustrates how the owner certificate, along 2095 with its CRL, can be encoded into an artifact for use outside of the 2096 RESTCONF protocol. Note that the inclusion of the CLR is optional, 2097 and only present to support cases where the device is deployed on a 2098 private network, such that it would be unable to validate the 2099 revocation status of the certificate using an online lookup of the 2100 CRL or using OCSP. As the owner certificate and CRL are already 2101 signed by the manufacturer, an additional owner signature is 2102 unnecessary. 2104 2106 2108 2109 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\ 2110 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\ 2111 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2112 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2113 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2114 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2115 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2116 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2117 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\ 2118 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 2119 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 2120 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\ 2121 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 2122 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2123 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2124 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2125 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2126 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2127 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\ 2128 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\ 2129 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\ 2130 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\ 2131 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\ 2132 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\ 2133 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\ 2134 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 2135 2136 2137 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2138 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2139 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2140 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2141 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2142 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2143 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2144 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2145 MjAO== 2146 2147 2149 7.3.4. Ownership Voucher 2151 The following example illustrates how the ownership voucher, along 2152 with its CRL, can be encoded into an artifact for use outside of the 2153 RESTCONF protocol. Note that the inclusion of the CLR is optional, 2154 and only present to support cases where the device is deployed on a 2155 private network, such that it would be unable to validate the 2156 revocation status of the certificate using an online lookup of the 2157 CRL or using OCSP. As the ownership voucher and CRL are already 2158 signed by the manufacturer, an additional owner signature is 2159 unnecessary. 2161 2163 2165 2166 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2167 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2168 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2169 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2170 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2171 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2172 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2173 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2174 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2175 MjAO 2176 2177 2178 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2179 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2180 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2181 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2182 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 2183 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 2184 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 2185 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2186 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 2187 2188 2190 7.4. YANG Module 2192 The bootstrap server's device-facing interface is normatively defined 2193 by the following YANG module: 2195 file "ietf-zerotouch-bootstrap-server@2016-03-16.yang" 2196 module ietf-zerotouch-bootstrap-server { 2197 yang-version "1.1"; 2199 namespace 2200 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 2201 prefix "ztbs"; 2203 import ietf-yang-types { // RFC 6991 2204 prefix yang; 2205 } 2207 import ietf-inet-types { // RFC 6991 2208 prefix inet; 2209 } 2211 organization 2212 "IETF NETCONF (Network Configuration) Working Group"; 2214 contact 2215 "WG Web: 2216 WG List: 2217 WG Chair: Mehmet Ersue 2218 2219 WG Chair: Mahesh Jethanandani 2220 2221 Editor: Kent Watsen 2222 "; 2224 description 2225 "This module defines the southbound interface for Zero Touch 2226 bootstrap servers. 2228 Copyright (c) 2014 IETF Trust and the persons identified as 2229 authors of the code. All rights reserved. 2231 Redistribution and use in source and binary forms, with or 2232 without modification, is permitted pursuant to, and subject 2233 to the license terms contained in, the Simplified BSD 2234 License set forth in Section 4.c of the IETF Trust's 2235 Legal Provisions Relating to IETF Documents 2236 (http://trustee.ietf.org/license-info). 2238 This version of this YANG module is part of RFC XXXX; see 2239 the RFC itself for full legal notices."; 2241 revision "2016-03-16" { 2242 description 2243 "Initial version"; 2245 reference 2246 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 2247 } 2249 container devices { 2250 config false; 2251 description 2252 "This is the top-level container for a device-facing protocol. 2253 As such it is read-only, how this data is configured is outside 2254 the scope of this data-model. Further, it is expected that 2255 devices would only be able to access their data and not the 2256 data for any other device."; 2257 list device { 2258 key unique-id; 2260 description 2261 "A device's record entry. This is the only RESTCONF resource 2262 that a device is expected to GET. Getting this just this 2263 top-level provides the device with all the data it needs in 2264 a single request, which is ideal from both a performance and 2265 a resiliency perspectives.."; 2267 leaf unique-id { 2268 type string; 2269 description 2270 "A unique identifier for the device (e.g., serial number). 2271 Each device accesses its bootstrapping record by its unique 2272 identifier."; 2273 } 2275 choice type { 2276 description 2277 "This choice statement ensures the response only contains 2278 redirect-information or bootstrap-information."; 2280 container redirect-information { 2281 description 2282 "This is redirect information data. Its purpose is to 2283 redirect the device to another bootstrap server. It 2284 contains a list of bootstrap servers."; 2286 list bootstrap-server { 2287 key address; 2288 description 2289 "A bootstrap server entry."; 2291 leaf address { 2292 type inet:host; 2293 description 2294 "The IP address or hostname of the bootstrap server 2295 the device should redirect to."; 2296 } 2297 leaf port { 2298 type inet:port-number; 2299 default 443; 2300 description 2301 "The port number the bootstrap server listens on."; 2302 } 2303 leaf trust-anchor { 2304 type binary; 2305 mandatory true; 2306 description 2307 "An X.509 v3 certificate structure as specified by RFC 2308 5280, Section 4 encoded using the ASN.1 distinguished 2309 encoding rules (DER), as specified in ITU-T X.690. A 2310 certificate that a device can use as a trust anchor to 2311 authenticate the bootstrap server it is being redirected 2312 to."; 2313 reference 2314 "RFC 5280: 2315 Internet X.509 Public Key Infrastructure Certificate 2316 and Certificate Revocation List (CRL) Profile. 2317 ITU-T X.690: 2318 Information technology - ASN.1 encoding rules: 2319 Specification of Basic Encoding Rules (BER), 2320 Canonical Encoding Rules (CER) and Distinguished 2321 Encoding Rules (DER)."; 2322 } 2323 } 2324 } 2326 container bootstrap-information { 2327 description 2328 "This is bootstrap information data. Its purpose is to 2329 provide the device everything it needs to bootstrap 2330 itself."; 2332 container boot-image { 2333 description 2334 "Specifies criteria for the boot image the device MUST be 2335 running."; 2337 container modules { 2338 description 2339 "Specifies a list of YANG modules that the device MUST 2340 support. This node is optional. When this node is 2341 specified, the remaining nodes MUST be processed only 2342 in case the currently running image does not support 2343 any of the YANG modules, as a means to obtain a valid 2344 image. When this node is not specified, then the 2345 device MUST ensure it is running the exact image, as 2346 specified by the remaining 'boot-image' nodes."; 2347 list module { 2348 description 2349 "Specifies a specific YANG modules, by its name and 2350 revision date. The revision date is provided as a 2351 minimal revision date, and supported revision 2352 thereafter is considered sufficient"; 2353 leaf name { 2354 type yang:yang-identifier; 2355 description 2356 "The YANG module's name."; 2357 } 2358 leaf revision { 2359 type string { 2360 pattern '\d{4}-\d{2}-\d{2}'; 2361 } 2362 description 2363 "Represents a specific date in 2016-03-16 format."; 2364 } 2365 } 2366 } 2367 leaf name { 2368 type string; 2369 mandatory true; 2370 description 2371 "The name of a software image that either the device 2372 MUST be running, or MUST install only if its currently 2373 running image cannot support any of the required YANG 2374 modules."; 2375 } 2376 leaf md5 { 2377 type string; 2378 mandatory true; 2379 description 2380 "The hex-encoded MD5 hash over the boot-image file."; 2381 } 2382 leaf sha1 { 2383 type string; 2384 mandatory true; 2385 description 2386 "The hex-encoded SHA-1 hash over the boot-image file."; 2387 } 2388 leaf-list uri { 2389 type inet:uri; 2390 min-elements 1; 2391 description 2392 "An ordered list of URIs to where the boot-image file 2393 may be obtained. When the bootstrap information is 2394 obtained from a bootstrap server, it is RECOMMENDED 2395 that the list begins with absolute paths (e.g., 2396 beginning with '/') to the bootstrap server, so as 2397 to leverage the existing secure connection. If remote 2398 URLs are also present in the list, deployments MUST 2399 know in advance which URI schemes (https, http, ftp, 2400 file, etc.) a device supports. If a secure scheme 2401 (e.g., https) is provided, devices MAY blindly accept 2402 the server's credentials (e.g., TLS certificate). 2403 Regardless how obtained, the device MUST ensure that 2404 the boot-image is valid, either by leveraging a 2405 signature embedded in the boot-image itself, if it 2406 exists, or by first comparing the downloaded image to 2407 both the MD5 and SHA1 fingerprints provided above."; 2408 } 2409 } 2411 anyxml configuration { // pyang doesn't support anydata yet! 2412 description 2413 "Any configuration data model known to the device. It may 2414 contain manufacturer-specific and/or standards-based data 2415 models."; 2416 } 2418 leaf script { 2419 type string; 2420 description 2421 "A device specific script that enables the execution of 2422 commands to perform actions not possible thru configuration 2423 alone. The script SHOULD be executed with 'root' level 2424 permissions. 2426 If a script is erroneously provided to a device that 2427 does not support the execution of scripts, the device 2428 SHOULD send a 'script-warning' notification message, 2429 but otherwise continue processing the bootstrapping 2430 data as if the script had not been present. 2432 The script would return exit status code '0' on success 2433 and non-zero on error, with accompanying stderr/stdout 2434 for logging purposes. In the case of an error, the exit 2435 status code will specify what the device should do. 2437 If the exit status code is greater than zero, then the 2438 device should assume that the script had soft failure 2439 that the script believes does not affect manageability. 2440 If the device obtained the bootstrap information from 2441 a bootstrap server, it SHOULD send a 'script-warning' 2442 notification message. 2444 If the exit status code is less than zero, the device 2445 should assume the script had a hard error that the 2446 script believes will affect manageability. In this 2447 case, the device should try to send a 'script-error' 2448 notification message followed by a reset that will 2449 force a new boot-image install (wiping out anything 2450 the script may have done) and restart the entire 2451 bootstrapping process again."; 2452 } 2453 } 2454 } 2456 container owner-certificate { 2457 when "../ownership-voucher" { 2458 description 2459 "The owner certificate is only configurable when there 2460 also exists an ownership voucher."; 2461 } 2462 description 2463 "It is intended that the device will fetch this container 2464 as a whole, as it contains values that need to be 2465 processed together."; 2467 leaf certificate { 2468 type binary; 2469 mandatory true; 2470 description 2471 "An X.509 v3 certificate structure as specified by RFC 2472 5280, Section 4 encoded using the ASN.1 distinguished 2473 encoding rules (DER), as specified in ITU-T X.690. 2474 This certificate, signed by a manufacturer or delegate, 2475 for an owner, must encode a manufacturer-assigned value 2476 identifying the organization. This identifier must match 2477 the owner identifier encoded in the ownership voucher."; 2478 reference 2479 "RFC 5280: 2480 Internet X.509 Public Key Infrastructure Certificate 2481 and Certificate Revocation List (CRL) Profile. 2482 ITU-T X.690: 2483 Information technology - ASN.1 encoding rules: 2484 Specification of Basic Encoding Rules (BER), 2485 Canonical Encoding Rules (CER) and Distinguished 2486 Encoding Rules (DER)."; 2487 } 2489 leaf issuer-crl { 2490 type binary; 2491 description 2492 "An CRL structure as specified by RFC 5280, Section 5 2493 encoded using the ASN.1 distinguished encoding rules 2494 (DER), as specified in ITU-T X.690. The CRL for the 2495 CA that signed the owner certificate. The CRL should 2496 be as up to date as possible. This leaf is optional 2497 as it is only needed to support deployments where the 2498 device is unable to download the CRL from and of the 2499 distribution points listed in the owner certificate."; 2500 reference 2501 "RFC 5280: 2502 Internet X.509 Public Key Infrastructure Certificate 2503 and Certificate Revocation List (CRL) Profile. 2504 ITU-T X.690: 2505 Information technology - ASN.1 encoding rules: 2506 Specification of Basic Encoding Rules (BER), 2507 Canonical Encoding Rules (CER) and Distinguished 2508 Encoding Rules (DER)."; 2509 } 2510 } 2512 container ownership-voucher { 2513 when "../signature" { 2514 description 2515 "An ownership voucher is only configurable when there 2516 also exists a signature."; 2517 } 2518 must "../owner-certificate" { 2519 description 2520 "An owner certificate must be present whenever an 2521 ownership voucher is present."; 2522 } 2523 description 2524 "This container contains the ownership voucher that the 2525 device uses to ascertain the identity of its rightful 2526 owner, as certified by its manufacturer."; 2528 leaf voucher { 2529 type binary; 2530 mandatory true; 2531 description 2532 "A manufacturer-specific encoding binding unique device 2533 identifiers to an owner identifier value matching the 2534 value encoded in the owner-certificate below."; 2535 } 2537 leaf issuer-vrl { 2538 type binary; 2539 description 2540 "An manufacturer-specific encoding of a voucher revocation 2541 list (VRL) for the issuer used by the manufacturer or 2542 delegate to sign ownership vouchers. The VRL should be 2543 as up to date as possible. This leaf is optional as it 2544 is only needed to support deployments where the device 2545 is unable to download the VRL from the manufacturer or 2546 delegate using some manufacturer-specific mechanism."; 2547 } 2548 } 2550 leaf signature { 2551 type binary; 2552 must "../ownership-voucher" { 2553 description 2554 "An ownership voucher must be present whenever an 2555 signature is present."; 2556 } 2557 description 2558 "A PKCS #7 SignedData structure as specified by RFC 2559 2315, Section 9.1 encoded using the ASN.1 distinguished 2560 encoding rules (DER), as specified in ITU-T X.690. 2561 This signature is generated using the owner's private 2562 private key and an owner-selected digest algorithm over 2563 the redirect-information or the bootstrap-information 2564 fields, which ever is present, and in whatever encoding 2565 they are presented in (e.g., XML, JSON, etc.)."; 2566 reference 2567 "RFC 2315: 2568 PKCS #7: Cryptographic Message Syntax Version 1.5 2569 ITU-T X.690: 2570 Information technology - ASN.1 encoding rules: 2571 Specification of Basic Encoding Rules (BER), 2572 Canonical Encoding Rules (CER) and Distinguished 2573 Encoding Rules (DER)."; 2574 } 2576 action notification { 2577 input { 2578 leaf notification-type { 2579 type enumeration { 2580 enum bootstrap-initiated { 2581 description 2582 "Indicates that the device has just accessed 2583 the bootstrap server. The 'message' field 2584 below SHOULD contain any additional information 2585 that the manufacturer thinks might be useful, 2586 or omitted entirely."; 2587 } 2588 enum validation-error { 2589 description 2590 "Indicates that the device had an issue validating 2591 the response from the bootstrap server. The 2592 'message' field below SHOULD indicate the specific 2593 error. This message also indicates that the device 2594 has abandoned trying to bootstrap off this bootstrap 2595 server."; 2596 } 2597 enum signature-validation-error { 2598 description 2599 "Indicates that the device had an issue validating 2600 the bootstrapping data. For instance, this could 2601 be due to the device expecting signed data, but 2602 only found unsigned data, or because the ownership 2603 voucher didn't include its unique identifier, or 2604 because the signature didn't match, or and other 2605 relevant error. This 'message' field below SHOULD 2606 indicate the specific error. This message also 2607 indicates that the device has abandoned trying to 2608 bootstrap off this bootstrap server."; 2609 } 2610 enum image-mismatch { 2611 description 2612 "Indicates that the device has determined that 2613 its running image does not meet the specified 2614 criteria. The 'message' field below SHOULD 2615 indicate both what image the device is currently 2616 running as well as the criteria that failed."; 2617 } 2618 enum image-download-error { 2619 description 2620 "Indicates that the device had an issue downloading 2621 the image, which could be anything from the file 2622 server being unreachable to the downloaded file 2623 being the incorrect file (signature mismatch). The 2624 'message' field about SHOULD indicate the specific 2625 error. This message also indicates that the device 2626 has abandoned trying to bootstrap off this bootstrap 2627 server."; 2629 } 2630 enum config-warning { 2631 description 2632 "Indicates that the device obtained warning messages 2633 when it committed the initial configuration. The 2634 'message' field below SHOULD indicate the warning 2635 messages that were generated."; 2636 } 2637 enum config-error { 2638 description 2639 "Indicates that the device obtained error messages 2640 when it committed the initial configuration. The 2641 'message' field below SHOULD indicate the error 2642 messages that were generated. This message also 2643 indicates that the device has abandoned trying to 2644 bootstrap off this bootstrap server."; 2645 } 2646 enum script-warning { 2647 description 2648 "Indicates that the device obtained a greater than 2649 zero exit status code from the script when it was 2650 executed. The 'message' field below SHOULD indicate 2651 both the resulting exit status code and well as 2652 capture any stdout/stderr messages the script may 2653 have produced."; 2654 } 2655 enum script-error { 2656 description 2657 "Indicates that the device obtained a less than zero 2658 exit status code from the script when it was executed. 2659 The 'message' field below SHOULD indicate both the 2660 resulting exit status code and well as capture any 2661 stdout/stderr messages the script may have produced. 2662 This message also indicates that the device has 2663 abandoned trying to bootstrap off this bootstrap 2664 server."; 2665 } 2666 enum bootstrap-complete { 2667 description 2668 "Indicates that the device successfully processed the 2669 all the bootstrapping data and that it is ready to 2670 be managed. The 'message' field below SHOULD contain 2671 any additional information that the manufacturer 2672 thinks might be useful, or omitted entirely. At 2673 this point, the device is not expected to access 2674 the bootstrap server again."; 2675 } 2676 enum informational { 2677 description 2678 "Provided any additional information not captured by 2679 any of the other notification-type. The 'message' 2680 field below SHOULD contain any additional information 2681 that the manufacturer thinks might be useful, or 2682 omitted entirely."; 2683 } 2684 } 2685 mandatory true; 2686 description 2687 "The type of notification provided."; 2688 } 2689 leaf message { 2690 type string; 2691 description 2692 "An optional human-readable value."; 2693 } 2694 container ssh-host-keys { 2695 description 2696 "A list of SSH host keys an NMS may use to authenticate 2697 a NETCONF connection to the device with."; 2698 list ssh-host-key { 2699 when "../type = bootstrap-complete" { 2700 description 2701 "SSH host keys are only sent when the notification 2702 type is 'bootstrap-complete'."; 2703 } 2704 description 2705 "An SSH host-key"; 2706 leaf format { 2707 type enumeration { 2708 enum ssh-dss { description "ssh-dss"; } 2709 enum ssh-rsa { description "ssh-rsa"; } 2710 } 2711 mandatory true; 2712 description 2713 "The format of the SSH host key."; 2714 } 2715 leaf key-data { 2716 type string; 2717 mandatory true; 2718 description 2719 "The key data for the SSH host key"; 2720 } 2721 } 2722 } 2723 container trust-anchors { 2724 description 2725 "A list of trust anchor certificates an NMS may use to 2726 authenticate a NETCONF or RESTCONF connection to the 2727 device with."; 2728 list trust-anchor { 2729 when "../type = bootstrap-complete" { 2730 description 2731 "Trust anchors are only sent when the notification 2732 type is 'bootstrap-complete'."; 2733 } 2734 description 2735 "A list of trust anchor certificates an NMS may use to 2736 authenticate a NETCONF or RESTCONF connection to the 2737 device with."; 2738 leaf-list protocol { 2739 type enumeration { 2740 enum netconf-ssh { description "netconf-ssh"; } 2741 enum netconf-tls { description "netconf-tls"; } 2742 enum restconf-tls { description "restconf-tls"; } 2743 enum netconf-ch-ssh { description "netconf-ch-ssh"; } 2744 enum netconf-ch-tls { description "netconf-ch-tls"; } 2745 enum restconf-ch-tls { description "restconf-ch-tls"; } 2746 } 2747 min-elements 1; 2748 description 2749 "The protocols that this trust anchor secures."; 2750 } 2751 leaf certificate { 2752 type binary; 2753 mandatory true; 2754 description 2755 "An X.509 v3 certificate structure as specified by RFC 2756 5280, Section 4 encoded using the ASN.1 distinguished 2757 encoding rules (DER), as specified in ITU-T X.690."; 2758 reference 2759 "RFC 5280: 2760 Internet X.509 Public Key Infrastructure Certificate 2761 and Certificate Revocation List (CRL) Profile. 2762 ITU-T X.690: 2763 Information technology - ASN.1 encoding rules: 2764 Specification of Basic Encoding Rules (BER), 2765 Canonical Encoding Rules (CER) and Distinguished 2766 Encoding Rules (DER)."; 2767 } 2768 } 2769 } 2770 } 2771 } // end action 2773 } 2774 } 2775 } 2777 2779 8. Security Considerations 2781 8.1. Immutable storage for trust anchors 2783 Devices MUST ensure that all their trust anchor certificates, 2784 including those for the owner certificate and ownership voucher, are 2785 protected from external modification. 2787 It may be necessary to update these certificates over time (e.g., the 2788 manufacturer wants to delegate trust to a new CA). It is therefore 2789 expected that devices MAY update these trust anchors when needed 2790 through a verifiable process, such as a software upgrade using signed 2791 software images. 2793 8.2. Clock Sensitivity 2795 The solution in this document relies on TLS certificates, owner 2796 certificates, ownership vouchers, and CRLs, all of which require an 2797 accurate clock in order to be processed correctly. Devices 2798 implementations should take care to ensure the devices have a 2799 reliable clock when processing signed data, ideally be using a built- 2800 in real time clock (RTC). If a device does not have an RTC, then it 2801 SHOULD try to use NTP to initialize its clock before processing any 2802 time-sensitive bootstrapping data. It is understood that NTP is 2803 itself unsecured, not enabling the client to authenticate the server, 2804 and therefore easily spoofed. In the case that NTP is spoofed, it is 2805 possible for a replay attack to occur where an ownership voucher 2806 assignment from a previous owner is replayed on a device that has 2807 since been claimed by a new owner. For this reason, for devices that 2808 do not contain an RTC, it is RECOMMENDED that manufacturers only 2809 issue a single ownership voucher for the lifetime of a device. 2811 8.3. Blindly authenticating a bootstrap server 2813 This document allows a device to blindly authenticate a bootstrap 2814 server's TLS certificate. It does so to allow for cases where the 2815 redirect information may be obtained in an unsecured manner (e.g., 2816 via a DNS service discovery lookup, where only a hostname or IP 2817 address is returned). 2819 To compensate for this, this document requires that devices do not 2820 send their IDevID certificate for client authentication, and that 2821 they do not POST any progress notifications, and that they assert 2822 that data downloaded from the server is signed, just as bootstrapping 2823 data would need to be signed if read from a removable storage device. 2825 8.4. Entropy loss over time 2827 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 2828 IDevID certificate should never expire (i.e. having a notAfter 2829 99991231235959Z). Given the long-lived nature of these certificates, 2830 it is paramount to use a strong key length (e.g., 512-bit ECC). 2832 8.5. Serial Numbers 2834 This draft suggests using the device's serial number as the unique 2835 identifier in its IDevID certificate. This is because serial numbers 2836 are ubiquitous and prominently contained in invoices and on labels 2837 affixed to devices and their packaging. That said, serial numbers 2838 many times encode revealing information, such as the device's model 2839 number, manufacture date, and/or sequence number. Knowledge of this 2840 information may provide an adversary with details needed to launch an 2841 attack. 2843 9. IANA Considerations 2845 Editor Note: this section needs to be rewritten to use the redirect 2846 and bootstrap information types (see Section 3). 2848 9.1. Zero Touch Redirect Information DHCP Options 2850 The following registrations are in accordance to RFC 2939 [RFC2939] 2851 for "BOOTP Manufacturer Extensions and DHCP Options" registry 2852 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 2854 9.1.1. DHCP v4 Option 2855 Tag: XXX 2857 Name: Zero Touch Redirect Information 2859 Returns a YANG-defined redirect-information object, encoded in 2860 the encoding specified by 'encoding'. Currently only "xml" 2861 and "json" are supported. 2863 Code Len 2864 +-----+-----+----------+---------------------+ 2865 | XXX | n | encoding |redirect-information | 2866 +-----+-----+----------+---------------------+ 2868 Reference: RFC XXXX 2870 9.1.2. DHCP v6 Option 2872 Tag: YYY 2874 Name: Zero Touch Redirect Information 2876 Returns a YANG-defined redirect-information object, encoded in 2877 the encoding specified by 'encoding'. Currently only "xml" 2878 and "json" are supported. 2880 Code Len 2881 +-----+-----+----------+---------------------+ 2882 | XXX | n | encoding |redirect-information | 2883 +-----+-----+----------+---------------------+ 2885 Reference: RFC XXXX 2887 10. Other Considerations 2889 Both this document and [draft-pritikin-anima-bootstrapping-keyinfra] 2890 define bootstrapping mechanisms. The authors have collaborated on 2891 both solutions and believe that each solution has merit and, in fact, 2892 can work together. That is, it is possible for a device to support 2893 both solutions simultaneously. 2895 11. Acknowledgements 2897 The authors would like to thank for following for lively discussions 2898 on list and in the halls (ordered by last name): David Harrington, 2899 Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, 2900 Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, Russ 2901 Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael 2902 Richardson, Juergen Schoenwaelder. 2904 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 2905 brainstorming the original I-D's solution during the IETF 87 meeting 2906 in Berlin. 2908 12. References 2910 12.1. Normative References 2912 [draft-ietf-netconf-call-home] 2913 Watsen, K., "NETCONF Call Home (work in progress)", draft- 2914 ieft-netconf-restconf-10 (work in progress), December 2915 2015, . 2918 [draft-ietf-netconf-restconf] 2919 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2920 Protocol", draft-ieft-netconf-restconf-10 (work in 2921 progress), 2016, . 2924 [draft-ietf-netconf-server-model] 2925 Watsen, K., "NETCONF Server Model (work in progress)", 2926 draft-ieft-netconf-server-model-09 (work in progress), 2927 March 2016, . 2930 [RFC1035] Mockapetris, P., "Domain names - implementation and 2931 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2932 November 1987, . 2934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2935 Requirement Levels", BCP 14, RFC 2119, 2936 DOI 10.17487/RFC2119, March 1997, 2937 . 2939 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 2940 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 2941 . 2943 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2944 specifying the location of services (DNS SRV)", RFC 2782, 2945 DOI 10.17487/RFC2782, February 2000, 2946 . 2948 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2949 Housley, R., and W. Polk, "Internet X.509 Public Key 2950 Infrastructure Certificate and Certificate Revocation List 2951 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2952 . 2954 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2955 the Network Configuration Protocol (NETCONF)", RFC 6020, 2956 DOI 10.17487/RFC6020, October 2010, 2957 . 2959 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2960 Verification of Domain-Based Application Service Identity 2961 within Internet Public Key Infrastructure Using X.509 2962 (PKIX) Certificates in the Context of Transport Layer 2963 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2964 2011, . 2966 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2967 DOI 10.17487/RFC6762, February 2013, 2968 . 2970 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2971 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2972 . 2974 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2975 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2976 . 2978 [Std-802.1AR-2009] 2979 IEEE SA-Standards Board, "IEEE Standard for Local and 2980 metropolitan area networks - Secure Device Identity", 2981 December 2009, . 2984 12.2. Informative References 2986 [draft-pritikin-anima-bootstrapping-keyinfra] 2987 Pritikin, M., Behringer, M., and S. Bjarnason, 2988 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 2989 bootstrapping-keyinfra-03 (work in progress), 2016, 2990 . 2993 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 2994 of New DHCP Options and Message Types", BCP 43, RFC 2939, 2995 DOI 10.17487/RFC2939, September 2000, 2996 . 2998 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2999 and A. Bierman, Ed., "Network Configuration Protocol 3000 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3001 . 3003 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3004 of Named Entities (DANE) Transport Layer Security (TLS) 3005 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3006 2012, . 3008 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 3009 System Management", RFC 7317, DOI 10.17487/RFC7317, August 3010 2014, . 3012 Appendix A. Examples 3014 A.1. Ownership Voucher 3016 Following describes an example data-model for an ownership voucher. 3017 Real vouchers are expected to be encoded in a manufacturer-specific 3018 format outside the of scope for this draft. 3020 A tree diagram describing an ownership voucher: 3022 module: ietf-zerotouch-ownership-voucher 3023 +--rw voucher 3024 +--rw owner-id string 3025 +--rw unique-id* string 3026 +--rw created-on yang:date-and-time 3027 +--rw expires-on? yang:date-and-time 3028 +--rw signature string 3030 The YANG module for this example voucher: 3032 file "ietf-zerotouch-ownership-voucher@2016-03-16.yang" 3034 module ietf-zerotouch-ownership-voucher { 3036 namespace 3037 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher"; 3038 prefix "ztov"; 3040 import ietf-yang-types { prefix yang; } 3042 organization 3043 "IETF NETCONF (Network Configuration) Working Group"; 3045 contact 3046 "WG Web: 3047 WG List: 3048 WG Chair: Mehmet Ersue 3049 3050 WG Chair: Mahesh Jethanandani 3051 3052 Editor: Kent Watsen 3053 "; 3055 description 3056 "This module defines the format for a ZeroTouch ownership voucher, 3057 which is produced by Vendors, relayed by Bootstrap Servers, and 3058 consumed by devices. The purpose of the voucher is to enable a 3059 device to ascertain the identity of its rightful owner, as 3060 certified by its Vendor. 3062 Copyright (c) 2014 IETF Trust and the persons identified as 3063 authors of the code. All rights reserved. 3065 Redistribution and use in source and binary forms, with or 3066 without modification, is permitted pursuant to, and subject 3067 to the license terms contained in, the Simplified BSD 3068 License set forth in Section 4.c of the IETF Trust's 3069 Legal Provisions Relating to IETF Documents 3070 (http://trustee.ietf.org/license-info). 3072 This version of this YANG module is part of RFC XXXX; see 3073 the RFC itself for full legal notices."; 3075 revision "2016-03-16" { 3076 description 3077 "Initial version"; 3078 reference 3079 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 3080 } 3082 // top-level container 3083 container voucher { 3084 description 3085 "A voucher, containing the owner's identifier, a list of 3086 device's unique identifiers, information on when the 3087 voucher was created, when it might expire, and the 3088 vendor's signature over the above values."; 3089 leaf owner-id { 3090 type string; 3091 mandatory true; 3092 description 3093 "A Vendor-assigned value for the rightful owner of the 3094 devices enumerated by this voucher. The owner-id value 3095 must match the value in the owner-certificate below"; 3096 } 3097 leaf-list unique-id { 3098 type string; 3099 min-elements 1; 3100 description 3101 "The unique identifier (e.g., serial-number) for a device. 3102 The value must match the value in the device's IDevID 3103 certificate. A device uses this value to determine if 3104 the voucher applies to it."; 3105 } 3106 leaf created-on { 3107 type yang:date-and-time; 3108 mandatory true; 3109 description 3110 "The date this voucher was created"; 3111 } 3112 leaf expires-on { 3113 type yang:date-and-time; 3114 description 3115 "The date this voucher expires, if at all. Use of this 3116 value requires that the device has access to a trusted 3117 real time clock"; 3118 } 3119 leaf signature { 3120 type string; 3121 mandatory true; 3122 description 3123 "The signature over the concatenation of all the previous 3124 values"; 3125 } 3126 } 3127 } 3129 3131 Appendix B. Change Log 3133 B.1. ID to 00 3135 o Major structural update; the essence is the same. Most every 3136 section was rewritten to some degree. 3138 o Added a Use Cases section 3140 o Added diagrams for "Actors and Roles" and "NMS Precondition" 3141 sections, and greatly improved the "Device Boot Sequence" diagram 3143 o Removed support for physical presence or any ability for 3144 configlets to not be signed. 3146 o Defined the Zero Touch Information DHCP option 3148 o Added an ability for devices to also download images from 3149 configuration servers 3151 o Added an ability for configlets to be encrypted 3152 o Now configuration servers only have to support HTTP/S - no other 3153 schemes possible 3155 B.2. 00 to 01 3157 o Added boot-image and validate-owner annotations to the "Actors and 3158 Roles" diagram. 3160 o Fixed 2nd paragraph in section 7.1 to reflect current use of 3161 anyxml. 3163 o Added encrypted and signed-encrypted examples 3165 o Replaced YANG module with XSD schema 3167 o Added IANA request for the Zero Touch Information DHCP Option 3169 o Added IANA request for media types for boot-image and 3170 configuration 3172 B.3. 01 to 02 3174 o Replaced the need for a configuration signer with the ability for 3175 each NMS to be able to sign its own configurations, using 3176 manufacturer signed ownership vouchers and owner certificates. 3178 o Renamed configuration server to bootstrap server, a more 3179 representative name given the information devices download from 3180 it. 3182 o Replaced the concept of a configlet by defining a southbound 3183 interface for the bootstrap server using YANG. 3185 o Removed the IANA request for the boot-image and configuration 3186 media types 3188 B.4. 02 to 03 3190 o Minor update, mostly just to add an Editor's Note to show how this 3191 draft might integrate with the draft-pritikin-anima-bootstrapping- 3192 keyinfra. 3194 B.5. 03 to 04 3196 o Major update formally introducing unsigned data and support for 3197 Internet-based redirect servers. 3199 o Added many terms to Terminology section. 3201 o Added all new "Guiding Principles" section. 3203 o Added all new "Sources for Bootstrapping Data" section. 3205 o Rewrote the "Interactions" section and renamed it "Workflow 3206 Overview". 3208 B.6. 04 to 05 3210 o Semi-major update, refactoring the document into more logical 3211 parts 3213 o Created new section for information types 3215 o Added support for DNS servers 3217 o Now allows provisional TLS connections 3219 o Bootstrapping data now supports scripts 3221 o Device Details section overhauled 3223 o Security Considerations expanded 3225 o Filled in enumerations for notification types 3227 B.7. 05 to 06 3229 o Minor update 3231 o Added a bunch of references. 3233 o Added new section Other Considerations. 3235 Authors' Addresses 3237 Kent Watsen 3238 Juniper Networks 3240 EMail: kwatsen@juniper.net 3242 Mikael Abrahamsson 3243 T-Systems 3245 EMail: "mikael.abrahamsson@t-systems.se