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