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