idnits 2.17.1 draft-ietf-netconf-zerotouch-12.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 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1645 has weird spacing: '...on-type enu...' == Line 1650 has weird spacing: '...ey-data str...' == Line 1654 has weird spacing: '...ificate bin...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 11, 2017) is 2662 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) == Unused Reference: 'RFC7468' is defined on line 2517, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Abrahamsson 5 Expires: July 15, 2017 T-Systems 6 January 11, 2017 8 Zero Touch Provisioning for NETCONF or RESTCONF based Management 9 draft-ietf-netconf-zerotouch-12 11 Abstract 13 This draft presents a secure technique for establishing a NETCONF or 14 RESTCONF connection between a newly deployed device, configured with 15 just its factory default settings, and its deployment specific 16 network management system (NMS). 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. Please note 23 that no other RFC Editor instructions are specified anywhere else in 24 this document. 26 This document contains references to other drafts in progress, both 27 in the Normative References section, as well as in body text 28 throughout. Please update the following references to reflect their 29 final RFC assignments: 31 o draft-ietf-netconf-call-home 33 o draft-ietf-netconf-restconf 35 o draft-ieft-netconf-server-model 37 o draft-ietf-anima-bootstrapping-keyinfra 39 Artwork in this document contains shorthand references to drafts in 40 progress. Please apply the following replacements: 42 o "XXXX" --> the assigned RFC value for this draft 44 Artwork in this document contains placeholder values for the date of 45 publication of this draft. Please apply the following replacement: 47 o "2017-01-11" --> the publication date of this draft 48 The following one Appendix section is to be removed prior to 49 publication: 51 o Appendix A. Change Log 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on July 15, 2017. 70 Copyright Notice 72 Copyright (c) 2017 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 88 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 89 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 90 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 91 1.4. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 7 92 2. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 7 93 2.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 7 94 2.2. Conveying Trust . . . . . . . . . . . . . . . . . . . . . 7 95 2.3. Conveying Ownership . . . . . . . . . . . . . . . . . . . 8 97 3. Types of Information . . . . . . . . . . . . . . . . . . . . 9 98 3.1. Redirect Information . . . . . . . . . . . . . . . . . . 9 99 3.2. Bootstrap Information . . . . . . . . . . . . . . . . . . 10 100 4. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 4.1. Information Type . . . . . . . . . . . . . . . . . . . . 11 102 4.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 11 103 4.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 11 104 4.4. Owner Certificate . . . . . . . . . . . . . . . . . . . . 12 105 4.5. Voucher Revocation . . . . . . . . . . . . . . . . . . . 13 106 4.6. Certificate Revocation . . . . . . . . . . . . . . . . . 13 107 5. Artifact Groupings . . . . . . . . . . . . . . . . . . . . . 15 108 5.1. Unsigned Information . . . . . . . . . . . . . . . . . . 15 109 5.2. Signed Information (without Revocations) . . . . . . . . 15 110 5.3. Signed Information (with Revocations) . . . . . . . . . . 16 111 6. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 16 112 6.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 16 113 6.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 18 114 6.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 19 115 6.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 20 116 7. Workflow Overview . . . . . . . . . . . . . . . . . . . . . . 22 117 7.1. Onboarding and Ordering Devices . . . . . . . . . . . . . 22 118 7.2. Owner Stages the Network for Bootstrap . . . . . . . . . 25 119 7.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 27 120 8. Device Details . . . . . . . . . . . . . . . . . . . . . . . 29 121 8.1. Factory Default State . . . . . . . . . . . . . . . . . . 29 122 8.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 30 123 8.3. Processing a Source of Bootstrapping Data . . . . . . . . 31 124 8.4. Validating Signed Data . . . . . . . . . . . . . . . . . 32 125 8.5. Processing Redirect Information . . . . . . . . . . . . . 33 126 8.6. Processing Bootstrap Information . . . . . . . . . . . . 34 127 9. RESTCONF API for Bootstrap Servers . . . . . . . . . . . . . 35 128 9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 35 129 9.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 37 130 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 131 10.1. Immutable storage for trust anchors . . . . . . . . . . 50 132 10.2. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 50 133 10.3. Blindly authenticating a bootstrap server . . . . . . . 50 134 10.4. Entropy loss over time . . . . . . . . . . . . . . . . . 51 135 10.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 51 136 10.6. Sequencing Sources of Bootstrapping Data . . . . . . . . 51 137 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 138 11.1. The BOOTP Manufacturer Extensions and DHCP Options 139 Registry . . . . . . . . . . . . . . . . . . . . . . . . 51 140 11.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 51 141 11.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 52 142 11.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 53 143 11.3. The YANG Module Names Registry . . . . . . . . . . . . . 53 144 12. Other Considerations . . . . . . . . . . . . . . . . . . . . 53 145 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 146 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 147 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 148 14.2. Informative References . . . . . . . . . . . . . . . . . 55 149 Appendix A. API Examples . . . . . . . . . . . . . . . . . . . . 57 150 A.1. Unsigned Redirect Information . . . . . . . . . . . . . . 57 151 A.2. Signed Redirect Information . . . . . . . . . . . . . . . 58 152 A.3. Unsigned Bootstrap Information . . . . . . . . . . . . . 61 153 A.4. Signed Bootstrap Information . . . . . . . . . . . . . . 63 154 A.5. Progress Notifications . . . . . . . . . . . . . . . . . 67 155 Appendix B. Artifact Examples . . . . . . . . . . . . . . . . . 69 156 B.1. Redirect Information . . . . . . . . . . . . . . . . . . 69 157 B.2. Bootstrap Information . . . . . . . . . . . . . . . . . . 71 158 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72 159 C.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 72 160 C.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 73 161 C.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 73 162 C.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 73 163 C.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 73 164 C.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 74 165 C.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 74 166 C.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 74 167 C.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 74 168 C.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 75 169 C.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 75 170 C.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 75 171 C.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 76 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 174 1. Introduction 176 A fundamental business requirement for any network operator is to 177 reduce costs where possible. For network operators, deploying 178 devices to many locations can be a significant cost, as sending 179 trained specialists to each site to do installations is both cost 180 prohibitive and does not scale. 182 This document defines a bootstrapping strategy enabling devices to 183 securely obtain bootstrapping data with no installer input, beyond 184 physical placement and connecting network and power cables. The 185 ultimate goal of this document is to enable a secure NETCONF 186 [RFC6241] or RESTCONF [draft-ietf-netconf-restconf] connection to the 187 deployment specific network management system (NMS). 189 1.1. Use Cases 191 o Connecting to a remotely administered network 193 This use-case involves scenarios, such as a remote branch 194 office or convenience store, whereby a device connects as an 195 access gateway to an ISP's network. Assuming it is not 196 possible to customize the ISP's network to provide any 197 bootstrapping support, and with no other nearby device to 198 leverage, the device has no recourse but to reach out to an 199 Internet-based bootstrap server to bootstrap off of. 201 o Connecting to a locally administered network 203 This use-case covers all other scenarios and differs only in 204 that the device may additionally leverage nearby devices, which 205 may direct it to use a local service to bootstrap off of. If 206 no such information is available, or the device is unable to 207 use the information provided, it can then reach out to network 208 just as it would for the remotely administered network use- 209 case. 211 1.2. Terminology 213 This document uses the following terms: 215 Artifact: The term "artifact" is used throughout to represent the 216 any of the six artifacts defined in Section 4. These artifacts 217 collectively provide all the bootstrapping data a device needs. 219 Bootstrapping Data: The term "bootstrapping data" is used throughout 220 this document to refer to the collection of data that a device 221 may obtain from any source of bootstrapping data. Specifically, 222 it refers to the artifacts defined in Section 4. 224 Bootstrap Information: The term "bootstrap information" is used 225 herein to refer to one of the bootstrapping artifacts defined in 226 Section 4. Specifically, bootstrap information is the 227 bootstrapping data that guides a device to, for instance, install 228 a specific boot-image and commit a specific configuration. 230 Bootstrap Server: The term "bootstrap server" is used within this 231 document to mean any RESTCONF server implementing the YANG module 232 defined in Section 9.2. 234 Device: The term "device" is used throughout this document to refer 235 to the network element that needs to be bootstrapped. See 236 Section 8 for more information about devices. 238 Initial Secure Device Identifier (IDevID): The term "IDevID" is 239 defined in [Std-802.1AR-2009] as the secure device identifier 240 (DevID) installed on the device by the manufacturer. This 241 identifier is used in this document to enable a Bootstrap Server 242 to securely identify and authenticate a device. 244 Manufacturer: The term "manufacturer is used herein to refer to the 245 manufacturer of a device or a delegate of the manufacturer. 247 Network Management System (NMS): The acronym "NMS" is used 248 throughout this document to refer to the deployment specific 249 management system that the bootstrapping process is responsible 250 for introducing devices to. From a device's perspective, when 251 the bootstrapping process has completed, the NMS is a NETCONF or 252 RESTCONF client. 254 Owner: See Rightful Owner. 256 Redirect Information: The term "bootstrap information" is used 257 herein to refer to one of the bootstrapping artifacts defined in 258 Section 4. Specifically, redirect information is the 259 bootstrapping data that directs a device to connect to a 260 bootstrap server. 262 Redirect Server: The term "redirect server" is used to refer to a 263 subset of bootstrap servers that only returns redirect 264 information. A redirect server is particularly useful when 265 hosted by a manufacturer, to redirect devices to deployment- 266 specific bootstrap servers. 268 Rightful Owner: The term "rightful owner" is used herein to refer to 269 the person or organization that purchased or otherwise owns a 270 device. Ownership is further described in Section 2.3. 272 Signed Data: The term "signed data" is used throughout to mean 273 either redirect information or bootstrap information that has 274 been signed by a device's rightful owner's private key. 276 Unsigned Data: The term "unsigned data" is used throughout to mean 277 either redirect rnformation or bootstrap information that has not 278 been signed by a device's rightful owner's private key. 280 1.3. Requirements Language 282 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 283 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 284 sections below are to be interpreted as described in RFC 2119 285 [RFC2119]. 287 1.4. Tree Diagram Notation 289 A simplified graphical representation of the data models is used in 290 this document. The meaning of the symbols in these diagrams is as 291 follows: 293 o Brackets "[" and "]" enclose list keys. 295 o Braces "{" and "}" enclose feature names, and indicate that the 296 named feature must be present for the subtree to be present. 298 o Abbreviations before data node names: "rw" (read-write) represents 299 configuration data and "ro" (read-only) represents state data. 301 o Symbols after data node names: "?" means an optional node, "!" 302 means a presence container, and "*" denotes a list and leaf-list. 304 o Parentheses enclose choice and case nodes, and case nodes are also 305 marked with a colon (":"). 307 o Ellipsis ("...") stands for contents of subtrees that are not 308 shown. 310 2. Guiding Principles 312 This section provides overarching principles guiding the solution 313 presented in this document. 315 2.1. Trust Anchors 317 A trust anchor is used in cryptography to represent an entity in 318 which trust is implicit and not derived. In public key 319 infrastructure using X.509 certificates, a root certificate is the 320 trust anchor, from which a chain of trust is derived. The solution 321 presented in this document requires that all the entities involved 322 (e.g., devices, bootstrap servers, NMSs) possess specific trust 323 anchors in order to ensure mutual authentication throughout the zero 324 touch bootstrapping process. 326 2.2. Conveying Trust 328 A device in its factory default state possesses a limited set of 329 manufacturer specified trust anchors. In this document, there are 330 two types of trust anchors of interest. The first type of trust 331 anchor is used to authenticate a secure (e.g., HTTPS) connection to, 332 for instance, a manufacturer-hosted Internet-based bootstrap server. 333 The second type of trust anchor is used to authenticate manufacturer- 334 signed data, such as the ownership voucher artifact described in 335 Section 4.3. 337 Using the first type of trust anchor, trust is conveyed by the device 338 first authenticating the server (e.g., a bootstrap server), and then 339 by the device trusting that the server would only provide data that 340 its rightful owner staged for it to find. Thereby the device can 341 trust any information returned from the server. 343 Using the second type of trust anchor, trust is conveyed by the 344 device first authenticating that an artifact has been signed by its 345 rightful owner, and thereby can trust any information held within the 346 artifact. 348 Notably, redirect information, as described in Section 3.1, may 349 include more trust anchors, which illustrates another way in which 350 trust can be conveyed. 352 2.3. Conveying Ownership 354 The ultimate goal of this document is to enable a device to establish 355 a secure connection with its rightful owner's NMS. This entails the 356 manufacturer being able to track who is the rightful owner of a 357 device (not defined in this document), as well as an ability to 358 convey that information to devices (defined in this document). 360 Matching the two ways to convey trust (Section 2.2), this document 361 provides two ways to convey ownership, by using a trusted bootstrap 362 server (Section 6.4) or by using an ownership voucher (Section 4.3). 364 When a device connects to a trusted bootstrap server, one that was 365 preconfigured into its factory default configuration, it implicitly 366 trusts that the bootstrap server would only provide data that its 367 rightful owner staged for it to find. That is, ownership is conveyed 368 by the administrator of the bootstrap server (e.g., a manufacturer) 369 taking the onus of ensuring that only data configured by a device's 370 rightful owner is made available to the device. With this approach, 371 the assignment of a device to an owner is ephemeral, as the 372 administrator can reassign a device to another owner at any time. 374 When a device is presented signed bootstrapping data, it can 375 authenticate that its rightful owner provided the data by verifying 376 the signature over the data using an additional artifact defined 377 within this document, the ownership voucher. With this approach, 378 ownership is conveyed by the manufacturer (or delegate) taking the 379 onus of ensuring that the ownership vouchers it issues are accurate 380 and, in some cases, also ensuring timely voucher revocations 381 (Section 4.5). 383 3. Types of Information 385 This document defines two types of information, redirect information 386 and bootstrap information, that devices access during the 387 bootstrapping process. These two types of information are described 388 in this section. 390 3.1. Redirect Information 392 Redirect information provides information to redirect a device to a 393 bootstrap server. Redirect information encodes a list of bootstrap 394 servers, each defined by its hostname or IP address, an optional 395 port, and an optional trust anchor certificate. 397 Redirect information is YANG modeled data formally defined by the 398 "redirect-information" grouping in the YANG module presented in 399 Section 9.2. This grouping has the tree diagram shown below. Please 400 see Section 1.4 for tree diagram notation. 402 +--:(redirect-information) 403 +--ro redirect-information 404 +--ro bootstrap-server* [address] 405 +--ro address inet:host 406 +--ro port? inet:port-number 407 +--ro trust-anchor? binary 409 Redirect information MAY be trusted or untrusted. The redirect 410 information is trusted whenever it is obtained via a secure 411 connection to a trusted bootstrap server, or whenever it is signed by 412 the device's rightful owner. In all other cases, the redirect 413 information is untrusted. 415 Trusted redirect information is useful for enabling a device to 416 establish a secure connection to a bootstrap server, which is 417 possible when the redirect information includes the bootstrap 418 server's trust anchor certificate. When a device is able to 419 establish a secure connection to a bootstrap server, the 420 bootstrapping data does not have to be signed in order to be trusted, 421 as described in Section 2.2. 423 Untrusted redirect information is useful for directing a device to a 424 bootstrap server where signed data has been staged for it to obtain. 425 When the redirect information is untrusted, the device MUST discard 426 any potentially included trust anchor certificates. When the 427 redirect information is untrusted, a device MAY establish a 428 provisional connection to any of the specified bootstrap servers. A 429 provisional connection is accomplished by the device blindly 430 accepting the bootstrap server's TLS certificate. In this case, the 431 device MUST NOT trust the bootstrap server, and data provided by the 432 bootstrap server MUST be signed for it to be of any use to the 433 device. 435 How devices process redirect information is described more formally 436 in Section 8.5. 438 3.2. Bootstrap Information 440 Bootstrap information provides all the data necessary for a device to 441 bootstrap itself, in order to be considered ready to be managed 442 (e.g., by an NMS). As defined in this document, this data includes 443 information about a boot image the device MUST be running, an initial 444 configuration the device MUST commit, and optional scripts that, if 445 specified, the device MUST successfully execute. 447 Bootstrap information is YANG modeled data formally defined by the 448 "bootstrap-information" grouping in the YANG module presented in 449 Section 9.2. This grouping has the tree diagram shown below. Please 450 see Section 1.4 for tree diagram notation. 452 +--:(bootstrap-information) 453 +--ro bootstrap-information 454 +--ro boot-image 455 | +--ro name string 456 | +--ro (hash-algorithm) 457 | | +--:(sha256) 458 | | +--ro sha256? string 459 | +--ro uri* inet:uri 460 +--ro configuration-handling enumeration 461 +--ro pre-configuration-script? script 462 +--ro configuration? 463 +--ro post-configuration-script? script 465 Bootstrap information MUST be trusted for it to be of any use to a 466 device. There is no option for a device to process untrusted 467 bootstrap information. 469 Bootstrap information is trusted whenever it is obtained via a secure 470 connection to a trusted bootstrap server, or whenever it is signed by 471 the device's rightful owner. In all other cases, the bootstrap 472 information is untrusted. 474 How devices process bootstrap information is described more formally 475 in Section 8.6. 477 4. Artifacts 479 This document defines six artifacts that can be made available to 480 devices while they are bootstrapping. As will be seen in Section 6, 481 each source of bootstrapping information specifies a means for 482 providing each of the artifacts defined in this section. 484 4.1. Information Type 486 The information type artifact encodes the essential bootstrapping 487 data for the device. This artifact is used to encode the redirect 488 information and bootstrap information types discussed in Section 3. 490 The information type artifact is YANG modeled data formally defined 491 by the "information-type" choice node in Section 9.2 and can be 492 encoded using any standard YANG encoding (e.g., XML, JSON). This 493 artifact is formatted the same as if returned by a RESTCONF server 494 for an HTTP GET request for the specific information-type resource. 495 Examples of this artifact's encoding are provided in Appendix B. 497 4.2. Signature 499 The signature artifact is used by a device to verify that an 500 information type artifact was created by the device's rightful owner. 501 The signature is generated using the owner's private key over the 502 information-type artifact, in whatever encoding it is presented in 503 (e.g., XML, JSON, etc.). How signed data is validated is formally 504 described in Section 8.4. 506 The signature artifact is formally a PKCS#7 SignedData structure as 507 specified by Section 9.1 of [RFC2315], containing just the signature 508 (no content, certificates, or CRLs), encoded using ASN.1 509 distinguished encoding rules (DER), as specified in ITU-T X.690. 511 4.3. Ownership Voucher 513 The ownership voucher is used to securely identify a device's owner, 514 as it is known to the manufacturer. The ownership voucher is signed 515 by the device's manufacturer or delegate. 517 The ownership voucher is used by a device to verify the owner 518 certificate (Section 4.4) that the device SHOULD have also received, 519 as described in Section 5. In particular, the device verifies that 520 owner certificate's chain of trust includes the trusted certificate 521 included in the voucher, and also verifies that the owner certificate 522 contains an identifier matching the one specified in the voucher. 524 In order to validate the voucher, a device MUST verify that the 525 voucher was signed by the private key associated with a trusted 526 certificate known to the device in its factory default state, as 527 described in Section 8.1, and the device MUST verify that the 528 voucher's expression for the devices that it applies to includes the 529 device's unique identifier (e.g., serial number) and, for devices 530 that insist on verifying voucher revocation status, the device MUST 531 verify that the voucher has neither expired nor been revoked. 533 The ownership voucher artifact, including its encoding, is formally 534 defined in [draft-kwatsen-netconf-voucher]. 536 4.4. Owner Certificate 538 The owner certificate artifact is a certificate that is used to 539 identify an 'owner' (e.g., an organization), as known to a trusted 540 certificate authority. The owner certificate is signed by the 541 trusted certificate authority. 543 The owner certificate is used by a device to verify the signature 544 artifact (Section 4.2) that the device SHOULD have also received, as 545 described in Section 5. In particular, the device verifies signature 546 using the public key in the owner certificate over the information 547 type artifact (Section 4.1). 549 In order to validate the owner certificate, a device MUST verify that 550 the owner certificate's certificate chain includes the certificate 551 specified by the ownership voucher (Section 4.3) that the device 552 SHOULD have also received, as described in Section 5, and the device 553 MUST verify that owner certificate contains an identifier matching 554 the one specified in the voucher and, for devices that insist on 555 verifying certificate revocation status, the device MUST verify that 556 the certificate has neither expired nor been revoked. 558 The owner certificate artifact is formally an unsigned PKCS #7 559 SignedData structure as specified by RFC 2315 [RFC2315], Section 9.1, 560 containing just certificates (no content, signatures, or CRLs), 561 encoded using ASN.1 distinguished encoding rules (DER), as specified 562 in ITU-T X.690. 564 The owner certificate artifact contains, in order, the owner 565 certificate itself and all intermediate certificates leading up to a 566 trust anchor certificate. The owner certificate MAY optionally 567 include the trust anchor certificate. 569 4.5. Voucher Revocation 571 The voucher revocation artifact is used to verify the revocation 572 status of vouchers. Voucher revocations are signed by the 573 manufacturer or delegate (i.e. the issuer of the voucher). 575 Voucher revocations are generally needed when it is critical for 576 devices to know that assurances implied at the time the voucher was 577 signed are still valid at the time the voucher is being processed. 579 The need for devices to insist on verifying voucher revocation status 580 is a decision for each manufacturer. If voucher revocation status 581 verification is not asserted, then the ownership vouchers are 582 essentially forever, which may be acceptable for various kinds of 583 devices. If revocations are supported, then it becomes possible to 584 support various scenarios such as handling a key compromise or change 585 in ownership. 587 If voucher revocations are supported, devices MAY dynamically obtain 588 the voucher revocation artifact (or equivalents) from an Internet 589 based resource. If the access to the Internet based resource is 590 sufficiently reliable, then there may not be a need for the voucher 591 revocation artifact to be supplied by any other means (e.g., 592 Section 6). However, since the access may not be sufficiently 593 reliable, support for this artifact is defined herein. 595 The voucher revocation artifact is used by a device to verify the 596 ownership voucher (Section 4.3) that the device SHOULD have also 597 received, as described in Section 5. In particular, the device 598 verifies that the voucher revocation explicitly states either that 599 the given voucher is valid or that it is not invalid. 601 In order to validate a voucher revocation artifact, a device MUST 602 verify that it was signed by a private key associated with a trusted 603 certificate known to the device in its factory default state, as 604 described in Section 8.1, and the device MUST verify that the voucher 605 revocation hasn't expired, and the device SHOULD verify that the 606 revocation is sufficiently fresh, per local policy. 608 The voucher revocation artifact, including its encoding, is formally 609 defined in [draft-kwatsen-netconf-voucher]. 611 4.6. Certificate Revocation 613 The certificate revocation artifact is a list of CRLS used to verify 614 the revocation status of owner certificates. Certificate revocations 615 are signed by the certificate authority (or delegate) that issued the 616 owner certificate. 618 Certificate revocations are generally needed when it is critical for 619 devices to know that assurances implied at the time the certificate 620 was signed are still valid at the time the certificate is being 621 processed. 623 The need for devices to insist on verifying certificate revocation 624 status is a decision for each manufacturer. If certificate 625 revocation status verification is not asserted, then the owner 626 certificates are essentially forever, which may be acceptable for 627 various kinds of devices. If revocations are supported, then it 628 becomes possible to support various scenarios such as handling a key 629 compromise or expiration. 631 If certificate revocations are supported, devices MAY dynamically 632 obtain the certificate revocation artifact from an Internet based 633 resource (using a CRL distribution point or an OCSP responder). If 634 the access to the Internet based resource is sufficiently reliable, 635 then there may not be a need for the certificate revocation artifact 636 to be supplied by any other means (e.g., Section 6). However, since 637 the access may not be sufficiently reliable, support for this 638 artifact is defined herein, so that the voucher revocation artifact 639 can be distributed by any source of bootstrapping data. 641 The certificate revocation artifact is used by a device to verify the 642 owner certificate (Section 4.4) that the device SHOULD have also 643 received, as described in Section 5. In particular, the device 644 verifies that the certificate revocation explicitly states either 645 that the given certificate is valid or that it is not invalid. 647 In order to validate the CRLs contained with the certificate 648 revocation artifact, a device MUST verify that the CRL was signed by 649 a private key associated certificate's issuer (or delegate), and the 650 device MUST verify that the CRL hasn't expired, and the device SHOULD 651 verify that the revocation is sufficiently fresh, per local policy. 653 The certificate revocation artifact is formally an unsigned PKCS #7 654 SignedData structure as specified by RFC 2315 [RFC2315], Section 9.1, 655 containing just CRLs (no content, signatures, or certificates), 656 encoded using ASN.1 distinguished encoding rules (DER), as specified 657 in ITU-T X.690. 659 The certificate revocation artifact contains, in order, the CRL for 660 the owner certificate itself and the CRLs for all intermediate 661 certificates leading up to but not including a trust anchor 662 certificate. 664 5. Artifact Groupings 666 Section 4 lists all the possible bootstrapping artifacts, but only 667 certain groupings of these artifacts make sense to return in the 668 various bootstrapping situations described in this document. The 669 remainder of this section identifies these groupings to further 670 clarify how the artifacts are used. 672 5.1. Unsigned Information 674 The first grouping of artifacts is for unsigned information. That 675 is, when the information type artifact (Section 4.1) has not been 676 signed. 678 Unsigned information is useful for cases when transport level 679 security can be used to convey trust (e.g., HTTPS), or when the 680 information can be processed in a provisional manner (i.e. unsigned 681 redirect information). 683 Conveying unsigned information entails communicating just one of the 684 six artifacts listed in Section 4, namely the information type 685 artifact. 687 List of artifacts included in this grouping: 688 - information type 690 5.2. Signed Information (without Revocations) 692 The second grouping of artifacts is for when the information type 693 artifact (Section 4.1) has been signed, without any revocation 694 information. 696 Signed information is needed when the information is obtained from an 697 untrusted source of bootstrapping data (Section 6) and yet it is 698 desired that the device be able to trust the information (i.e. no 699 provisional processing). 701 Revocation information may not need to be provided because, for 702 instance, the device only uses revocation information obtained 703 dynamically from Internet based resources. Another possible reason 704 may be because the device does not have a reliable clock, and 705 therefore the manufacturer decides to never revoke information (e.g., 706 ownership assignments are forever). 708 Conveying signed information without revocation information entails 709 communicating four of the six artifacts listed in Section 4. 711 List of artifacts included in this grouping: 712 - information type 713 - signature 714 - ownership voucher 715 - owner certificate 717 5.3. Signed Information (with Revocations) 719 The third grouping of artifacts is for when the information type 720 artifact (Section 4.1) has been signed and also includes revocation 721 information. 723 Signed information, as described above, is needed when the 724 information is obtained from an untrusted source of bootstrapping 725 data (Section 6) and yet it is desired that the device be able to 726 trust the information (i.e. no provisional processing). 728 Revocation information may need to be provided because, for instance, 729 the device insists on being able to verify revocations and the device 730 is deployed on a private network and therefore unable to obtain the 731 revocation information from Internet based resources. 733 Conveying signed information with revocation information entails 734 communicating all six of the artifacts listed in Section 4. 736 List of artifacts included in this grouping: 737 - information type 738 - signature 739 - ownership voucher 740 - owner certificate 741 - voucher revocations 742 - certificate revocations 744 6. Sources of Bootstrapping Data 746 This section defines some sources for zero touch bootstrapping data 747 that a device can access. The list of sources defined here is not 748 meant to be exhaustive. It is left to future documents to define 749 additional sources for obtaining zero touch bootstrapping data. 751 For each source defined in this section, details are given for how 752 each of the six artifacts listed in Section 4 is provided. 754 6.1. Removable Storage 756 A directly attached removable storage device (e.g., a USB flash 757 drive) MAY be used as a source of zero touch bootstrapping data. 759 To use a removable storage device as a source of bootstrapping data, 760 a device need only detect if the removable storage device is plugged 761 in and mount its filesystem. 763 Use of a removable storage device is compelling, as it doesn't 764 require any external infrastructure to work. It is also compelling 765 that the raw boot image file can be located on the removable storage 766 device, enabling a removable storage device to be a fully self- 767 standing bootstrapping solution. 769 A removable storage device is an untrusted source of bootstrapping 770 data. This means that the information stored on the removable 771 storage device either MUST be signed, or it MUST be information that 772 can be processed provisionally (e.g., unsigned redirect information). 774 From an artifact perspective, since a removable storage device 775 presents itself as a file-system, the bootstrapping artifacts need to 776 be presented as files. The six artifacts defined in Section 4 are 777 mapped to files below. 779 Artifact to File Mapping: 781 Information Type: Mapped to a file containing a standard YANG 782 encoding for the YANG modeled data described in Section 4.1. A 783 filenaming convention SHOULD be used to indicate data encoding 784 (e.g., boot-info.[xml|json]). 786 Signature: Mapped to a file containing the binary artifact 787 described in Section 4.2. 789 Ownership Voucher: Mapped to a file containing the binary 790 artifact described in Section 4.3. 792 Owner Certificate: Mapped to a file containing the binary 793 artifact described in Section 4.4. 795 Voucher Revocation: Mapped to a file containing the binary 796 artifact described in Section 4.5. 798 Certificate Revocation: Mapped to a file containing binary 799 artifact described in Section 4.6. 801 The format of the removable storage device's filesystem and the 802 naming of the files are outside the scope of this document. However, 803 in order to facilitate interoperability, it is RECOMMENDED devices 804 support open and/or standards based filesystems. It is also 805 RECOMMENDED that devices assume a filenaming convention that enables 806 more than one instance of bootstrapping data to exist on a removable 807 storage device. The filenaming convention SHOULD be unique to the 808 manufacturer, in order to enable bootstrapping data from multiple 809 manufacturers to exist on a removable storage device. 811 6.2. DNS Server 813 A DNS server MAY be used as a source of zero touch bootstrapping 814 data. 816 Using a DNS server may be a compelling option for deployments having 817 existing DNS infrastructure, as it enables a touchless bootstrapping 818 option that does not entail utilizing an Internet based resource 819 hosted by a 3rd-party. 821 To use a DNS server as a source of bootstrapping data, a device MAY 822 perform a multicast DNS [RFC6762] query searching for the service 823 "_zerotouch._tcp.local.". Alternatively the device MAY perform DNS- 824 SD [RFC6763] via normal DNS operation, using the domain returned to 825 it from the DHCP server; for example, searching for the service 826 "_zerotouch._tcp.example.com". 828 Unsigned DNS records (not using DNSSEC as described in [RFC6698]) are 829 an untrusted source of bootstrapping data. This means that the 830 information stored in the DNS records either MUST be signed, or it 831 MUST be information that can be processed provisionally (e.g., 832 unsigned redirect information). 834 From an artifact perspective, since a DNS server presents resource 835 records (Section 3.2.1 of [RFC1035]), the bootstrapping artifacts 836 need to be presented as resource records. The six artifacts defined 837 in Section 4 are mapped to resource records below. 839 Artifact to Resource Record Mapping: 841 Information Type: Mapped to a TXT record called "info-type" 842 containing a standard YANG encoding for the YANG modeled data 843 described in Section 4.1. Note: no additional field is 844 provided to specify the encoding. 846 Signature: Mapped to a TXT record called "sig" containing the 847 base64-encoding of the binary artifact described in 848 Section 4.2. 850 Ownership Voucher: Mapped to a TXT record called "voucher" 851 containing the base64-encoding of the binary artifact described 852 in Section 4.3. 854 Owner Certificate: Mapped to a TXT record called "cert" 855 containing the base64-encoding of the binary artifact described 856 in Section 4.4. 858 Voucher Revocation: Mapped to a TXT record called "vouch-rev" 859 containing the base64-encoding of the binary artifact described 860 in Section 4.5. 862 Certificate Revocation: Mapped to a TXT record called "cert-rev" 863 that containing the base64-encoding of the binary artifact 864 described in Section 4.6. 866 TXT records have an upper size limit of 65535 bytes (Section 3.2.1 in 867 RFC1035), since 'RDLENGTH' is a 16-bit field. Please see 868 Section 3.1.3 in RFC4408 for how a TXT record can achieve this size. 869 Due to this size limitation, some information type artifacts may not 870 fit. In particular, the bootstrap information artifact could hit 871 this upper bound, depending on the size of the included configuration 872 and scripts. 874 When bootstrap information is provided, it is notable that the URL 875 for the boot-image the device can download would have to point to 876 another server (e.g., http://, ftp://, etc.), as DNS servers do not 877 themselves distribute files. 879 6.3. DHCP Server 881 A DHCP server MAY be used as a source of zero touch bootstrapping 882 data. 884 To use a DHCP server as a source of bootstrapping data, a device need 885 only send a DHCP lease request to a DHCP server. However, the device 886 SHOULD pass the Vendor Class Identifier (option 60) field in its DHCP 887 lease request, so the DHCP server can return bootstrap information 888 shared by devices from the same vendor. However, if it is desired to 889 return device-specific bootstrap information, then the device SHOULD 890 also send the Client Identifier (option 61) field in its DHCP lease 891 request, so the DHCP server can select the specific bootstrap 892 information that has been staged for that one device. 894 Using a DHCP server may be a compelling option for deployments having 895 existing DHCP infrastructure, as it enables a touchless bootstrapping 896 option that does not entail utilizing an Internet based resource 897 hosted by a 3rd-party. 899 A DHCP server is an untrusted source of bootstrapping data. This 900 means that the information returned by the DHCP server either MUST be 901 signed, or it MUST be information that can be processed provisionally 902 (e.g., unsigned redirect information). 904 From an artifact perspective, since a DHCP server presents data as 905 DHCP options , the bootstrapping artifacts need to be presented as 906 DHCP options, specifically the ones specified in Section 11.1. The 907 six artifacts defined in Section 4 are mapped to the DHCP options 908 specified in Section 11.1 below. 910 Artifact to DHCP Option Field Mapping: 912 Information Type: Mapped to the DHCP option field "information- 913 type" containing the YANG modeled data described in 914 Section 4.1. The additional field "encoding" is provided to 915 specify the encoding used, taking the values "xml" or "json". 917 Signature: Mapped to the DHCP option field "signature" containing 918 the binary artifact described in Section 4.2. 920 Ownership Voucher: Mapped to the DHCP option field "ownership- 921 voucher" containing the binary artifact described in 922 Section 4.3. 924 Owner Certificate: Mapped to the DHCP option field "owner- 925 certificate" containing the binary artifact described in 926 Section 4.4. 928 Voucher Revocation: Mapped to the DHCP option field "voucher- 929 revocations" containing the binary artifact described in 930 Section 4.5. 932 Certificate Revocation: Mapped to the DHCP option field 933 "certificate-revocations" containing the binary artifact 934 described in Section 4.6. 936 When bootstrap information is provided, it is notable that the URL 937 for the boot-image the device can download would have to point to 938 another server (e.g., http://, ftp://, etc.), as DHCP servers do not 939 themselves distribute files. 941 6.4. Bootstrap Server 943 A bootstrap server MAY be used as a source of zero touch 944 bootstrapping data. A bootstrap server is defined as a RESTCONF 945 ([draft-ietf-netconf-restconf]) server implementing the YANG module 946 provided in Section 9. 948 Unlike any other source of bootstrap data described in this document, 949 a bootstrap server is not only a source of data, but it can also 950 receive data from devices using the YANG-defined "notification" 951 action statement defined in the YANG module (Section 9.2). The data 952 sent from devices both enables visibility into the bootstrapping 953 process (e.g., warnings and errors) as well as provides potentially 954 useful completion status information (e.g., the device's SSH host- 955 keys). 957 To use a bootstrap server as a source of bootstrapping data, a device 958 MUST use the RESTCONF protocol to access the YANG container node 959 /device/, passing its own serial number in the URL as the key to the 960 'device' list. 962 Using a bootstrap server as a source of bootstrapping data is a 963 compelling option as it uses transport-level security in lieu of 964 signed data, which may be easier to deploy in some situations. 965 Additionally, the bootstrap server is able to receive notifications 966 from devices, which may be critical to some deployments (e.g., the 967 passing of the device's SSH host keys). 969 A bootstrap server may be trusted or an untrusted source of 970 bootstrapping data, depending on how the device learned about the 971 bootstrap server's trust anchor from a trusted source. When a 972 bootstrap server is trusted, the information returned from it MAY be 973 signed. However, when the server is untrusted, in order for its 974 information to be of any use to the device, the information MUST 975 either be signed or be information that can be processed 976 provisionally (e.g., unsigned redirect information). 978 When a device is able to trust a bootstrap server, it MUST send its 979 IDevID certificate in the form of a TLS client certificate, and it 980 MUST send notifications to the bootstrap server. When a device is 981 not able to trust a bootstrap server, it MUST NOT send its IDevID 982 certificate in the form of a TLS client certificate, and it MUST NOT 983 send any notifications to the bootstrap server. 985 From an artifact perspective, since a bootstrap server presents data 986 as a YANG-modeled data, the bootstrapping artifacts need to be mapped 987 to nodes in the YANG module. The six artifacts defined in Section 4 988 are mapped to bootstrap server nodes defined in Section 9.2 below. 990 Artifact to Bootstrap Server Node Mapping: 992 Information Type: Mapped to the choice node /device/information- 993 type. 995 Signature: Mapped to the leaf node /device/signature. 997 Ownership Voucher: Mapped to the leaf node /device/ownership- 998 voucher. 1000 Owner Certificate: Mapped to the leaf node /device/owner- 1001 certificate. 1003 Voucher Revocations: Mapped to the leaf node /device/voucher- 1004 revocation. 1006 Certificate Revocations: Mapped to the leaf-list node /device/ 1007 certificate-revocation. 1009 While RESTCONF servers typically support a nested hierarchy of 1010 resources, zero touch bootstrap servers only need to support the 1011 paths /device and /device/notification. The processing instructions 1012 provided in Section 8.3 only uses these two URLs. 1014 7. Workflow Overview 1016 The zero touch solution presented in this document is conceptualized 1017 to be composed of the workflows described in this section. 1018 Implementations MAY vary in details. Each diagram is followed by a 1019 detailed description of the steps presented in the diagram, with 1020 further explanation on how implementations may vary. 1022 7.1. Onboarding and Ordering Devices 1024 The following diagram illustrates key interactions that may occur 1025 from when a prospective owner enrolls in a manufacturer's zero touch 1026 program to when the manufacturer ships devices for an order placed by 1027 the prospective owner. 1029 +-----------+ 1030 +------------+ |Prospective| +---+ 1031 |Manufacturer| | Owner | |NMS| 1032 +------------+ +-----------+ +---+ 1033 | | | 1034 | | | 1035 | 1. initiate enrollment | | 1036 #<-----------------------------| | 1037 # | | 1038 # | | 1039 # IDevID trust anchor | | 1040 #-----------------------------># set IDevID trust anchor | 1041 # #--------------------------->| 1042 # | | 1043 # bootstrap server | | 1044 # account credentials | | 1045 #-----------------------------># set credentials | 1046 # #--------------------------->| 1047 # | | 1048 # | | 1049 # owner certificate | | 1050 #-----------------------------># set certificate | 1051 | #--------------------------->| 1052 | | | 1053 | | | 1054 | 2. place device order | | 1055 |<-----------------------------# model devices | 1056 | #--------------------------->| 1057 | | | 1058 | 3. ship devices and send | | 1059 | device identifiers and | | 1060 | ownership vouchers | | 1061 |-----------------------------># set device identifiers | 1062 | # and ownership vouchers | 1063 | #--------------------------->| 1064 | | | 1066 Each numbered item below corresponds to a numbered item in the 1067 diagram above. 1069 1. A prospective owner of a manufacturer's devices, or an existing 1070 owner that wishes to start using zero touch for future device 1071 orders, initiates an enrollment process with the manufacturer or 1072 delegate. This process includes the following: 1074 * Regardless how the prospective owner intends to bootstrap 1075 their devices, they will always obtain from the manufacturer 1076 or delegate the trust anchor certificate for its device's 1077 IDevID certificates. This certificate will need to be 1078 installed on the prospective owner's NMS so that the NMS can 1079 subsequently authenticate the device's IDevID certificates. 1081 * If the manufacturer hosts an Internet based bootstrap server 1082 (e.g., a redirect server) such as described in Section 6.4, 1083 then credentials necessary to configure the bootstrap server 1084 would be provided to the prospective owner. If the bootstrap 1085 server is configurable through an API (outside the scope of 1086 this document), then the credentials might be installed on the 1087 prospective owner's NMS so that the NMS can subsequently 1088 configure the manufacturer-hosted bootstrap server directly. 1090 * If the manufacturer's devices are able to validate signed data 1091 (Section 8.4), then the manufacturer, acting as a certificate 1092 authority, may additionally sign an owner certificate for the 1093 prospective owner. Alternatively, and not depicted, the owner 1094 may obtain an owner certificate from a manufacturer-trusted 1095 3rd-party certificate authority, and report that certificate 1096 to the manufacturer. How the owner certificate is used to 1097 enable devices to validate signed bootstrapping data is 1098 described in Section 8.4. Assuming the prospective owner's 1099 NMS is able to prepare and sign the bootstrapping data, the 1100 owner certificate would be installed on the NMS at this time. 1102 2. Some time later, the prospective owner places an order with the 1103 manufacturer (or delegate), perhaps with a special flag checked 1104 for zero touch handling. At this time, or perhaps before placing 1105 the order, the owner may model the devices in their NMS, creating 1106 virtual objects for the devices with no real-world device 1107 associations. For instance the model can be used to simulate the 1108 device's location in the network and the configuration it should 1109 have when fully operational. 1111 3. When the manufacturer or delegate fulfills the order, shipping 1112 the devices to their intended locations, they may notify the 1113 owner of the devices's unique identifiers (e.g., serial numbers) 1114 and shipping destinations, which the owner may use to stage the 1115 network for when the devices power on. Additionally, the 1116 manufacturer may send one or more ownership vouchers, 1117 cryptographically assigning ownership of those devices to the 1118 rightful owner. The owner may set this information on their NMS, 1119 perhaps binding specific modeled devices to the unique 1120 identifiers and ownership vouchers. 1122 7.2. Owner Stages the Network for Bootstrap 1124 The following diagram illustrates how an owner might stage the 1125 network for bootstrapping devices. 1127 +----------+ +------------+ 1128 |Deployment| |Manufacturer| +------+ +------+ 1129 | Specific | | Hosted | | Local| | Local| +---------+ 1130 +---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| 1131 |NMS| | Server | | Server | |Server| |Server| | Storage | 1132 +---+ +----------+ +------------+ +------+ +------+ +---------+ 1133 | | | | | | 1134 activate | | | | | | 1135 modeled | | | | | | 1136 1. device | | | | | | 1137 ----------->| | | | | | 1138 | 2. (optional) | | | | 1139 | configure | | | | 1140 | bootstrap | | | | 1141 | server | | | | 1142 |------->| | | | | 1143 | | | | | | 1144 | 3. (optional) configure | | | 1145 | bootstrap server | | | | 1146 |--------------------->| | | | 1147 | | | | | | 1148 | | | | | | 1149 | 4. (optional) configure DNS server| | | 1150 |---------------------------------->| | | 1151 | | | | | | 1152 | | | | | | 1153 | 5. (optional) configure DHCP server | | 1154 |------------------------------------------->| | 1155 | | | | | | 1156 | | | | | | 1157 | 6. (optional) store bootstrapping artifacts on media | 1158 |----------------------------------------------------->| 1159 | | | | | | 1160 | | | | | | 1162 Each numbered item below corresponds to a numbered item in the 1163 diagram above. 1165 1. Having previously modeled the devices, including setting their 1166 fully operational configurations and associating both device 1167 identifiers (e.g., serial numbers) and ownership vouchers, the 1168 owner "activates" one or more modeled devices. That is, the 1169 owner tells the NMS to perform the steps necessary to prepare for 1170 when the real-world devices power up and initiate the 1171 bootstrapping process. Note that, in some deployments, this step 1172 might be combined with the last step from the previous workflow. 1173 Here it is depicted that an NMS performs the steps, but they may 1174 be performed manually or through some other mechanism. 1176 2. If it is desired to use a deployment specific bootstrap server, 1177 it MUST be configured to provide the bootstrapping information 1178 for the specific devices. Configuring the bootstrap server MAY 1179 occur via a programmatic API not defined by this document. 1180 Illustrated here as an external component, the bootstrap server 1181 MAY be implemented as an internal component of the NMS itself. 1183 3. If it is desired to use a manufacturer (or delegate) hosted 1184 bootstrap server, it MUST be configured to provide the 1185 bootstrapping information for the specific devices. The 1186 configuration MUST be either redirect or bootstrap information. 1187 That is, either the manufacturer hosted bootstrap server will 1188 redirect the device to another bootstrap server, or provide the 1189 device with its bootstrapping information itself. The types of 1190 bootstrapping information the manufacturer hosted bootstrap 1191 server supports MAY vary by implementation; some implementations 1192 may only support redirect information, or only support bootstrap 1193 information, or support both redirect and bootstrap information. 1194 Configuring the bootstrap server MAY occur via a programmatic API 1195 not defined by this document. 1197 4. If it is desired to use a DNS server to supply bootstrapping 1198 information, a DNS server needs to be configured. If multicast 1199 DNS-SD is desired, then the server MUST reside on the local 1200 network, otherwise the DNS server MAY reside on a remote network. 1201 Please see Section 6.2 for more information about how to 1202 configure DNS servers. Configuring the DNS server MAY occur via 1203 a programmatic API not defined by this document. 1205 5. If it is desired to use a DHCP server to supply bootstrapping 1206 data, a DHCP server needs to be configured. The DHCP server may 1207 be accessed directly or via a DHCP relay. Please see Section 6.3 1208 for more information about how to configure DHCP servers. 1209 Configuring the DHCP server MAY occur via a programmatic API not 1210 defined by this document. 1212 6. If it is desired to use a removable storage device (e.g., USB 1213 flash drive) to supply bootstrapping information, the information 1214 would need to be placed onto it. Please see Section 6.1 for more 1215 information about how to configure a removable storage device. 1217 7.3. Device Powers On 1219 The following diagram illustrates the sequence of activities that 1220 occur when a device powers on. 1222 +----------+ 1223 +-----------+ |Deployment| 1224 | Source of | | Specific | 1225 +------+ | Bootstrap | |Bootstrap | +---+ 1226 |Device| | Data | | Server | |NMS| 1227 +------+ +-----------+ +----------+ +---+ 1228 | | | | 1229 | | | | 1230 | 1. if running a modified (not | | | 1231 | factory default) configuration, | | | 1232 | then exit. | | | 1233 | | | | 1234 | 2. for each source supported, check | | | 1235 |------------------------------------->| | | 1236 | | | | 1237 | 3. if bootstrap-information found, | | | 1238 | initialize self and, only if | | | 1239 | source is a bootstrap server, | | | 1240 | send notifications | | | 1241 |-------------------------------------># | | 1242 | # webhook | | 1243 | #----------------------->| 1244 | | | 1245 | 4. else if redirect-information found, for | | 1246 | each bootstrap server specified, check | | 1247 |-+-------------------------------------------------->| | 1248 | | | | 1249 | | if more redirect-information is found, recurse | | 1250 | | (not depicted), else if bootstrap-information | | 1251 | | found, initialize self and post notifications | | 1252 | +--------------------------------------------------># | 1253 | # webhook | 1254 | #-------->| 1255 | 1256 | 5. retry sources and/or wait for manual provisioning. 1257 | 1259 The interactions in the above diagram are described below. 1261 1. Upon power being applied, the device's bootstrapping logic first 1262 checks to see if it is running in its factory default state. If 1263 it is in a modified state, then the bootstrapping logic exits and 1264 none of the following interactions occur. 1266 2. For each source of bootstrapping data the device supports, 1267 preferably in order of closeness to the device (e.g., removable 1268 storage before Internet based servers), the device checks to see 1269 if there is any bootstrapping data for it there. 1271 3. If bootstrap-information is found, the device initializes itself 1272 accordingly (e.g., installing a boot-image and committing an 1273 initial configuration). If the source is a bootstrap server, and 1274 the bootstrap server can be trusted (i.e., TLS-level 1275 authentication), the device also sends progress notifications to 1276 the bootstrap server. 1278 * The contents of the initial configuration SHOULD configure an 1279 administrator account on the device (e.g., username, ssh-rsa 1280 key, etc.) and SHOULD configure the device either to listen 1281 for NETCONF or RESTCONF connections or to initiate call home 1282 connections ([draft-ietf-netconf-call-home]). 1284 * If the bootstrap server supports forwarding device 1285 notifications to external systems (e.g., via a webhook), the 1286 "bootstrap-complete" notification (Section 9.2) informs the 1287 external system to know when it can, for instance, initiate a 1288 connection to the device (assuming it knows the device's 1289 address and the device was configured to listen for 1290 connections). To support this further, the bootstrap-complete 1291 notification also relays the device's SSH host keys and/or TLS 1292 certificates, with which the external system can use to 1293 authenticate subsequent connections to the device. 1295 If the device is ever able to complete the bootstrapping process 1296 successfully (i.e., no longer running its factory default 1297 configuration), it exits the bootstrapping logic without 1298 considering any additional sources of bootstrapping data. 1300 4. Otherwise, if redirect-information is found, the device iterates 1301 through the list of specified bootstrap servers, checking to see 1302 if there is any bootstrapping data for it on them. If the 1303 bootstrap server returns more redirect-information, then the 1304 device processes it recursively. Otherwise, if the bootstrap 1305 server returns bootstrap-information, the device processes it 1306 following the description provided in (3) above. 1308 5. After having tried all supported sources of bootstrapping data, 1309 the device MAY retry again all the sources and/or provide 1310 manageability interfaces for manual configuration (e.g., CLI, 1311 HTTP, NETCONF, etc.). If manual configuration is allowed, and 1312 such configuration is provided, the device MUST immediately cease 1313 trying to obtain bootstrapping data, as it would then no longer 1314 be in running its factory default configuration. 1316 8. Device Details 1318 Devices supporting the bootstrapping strategy described in this 1319 document MUST have the preconfigured factory default state and 1320 bootstrapping logic described in the following sections. 1322 8.1. Factory Default State 1324 +------------------------------------------------------------------+ 1325 | | 1326 | | 1327 | +----------------------------------------------------------+ | 1328 | | | | 1329 | | | | 1330 | | 1. IDevID cert & associated intermediate certificate(s) | | 1331 | | 2. list of trusted Internet based bootstrap servers | | 1332 | | 3. list of trust anchor certs for bootstrap servers | | 1333 | | 4. trust anchor cert for ownership vouchers | | 1334 | +----------------------------------------------------------+ | 1335 | | 1336 | +----------------------+ | 1337 | | | | 1338 | | | | 1339 | | 5. private key | | 1340 | +----------------------+ | 1341 | | 1342 +------------------------------------------------------------------+ 1344 Each numbered item below corresponds to a numbered item in the 1345 diagram above. 1347 1. Devices MUST be manufactured with an initial device identifier 1348 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 1349 X.509 certificate, encoding the device's unique device identifier 1350 (e.g., serial number). The device MUST also possess any 1351 intermediate certificates between the IDevID certificate and the 1352 manufacturer's IDevID trust anchor certificate, which is provided 1353 to prospective owners separately (e.g., Section 7.1). 1355 2. Devices that support loading bootstrapping data from an Internet- 1356 based bootstrap server (see Section 6.4) MUST be manufactured 1357 with a configured list of trusted bootstrap servers. Consistent 1358 with redirect information (Section 3.1, each bootstrap server MAY 1359 be identified by its hostname or IP address, and an optional 1360 port. 1362 3. Devices that support loading bootstrapping data from an Internet- 1363 based bootstrap server (see Section 6.4) MUST also be 1364 manufactured with a list of trust anchor certificates that can be 1365 used for X.509 certificate path validation ([RFC6125], Section 6) 1366 on the bootstrap server's TLS server certificate. 1368 4. Devices that support loading owner signed data (see Section 1.2) 1369 MUST also be manufactured with the trust anchor certificate for 1370 the ownership vouchers. 1372 5. Device MUST be manufactured with a private key that corresponds 1373 to the public key encoded in the device's IDevID certificate. 1374 This private key SHOULD be securely stored, ideally by a 1375 cryptographic processor (e.g., a TPM). 1377 8.2. Boot Sequence 1379 A device claiming to support the bootstrapping strategy defined in 1380 this document MUST support the boot sequence described in this 1381 section. 1383 Power On 1384 | 1385 v No 1386 1. Running default config? --------> Boot normally 1387 | 1388 | Yes 1389 v 1390 2. For each supported source of bootstrapping data, 1391 try to load bootstrapping data from the source 1392 | 1393 | 1394 v Yes 1395 3. Able to bootstrap off any source? -----> Run with new configuration 1396 | 1397 | No 1398 v 1399 4. Loop and/or wait for manual provisioning. 1401 Each numbered item below corresponds to a numbered item in the 1402 diagram above. 1404 1. When the device powers on, it first checks to see if it is 1405 running the factory default configuration. If it is running a 1406 modified configuration, then it boots normally. 1408 2. The device iterates over its list of sources for bootstrapping 1409 data (Section 6). Details for how to processes a source of 1410 bootstrapping data are provided in Section 8.3. 1412 3. If the device is able to bootstrap itself off any of the sources 1413 of bootstrapping data, it runs with the new bootstrapped 1414 configuration. 1416 4. Otherwise the device MAY loop back through the list of 1417 bootstrapping sources again and/or wait for manual provisioning. 1419 8.3. Processing a Source of Bootstrapping Data 1421 This section describes a recursive algorithm that a device claiming 1422 to support the bootstrapping strategy defined in this document MUST 1423 use to authenticate bootstrapping data. A device enters this 1424 algorithm for each new source of bootstrapping data. The first time 1425 the device enters this algorithm, it MUST initialize a conceptual 1426 trust state variable, herein referred to as "trust-state", to FALSE. 1427 The ultimate goal of this algorithm is for the device to process 1428 bootstrap information (Section 3.2) while the trust-state variable is 1429 TRUE. 1431 If the data source is a bootstrap server, and the device is able to 1432 authenticate the server using X.509 certificate path validation 1433 ([RFC6125], Section 6) to one of the device's preconfigured trust 1434 anchors, or to a trust anchor that it learned from a previous step, 1435 then the device MUST set trust-state to TRUE. 1437 If trust-state is TRUE, when connecting to the bootstrap server, the 1438 device MUST use its IDevID certificate for client certificate based 1439 authentication and MUST POST progress notifications using the 1440 bootstrap server's "notification" action. Otherwise, if trust-state 1441 is FALSE, when connecting to the bootstrap server, the device MUST 1442 NOT use its IDevID certificate for a client certificate based 1443 authentication and MUST NOT POST progress notifications using the 1444 bootstrap server's "notification" action. 1446 When accessing a bootstrap server, the device MUST only access its 1447 top-level resource, to obtain all the data staged for it in one GET 1448 request, so that it can determine if the data is signed or not, and 1449 thus act accordingly. If trust-state is TRUE, then the device MAY 1450 also accesses the bootstrap servers 'notification' resource for the 1451 device. 1453 For any source of bootstrapping data (e.g., Section 6), if the data 1454 is signed and the device is able to validate the signed data using 1455 the algorithm described in Section 8.4, then the device MUST set 1456 trust-state to TRUE, else the device MUST set trust-state to FALSE. 1457 Note, this is worded to cover the special case when signed data is 1458 returned even from a trusted bootstrap server. 1460 If the data is bootstrap information (not redirect information), and 1461 trust-state is FALSE, the device MUST exit the recursive algorithm, 1462 returning to the state machine described in Section 8.2. Otherwise, 1463 the device MUST attempt to process the bootstrap information as 1464 described in Section 8.6. In either case, success or failure, the 1465 device MUST exit the recursive algorithm, returning to the state 1466 machine described in Section 8.2, the only difference being in how it 1467 responds to the "Able to bootstrap off any source?" conditional 1468 described in that state machine. 1470 If the data is redirect information, the device MUST process the 1471 redirect information as described in Section 8.5. This is the 1472 recursion step, it will cause to device to reenter this algorithm, 1473 but this time the data source will most definitely be a bootstrap 1474 server, as that is all redirect information is able to do. 1476 8.4. Validating Signed Data 1478 Whenever a device is presented signed data from an untrusted source, 1479 it MUST validate the signed data as described in this section. If 1480 the signed data is provided by a trusted source, a redundant trust 1481 case, the device MAY skip verifying the signature. 1483 Whenever there is signed data, the device MUST also be provided an 1484 ownership voucher and an owner certificate. Depending on 1485 circumstances, the device MAY also be provided certificate and 1486 voucher revocations. How all the needed artifacts are provided for 1487 each source of bootstrapping data is defined in Section 6. 1489 The device MUST first authenticate the ownership voucher by 1490 validating the signature on it to one of its preconfigured trust 1491 anchors (see Section 8.1) and verify that the voucher contains the 1492 device's unique identifier (e.g., serial number). If the device 1493 insists on verifying revocation status, it MUST also verify that the 1494 voucher isn't expired or has been revoked. If the authentication of 1495 the voucher is successful, the device extracts the rightful owner's 1496 identity from the voucher for use in the next step. 1498 Next the device MUST authenticate the owner certificate by performing 1499 X.509 certificate path validation on it, and by verifying that the 1500 certificate is both identified by the voucher and also has in its 1501 chain of trust the certificate identified by the voucher. If the 1502 device insists on verifying revocation status, it MUST also verify 1503 that none of the certificates in the chain of certificates have been 1504 revoked or expired. If the authentication of the certificate is 1505 successful, the device extracts the owner's public key from the 1506 certificate for use in the next step. 1508 Finally the device MUST verify the signature over 'information type' 1509 artifact was generated by the private key matching the public key 1510 extracted from the owner certificate in the previous step. 1512 When the device receives the signed data from a bootstrap server, the 1513 device MUST use text-level operations to extract the 'information- 1514 type' node from the parent 'device' node in the response in order to 1515 verify the signature. It is not important if the extracted text is a 1516 valid YANG encoding in order to verify the signature. 1518 If any of these steps fail, then the device MUST mark the data as 1519 invalid and not perform any of the subsequent steps. 1521 8.5. Processing Redirect Information 1523 In order to process redirect information (Section 3.1), the device 1524 MUST follow the steps presented in this section. 1526 Processing redirect information is straightforward. The device 1527 sequentially steps through the list of provided bootstrap servers 1528 until it can find one it can bootstrap off of. 1530 If a hostname is provided, and the hostname's DNS resolution is to 1531 more than one IP address, the device MUST attempt to connect to all 1532 of the DNS resolved addresses at least once, before moving on to the 1533 next bootstrap server. If the device is able to obtain bootstrapping 1534 data from any of the DNS resolved addresses, it MUST immediately 1535 process that data, without attempting to connect to any of the other 1536 DNS resolved addresses. 1538 If the redirect information is trusted (e.g., trust-state is TRUE), 1539 and the bootstrap server entry contains a trust anchor certificate, 1540 then the device MUST authenticate the bootstrap server using X.509 1541 certificate path validation ([RFC6125], Section 6) to the specified 1542 trust anchor. If the device is unable to authenticate the bootstrap 1543 server to the specified trust anchor, the device MUST NOT attempt a 1544 provisional connection to the bootstrap server (i.e., by blindly 1545 accepting its server certificate). 1547 If the redirect information is untrusted (e.g., trust-state is 1548 FALSE), the device MUST discard any trust anchors provided by the 1549 redirect information and establish a provisional connection to the 1550 bootstrap server (i.e., by blindly accepting its TLS server 1551 certificate). 1553 8.6. Processing Bootstrap Information 1555 In order to process bootstrap information (Section 3.2), the device 1556 MUST follow the steps presented in this section. 1558 When processing bootstrap information, the device MUST first process 1559 the boot image information, then execute the pre-configuration script 1560 (if any), then commit the initial configuration, and then execute the 1561 script (if any), in that order. If the device encounters an error at 1562 any step, it MUST NOT proceed to the next step. 1564 First the device MUST determine if the image it is running satisfies 1565 the specified boot image criteria (e.g., name or fingerprint match). 1566 If it does not, the device MUST download, verify, and install the 1567 specified boot image, and then reboot. To verify the boot image, the 1568 device MUST check that the boot image file matches the fingerprint 1569 (e.g., sha256) supplied by the bootstrapping information. Upon 1570 rebooting, the device MUST still be in its factory default state, 1571 causing the bootstrapping process to run again, which will eventually 1572 come to this very point, but this time the device's running image 1573 will satisfy the specified criteria, and thus the device will move to 1574 processing the next step. 1576 Next, for devices that support executing scripts, if a pre- 1577 configuration script has been specified, the device MUST execute the 1578 script and check its exit status code to determine if had any 1579 warnings or errors. In the case of errors, the device MUST reset 1580 itself in such a way that force the reinstallation of its boot image, 1581 thereby wiping out any bad state the script might have left behind. 1583 Next the device commits the provided initial configuration. Assuming 1584 no errors, the device moves to processing the next step. 1586 Again, for devices that support executing scripts, if a post- 1587 configuration script has been specified, the device MUST execute the 1588 script and check its exit status code to determine if it had any 1589 warnings or errors. In the case of errors, the device MUST reset 1590 itself in such a way that force the reinstallation of its boot image, 1591 thereby wiping out any bad state the script might have left behind. 1593 At this point, the device has completely processed the bootstrapping 1594 data and is ready to be managed. If the device obtained the 1595 bootstrap information from a trusted bootstrap server, the device 1596 MUST send the 'bootstrap-complete' notification now. 1598 At this point the device is configured and no longer running its 1599 factory default configuration. Notably, if the bootstrap information 1600 configured the device it initiate a call home connection, the device 1601 would proceed to do so now. 1603 9. RESTCONF API for Bootstrap Servers 1605 This section defines a YANG ([RFC6020]) module that is used to define 1606 the RESTCONF ([draft-ietf-netconf-restconf]) API used by the 1607 bootstrap server defined in Section 6.4. Examples illustrating this 1608 API in use are provided in Appendix A. 1610 9.1. Tree Diagram 1612 The following tree diagram provides an overview for the bootstrap 1613 server RESTCONF API. The syntax used for this tree diagram is 1614 described in Section 1.4. 1616 module: ietf-zerotouch-bootstrap-server 1617 +--ro device* [unique-id] 1618 +--ro unique-id string 1619 +--ro (information-type) 1620 | +--:(redirect-information) 1621 | | +--ro redirect-information 1622 | | +--ro bootstrap-server* [address] 1623 | | +--ro address inet:host 1624 | | +--ro port? inet:port-number 1625 | | +--ro trust-anchor? binary 1626 | +--:(bootstrap-information) 1627 | +--ro bootstrap-information 1628 | +--ro boot-image 1629 | | +--ro name string 1630 | | +--ro (hash-algorithm) 1631 | | | +--:(sha256) 1632 | | | +--ro sha256? string 1633 | | +--ro uri* inet:uri 1634 | +--ro configuration-handling? enumeration 1635 | +--ro pre-configuration-script? script 1636 | +--ro configuration? 1637 | +--ro post-configuration-script? script 1638 +--ro signature? binary 1639 +--ro ownership-voucher? binary 1640 +--ro owner-certificate? binary 1641 +--ro voucher-revocation? binary 1642 +--ro certificate-revocation? binary 1643 +---x notification 1644 +---w input 1645 +---w notification-type enumeration 1646 +---w message? string 1647 +---w ssh-host-keys 1648 | +---w ssh-host-key* 1649 | +---w format enumeration 1650 | +---w key-data string 1651 +---w trust-anchors 1652 +---w trust-anchor* 1653 +---w protocol* enumeration 1654 +---w certificate binary 1656 In the above diagram, notice that all of the protocol accessible 1657 nodes are read-only, to assert that devices can only pull data from 1658 the bootstrap server. 1660 Also notice that the module defines an action statement, which 1661 devices use to provide progress notifications to the bootstrap 1662 server. 1664 9.2. YANG Module 1666 The bootstrap server's device-facing API is normatively defined by 1667 the YANG module defined in this section. 1669 Note: the module defined herein uses data types defined in [RFC2315], 1670 [RFC5280], [RFC6234], [RFC6991], and [draft-kwatsen-netconf-voucher]. 1672 file "ietf-zerotouch-bootstrap-server@2017-01-11.yang" 1674 module ietf-zerotouch-bootstrap-server { 1675 yang-version "1.1"; 1677 namespace 1678 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 1679 prefix "ztbs"; 1681 import ietf-inet-types { 1682 prefix inet; 1683 reference "RFC 6991: Common YANG Data Types"; 1684 } 1686 organization 1687 "IETF NETCONF (Network Configuration) Working Group"; 1689 contact 1690 "WG Web: 1691 WG List: 1692 Author: Kent Watsen 1693 "; 1695 description 1696 "This module defines an interface for bootstrap servers, as defined 1697 by RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based 1698 Management. 1700 Copyright (c) 2014 IETF Trust and the persons identified as 1701 authors of the code. All rights reserved. 1703 Redistribution and use in source and binary forms, with or without 1704 modification, is permitted pursuant to, and subject to the license 1705 terms contained in, the Simplified BSD License set forth in Section 1706 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1707 (http://trustee.ietf.org/license-info). 1709 This version of this YANG module is part of RFC XXXX; see the RFC 1710 itself for full legal notices."; 1712 revision "2017-01-11" { 1713 description 1714 "Initial version"; 1715 reference 1716 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based 1717 Management"; 1718 } 1720 list device { 1721 key unique-id; 1722 config false; 1724 description 1725 "A device's record entry. This is the only RESTCONF resource 1726 that a device will GET, as described in Section 8.2 in RFC XXXX. 1727 Getting just this top-level node provides a device with all the 1728 data it needs in a single request."; 1729 reference 1730 "RFC XXXX: Zero Touch Provisioning for NETCONF or 1731 RESTCONF based Management"; 1733 leaf unique-id { 1734 type string; 1735 description 1736 "A unique identifier for the device (e.g., serial number). 1737 Each device accesses its bootstrapping record by its unique 1738 identifier."; 1739 } 1741 choice information-type { 1742 mandatory true; 1743 description 1744 "This choice statement ensures the response only contains 1745 redirect-information or bootstrap-information. Note that 1746 this is the only mandatory true node, as the other nodes 1747 are not needed when the device trusts the bootstrap server, 1748 in which case the data does not need to be signed."; 1750 container redirect-information { 1751 description 1752 "This is redirect information, as described in Section 3.1 1753 in RFC XXXX. Its purpose is to redirect a device to another 1754 bootstrap server."; 1755 reference 1756 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF 1757 based Management"; 1759 list bootstrap-server { 1760 key address; 1761 description 1762 "A bootstrap server entry."; 1764 leaf address { 1765 type inet:host; 1766 mandatory true; 1767 description 1768 "The IP address or hostname of the bootstrap server the 1769 device should redirect to."; 1770 } 1771 leaf port { 1772 type inet:port-number; 1773 default 443; 1774 description 1775 "The port number the bootstrap server listens on."; 1776 } 1777 leaf trust-anchor { //should there be two fields like voucher? 1778 type binary; 1779 description 1780 "An X.509 v3 certificate structure as specified by RFC 1781 5280, Section 4, encoded using ASN.1 distinguished 1782 encoding rules (DER), as specified in ITU-T X.690. A 1783 certificate that a device can use as a trust anchor 1784 to authenticate the bootstrap server it is being 1785 redirected to."; 1786 reference 1787 "RFC 5280: 1788 Internet X.509 Public Key Infrastructure Certificate 1789 and Certificate Revocation List (CRL) Profile. 1790 ITU-T X.690: 1791 Information technology - ASN.1 encoding rules: 1792 Specification of Basic Encoding Rules (BER), 1793 Canonical Encoding Rules (CER) and Distinguished 1794 Encoding Rules (DER)."; 1795 } 1796 } 1797 } 1799 container bootstrap-information { 1801 description 1802 "This is bootstrap information, as described in Section 3.2 in 1803 RFC XXXX. Its purpose is to provide the device everything it 1804 needs to bootstrap itself."; 1805 reference 1806 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF 1807 based Management"; 1809 container boot-image { 1810 description 1811 "Specifies criteria for the boot image the device MUST 1812 be running."; 1814 leaf name { // maybe this should be a regex? 1815 type string; 1816 mandatory true; 1817 description 1818 "The name of a software image that the device MUST 1819 be running in order to process the remaining nodes."; 1820 } 1821 choice hash-algorithm { 1822 mandatory true; 1823 description 1824 "Identifies the hash algorithm used."; 1825 leaf sha256 { 1826 type string; 1827 description 1828 "The hex-encoded SHA-256 hash over the boot 1829 image file. This is used by the device to 1830 verify a downloaded boot image file."; 1831 reference 1832 "RFC 6234: US Secure Hash Algorithms."; 1833 } 1834 } 1835 leaf-list uri { 1836 type inet:uri; 1837 min-elements 1; 1838 description 1839 "An ordered list of URIs to where the boot-image file MAY 1840 be obtained. Deployments MUST know in which URI schemes 1841 (http, ftp, etc.) a device supports. If a secure scheme 1842 (e.g., https) is provided, a device MAY establish a 1843 provisional connection to the server, by blindly 1844 accepting the server's credentials (e.g., its TLS 1845 certificate)"; 1846 } 1847 } 1849 leaf configuration-handling { 1850 type enumeration { 1851 enum merge { 1852 description 1853 "Merge configuration into existing running configuration."; 1854 } 1855 enum replace { 1856 description 1857 "Replace existing running configuration with the passed 1858 configuration."; 1859 } 1860 } 1861 description 1862 "This enumeration indicates how the server should process 1863 the provided configuration. When not specified, the device 1864 MAY determine how to process the configuration using other 1865 means (e.g., vendor-specific metadata)."; 1866 } 1868 leaf pre-configuration-script { 1869 type script; 1870 description 1871 "A script that, when present, is executed before the 1872 configuration has been processed."; 1873 } 1875 anydata configuration { 1876 must "../configuration-handling"; 1877 description 1878 "Any configuration data model known to the device. It may 1879 contain manufacturer-specific and/or standards-based data 1880 models."; 1881 } 1883 leaf post-configuration-script { 1884 type script; 1885 description 1886 "A script that, when present, is executed after the 1887 configuration has been processed."; 1888 } 1889 } 1890 } 1892 leaf signature { 1893 type binary; 1894 must "../redirect-information or ../bootstrap-information" { 1895 description 1896 "An information type must be present whenever an 1897 signature is present."; 1898 } 1899 description 1900 "A PKCS#7 SignedData structure, as specified by Section 9.1 1901 of RFC 2315, containing just the signature (no content, 1902 certificates, or CRLs), encoded using ASN.1 distinguished 1903 encoding rules (DER), as specified in ITU-T X.690. 1905 This signature is generated by the device's owner using 1906 the private key associated with the owner certificate 1907 over the information-type node, exactly as it's presented 1908 to the device. The device MUST use text-level operations 1909 to extract the information-type node from the larger 1910 'device' response in order to verify it. It is not 1911 important if the extracted text is itself a valid 1912 encoding (e.g., XML or JSON)."; 1913 reference 1914 "RFC 2315: 1915 PKCS #7: Cryptographic Message Syntax Version 1.5 1916 ITU-T X.690: 1917 Information technology - ASN.1 encoding rules: 1918 Specification of Basic Encoding Rules (BER), 1919 Canonical Encoding Rules (CER) and Distinguished 1920 Encoding Rules (DER)."; 1921 } 1923 leaf ownership-voucher { 1924 type binary; 1925 must "../signature" { 1926 description 1927 "A signature must be present whenever an ownership voucher 1928 is presented."; 1929 } 1930 must "../owner-certificate" { 1931 description 1932 "An owner certificate must be present whenever an ownership 1933 voucher is presented."; 1934 } 1935 description 1936 "A 'voucher' structure, per draft-kwatsen-netconf-voucher. 1937 The voucher needs to reference the device's unique identifier 1938 and also specify the owner certificate's identity and a CA 1939 certificate in the owner certificate's chain of trust."; 1940 reference 1941 "draft-kwatsen-netconf-voucher: 1942 Voucher and Voucher Revocation Profiles for Bootstrapping 1943 Protocols"; 1944 } 1946 leaf owner-certificate { 1947 type binary; 1948 must "../signature" { 1949 description 1950 "A signature must be present whenever an owner certificate 1951 is presented."; 1952 } 1953 must "../ownership-voucher" { 1954 description 1955 "An ownership voucher must be present whenever an owner 1956 certificate is presented."; 1957 } 1958 description 1959 "An unsigned PKCS #7 SignedData structure, as specified 1960 by Section 9.1 in RFC 2315, containing just certificates 1961 (no content, signatures, or CRLs), encoded using ASN.1 1962 distinguished encoding rules (DER), as specified in 1963 ITU-T X.690. 1965 This structure contains, in order, the owner certificate 1966 itself and all intermediate certificates leading up to a 1967 trust anchor certificate. The owner certificate MAY 1968 optionally include the trust anchor certificate."; 1969 reference 1970 "RFC 2315: 1971 PKCS #7: Cryptographic Message Syntax Version 1.5. 1972 ITU-T X.690: 1973 Information technology - ASN.1 encoding rules: 1974 Specification of Basic Encoding Rules (BER), 1975 Canonical Encoding Rules (CER) and Distinguished 1976 Encoding Rules (DER)."; 1977 } 1979 leaf voucher-revocation { 1980 type binary; 1981 must "../ownership-voucher" { 1982 description 1983 "An ownership voucher must be present whenever a voucher 1984 revocation is presented."; 1985 } 1986 description 1987 "A 'voucher-revocation' structure, as defined in 1988 draft-kwatsen-netconf-voucher. The voucher revocation 1989 definitively states whether a voucher is valid or not."; 1990 reference 1991 "draft-kwatsen-netconf-voucher: 1992 Voucher and Voucher Revocation Profiles for Bootstrapping 1993 Protocols"; 1994 } 1996 leaf certificate-revocation { 1997 type binary; 1998 must "../owner-certificate" { 1999 description 2000 "An owner certificate must be present whenever an voucher 2001 revocation is presented."; 2002 } 2003 description 2004 "An unsigned PKCS #7 SignedData structure, as specified by 2005 Section 9.1 in RFC 2315, containing just CRLs (no content, 2006 signatures, or certificates), encoded using ASN.1 2007 distinguished encoding rules (DER), as specified in 2008 ITU-T X.690. 2010 This structure contains, in order, the CRL for the owner 2011 certificate itself and the CRLs for all intermediate 2012 certificates leading up to but not including a trust 2013 anchor certificate."; 2014 reference 2015 "RFC 5280: 2016 Internet X.509 Public Key Infrastructure Certificate 2017 and Certificate Revocation List (CRL) Profile. 2018 ITU-T X.690: 2019 Information technology - ASN.1 encoding rules: 2020 Specification of Basic Encoding Rules (BER), 2021 Canonical Encoding Rules (CER) and Distinguished 2022 Encoding Rules (DER)."; 2023 } 2025 action notification { 2026 input { 2027 leaf notification-type { 2028 type enumeration { 2029 enum bootstrap-initiated { 2030 description 2031 "Indicates that the device has just accessed the 2032 bootstrap server. The 'message' field below MAY 2033 contain any additional information that the 2034 manufacturer thinks might be useful."; 2035 } 2036 enum parsing-warning { 2037 description 2038 "Indicates that the device had a non-fatal error when 2039 parsing the response from the bootstrap server. The 2040 'message' field below SHOULD indicate the specific 2041 warning that occurred."; 2042 } 2043 enum parsing-error { 2044 description 2045 "Indicates that the device encountered a fatal error 2046 when parsing the response from the bootstrap server. 2048 For instance, this could be due to malformed encoding, 2049 the device expecting signed data when only unsigned 2050 data is provided, because the ownership voucher didn't 2051 include the device's unique identifier, or because the 2052 signature didn't match. The 'message' field below 2053 SHOULD indicate the specific error. This notification 2054 also indicates that the device has abandoned trying to 2055 bootstrap off this bootstrap server."; 2056 } 2057 enum boot-image-warning { 2058 description 2059 "Indicates that the device encountered a non-fatal 2060 error condition when trying to install a boot-image. 2061 A possible reason might include a need to reformat a 2062 partition causing loss of data. The 'message' field 2063 below SHOULD indicate any warning messages that were 2064 generated."; 2065 } 2066 enum boot-image-error { 2067 description 2068 "Indicates that the device encountered an error when 2069 trying to install a boot-image, which could be for 2070 reasons such as a file server being unreachable, 2071 file not found, signature mismatch, etc. The 2072 'message' field SHOULD indicate the specific error 2073 that occurred. This notification also indicates 2074 that the device has abandoned trying to bootstrap 2075 off this bootstrap server."; 2076 } 2077 enum pre-script-warning { 2078 description 2079 "Indicates that the device obtained a greater than 2080 zero exit status code from the script when it was 2081 executed. The 'message' field below SHOULD indicate 2082 both the resulting exit status code, as well as 2083 capture any stdout/stderr messages the script may 2084 have produced."; 2085 } 2086 enum pre-script-error { 2087 description 2088 "Indicates that the device obtained a less than zero 2089 exit status code from the script when it was executed. 2090 The 'message' field below SHOULD indicate both the 2091 resulting exit status code, as well as capture any 2092 stdout/stderr messages the script may have produced. 2093 This notification also indicates that the device has 2094 abandoned trying to bootstrap off this bootstrap 2095 server."; 2097 } 2098 enum config-warning { 2099 description 2100 "Indicates that the device obtained warning messages 2101 when it committed the initial configuration. The 2102 'message' field below SHOULD indicate any warning 2103 messages that were generated."; 2104 } 2105 enum config-error { 2106 description 2107 "Indicates that the device obtained error messages 2108 when it committed the initial configuration. The 2109 'message' field below SHOULD indicate the error 2110 messages that were generated. This notification 2111 also indicates that the device has abandoned trying 2112 to bootstrap off this bootstrap server."; 2113 } 2114 enum post-script-warning { 2115 description 2116 "Indicates that the device obtained a greater than 2117 zero exit status code from the script when it was 2118 executed. The 'message' field below SHOULD indicate 2119 both the resulting exit status code, as well as 2120 capture any stdout/stderr messages the script may 2121 have produced."; 2122 } 2123 enum post-script-error { 2124 description 2125 "Indicates that the device obtained a less than zero 2126 exit status code from the script when it was executed. 2127 The 'message' field below SHOULD indicate both the 2128 resulting exit status code, as well as capture any 2129 stdout/stderr messages the script may have produced. 2130 This notification also indicates that the device has 2131 abandoned trying to bootstrap off this bootstrap 2132 server."; 2133 } 2134 enum bootstrap-complete { 2135 description 2136 "Indicates that the device successfully processed the 2137 all the bootstrapping data and that it is ready to be 2138 managed. The 'message' field below MAY contain any 2139 additional information that the manufacturer thinks 2140 might be useful. After sending this notification, 2141 the device is not expected to access the bootstrap 2142 server again."; 2143 } 2144 enum informational { 2145 description 2146 "Indicates any additional information not captured by 2147 any of the other notification-type. For instance, a 2148 message indicating that the device is about to reboot 2149 after having installed a boot-image could be provided. 2150 The 'message' field below SHOULD contain information 2151 that the manufacturer thinks might be useful."; 2152 } 2153 } 2154 mandatory true; 2155 description 2156 "The type of notification provided."; 2157 } 2158 leaf message { 2159 type string; 2160 description 2161 "An optional human-readable value."; 2162 } 2163 container ssh-host-keys { 2164 when "../notification-type = 'bootstrap-complete'" { 2165 description 2166 "SSH host keys are only sent when the notification 2167 type is 'bootstrap-complete'."; 2168 } 2169 description 2170 "A list of SSH host keys an NMS may use to authenticate 2171 a NETCONF connection to the device with."; 2172 list ssh-host-key { 2173 description 2174 "An SSH host-key"; 2175 leaf format { 2176 type enumeration { 2177 enum ssh-dss { description "ssh-dss"; } 2178 enum ssh-rsa { description "ssh-rsa"; } 2179 } 2180 mandatory true; 2181 description 2182 "The format of the SSH host key."; 2183 } 2184 leaf key-data { 2185 type string; 2186 mandatory true; 2187 description 2188 "The key data for the SSH host key"; 2189 } 2190 } 2191 } 2192 container trust-anchors { 2193 when "../notification-type = 'bootstrap-complete'" { 2194 description 2195 "Trust anchors are only sent when the notification 2196 type is 'bootstrap-complete'."; 2197 } 2198 description 2199 "A list of trust anchor certificates an NMS may use to 2200 authenticate a NETCONF or RESTCONF connection to the 2201 device with."; 2202 list trust-anchor { 2203 description 2204 "A list of trust anchor certificates an NMS may use to 2205 authenticate a NETCONF or RESTCONF connection to the 2206 device with."; 2207 leaf-list protocol { 2208 type enumeration { 2209 enum netconf-ssh { description "netconf-ssh"; } 2210 enum netconf-tls { description "netconf-tls"; } 2211 enum restconf-tls { description "restconf-tls"; } 2212 enum netconf-ch-ssh { description "netconf-ch-ssh"; } 2213 enum netconf-ch-tls { description "netconf-ch-tls"; } 2214 enum restconf-ch-tls { description "restconf-ch-tls"; } 2215 } 2216 min-elements 1; 2217 description 2218 "The protocols that this trust anchor secures."; 2219 } 2220 leaf certificate { 2221 type binary; 2222 mandatory true; 2223 description 2224 "An X.509 v3 certificate structure, as specified by 2225 Section 4 in RFC5280, encoded using ASN.1 distinguished 2226 encoding rules (DER), as specified in ITU-T X.690."; 2227 reference 2228 "RFC 5280: 2229 Internet X.509 Public Key Infrastructure Certificate 2230 and Certificate Revocation List (CRL) Profile. 2231 ITU-T X.690: 2232 Information technology - ASN.1 encoding rules: 2233 Specification of Basic Encoding Rules (BER), 2234 Canonical Encoding Rules (CER) and Distinguished 2235 Encoding Rules (DER)."; 2236 } 2237 } 2238 } 2239 } 2240 } // end action 2242 } // end device 2244 typedef script { 2245 type binary; 2246 description 2247 "A device specific script that enables the execution of commands 2248 to perform actions not possible thru configuration alone. 2250 No attempt is made to standardize the contents, running context, 2251 or programming language of the script. The contents of the 2252 script are considered specific to the vendor, product line, 2253 and/or model of the device. 2255 If a script is erroneously provided to a device that does not 2256 support the execution of scripts, the device SHOULD send a 2257 'script-warning' notification message, but otherwise continue 2258 processing the bootstrapping data as if the script had not 2259 been present. 2261 The script returns exit status code '0' on success and non-zero 2262 on error, with accompanying stderr/stdout for logging purposes. 2263 In the case of an error, the exit status code will specify what 2264 the device should do. 2266 If the exit status code is greater than zero, then the device 2267 should assume that the script had a soft error, which the 2268 script believes does not affect manageability. If the device 2269 obtained the bootstrap information from a bootstrap server, 2270 it SHOULD send a 'script-warning' notification message. 2272 If the exit status code is less than zero, the device should 2273 assume the script had a hard error, which the script believes 2274 will affect manageability. In this case, the device SHOULD 2275 send a 'script-error' notification message followed by a 2276 reset that will force a new boot-image install (wiping out 2277 anything the script may have done) and restart the entire 2278 bootstrapping process again."; 2279 } 2281 } 2283 2284 10. Security Considerations 2286 10.1. Immutable storage for trust anchors 2288 Devices MUST ensure that all their trust anchor certificates, 2289 including those for connecting to bootstrap servers and verifying 2290 ownership vouchers, are protected from external modification. 2292 It may be necessary to update these certificates over time (e.g., the 2293 manufacturer wants to delegate trust to a new CA). It is therefore 2294 expected that devices MAY update these trust anchors when needed 2295 through a verifiable process, such as a software upgrade using signed 2296 software images. 2298 10.2. Clock Sensitivity 2300 The solution in this document relies on TLS certificates, owner 2301 certificates, and ownership vouchers, all of which require an 2302 accurate clock in order to be processed correctly (e.g., to test 2303 validity dates and revocation status). Implementations MUST ensure 2304 devices have an accurate clock when shipped from manufacturing 2305 facilities, and take steps to prevent clock tampering. 2307 If it is not possible to ensure clock accuracy, it is RECOMMENDED 2308 that implementations disable the aspects of the solution having clock 2309 sensitivity. In particular, such implementations should assume that 2310 TLS certificates, owner certificates, and ownership vouchers are not 2311 revokable, In real-world terms, this means that manufacturers SHOULD 2312 only issue a single ownership voucher for the lifetime of some 2313 devices. 2315 It is important to note that implementations SHOULD NOT rely on NTP 2316 for time, as it is not a secure protocol. 2318 10.3. Blindly authenticating a bootstrap server 2320 This document allows a device to blindly authenticate a bootstrap 2321 server's TLS certificate. It does so to allow for cases where the 2322 redirect information may be obtained in an unsecured manner, which is 2323 desirable to support in some cases. 2325 To compensate for this, this document requires that devices, when 2326 connected to an untrusted bootstrap server, do not send their IDevID 2327 certificate for client authentication, and they do not POST any 2328 progress notifications, and they assert that data downloaded from the 2329 server is signed. 2331 10.4. Entropy loss over time 2333 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 2334 IDevID certificate should never expire (i.e. having the notAfter 2335 value 99991231235959Z). Given the long-lived nature of these 2336 certificates, it is paramount to use a strong key length (e.g., 2337 512-bit ECC). 2339 10.5. Serial Numbers 2341 This draft suggests using the device's serial number as the unique 2342 identifier in its IDevID certificate. This is because serial numbers 2343 are ubiquitous and prominently contained in invoices and on labels 2344 affixed to devices and their packaging. That said, serial numbers 2345 many times encode revealing information, such as the device's model 2346 number, manufacture date, and/or sequence number. Knowledge of this 2347 information may provide an adversary with details needed to launch an 2348 attack. 2350 10.6. Sequencing Sources of Bootstrapping Data 2352 For devices supporting more than one source for bootstrapping data, 2353 no particular sequencing order has to be observed for security 2354 reasons, as the solution for each source is considered equally 2355 secure. However, from a privacy perspective, it is RECOMMENDED that 2356 devices access local sources before accessing remote sources. 2358 11. IANA Considerations 2360 11.1. The BOOTP Manufacturer Extensions and DHCP Options Registry 2362 The following registrations are in accordance to RFC 2939 [RFC2939] 2363 for "BOOTP Manufacturer Extensions and DHCP Options" registry 2364 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 2366 11.1.1. DHCP v4 Option 2367 Tag: XXX 2369 Name: Zero Touch Information 2371 Returns up to six zero touch bootstrapping artifacts. 2373 Code Len 2374 +-----+-----+----------+------------------+-----------+ 2375 | XXX | n | encoding | information-type | signature | 2376 +-----+-----+----------+------------------+-----------+ 2378 +-------------------+-------------------+-------------------------+ 2379 | owner-certificate | ownership-voucher | certificate-revocations | 2380 +-------------------+-------------------+-------------------------+ 2382 +---------------------+ 2383 | voucher-revocations | 2384 +---------------------+ 2386 Reference: RFC XXXX 2388 11.1.2. DHCP v6 Option 2390 Tag: YYY 2392 Name: Zero Touch Information 2394 Returns up to six zero touch bootstrapping artifacts. 2396 Code Len 2397 +-----+-----+----------+------------------+-----------+ 2398 | XXX | n | encoding | information-type | signature | 2399 +-----+-----+----------+------------------+-----------+ 2401 +-------------------+-------------------+-------------------------+ 2402 | owner-certificate | ownership-voucher | certificate-revocations | 2403 +-------------------+-------------------+-------------------------+ 2405 +---------------------+ 2406 | voucher-revocations | 2407 +---------------------+ 2409 Reference: RFC XXXX 2411 11.2. The IETF XML Registry 2413 This document registers one URI in the IETF XML registry [RFC3688]. 2414 Following the format in [RFC3688], the following registration is 2415 requested: 2417 URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server 2418 Registrant Contact: The NETCONF WG of the IETF. 2419 XML: N/A, the requested URI is an XML namespace. 2421 11.3. The YANG Module Names Registry 2423 This document registers one YANG module in the YANG Module Names 2424 registry [RFC6020]. Following the format defined in [RFC6020], the 2425 the following registration is requested: 2427 name: ietf-zerotouch-bootstrap-server 2428 namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server 2429 prefix: ztbs 2430 reference: RFC XXXX 2432 12. Other Considerations 2434 Both this document and [draft-ietf-anima-bootstrapping-keyinfra] 2435 define bootstrapping mechanisms. The authors have collaborated on 2436 both solutions and believe that each solution has merit and, in fact, 2437 can work together. That is, it is possible for a device to support 2438 both solutions simultaneously. 2440 13. Acknowledgements 2442 The authors would like to thank for following for lively discussions 2443 on list and in the halls (ordered by last name): David Harrington, 2444 Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, 2445 Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, Russ 2446 Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael 2447 Richardson, Phil Shafer, Juergen Schoenwaelder. 2449 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 2450 brainstorming the original I-D's solution during the IETF 87 meeting 2451 in Berlin. 2453 14. References 2454 14.1. Normative References 2456 [draft-ietf-netconf-restconf] 2457 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2458 Protocol", draft-ieft-netconf-restconf-10 (work in 2459 progress), 2016, . 2462 [draft-kwatsen-netconf-voucher] 2463 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2464 "Voucher and Voucher Revocation Profiles for Bootstrapping 2465 Protocols", draft-kwatsen-netconf-voucher-00 (work in 2466 progress), 2016, . 2469 [RFC1035] Mockapetris, P., "Domain names - implementation and 2470 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2471 November 1987, . 2473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2474 Requirement Levels", BCP 14, RFC 2119, 2475 DOI 10.17487/RFC2119, March 1997, 2476 . 2478 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 2479 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 2480 . 2482 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2483 Housley, R., and W. Polk, "Internet X.509 Public Key 2484 Infrastructure Certificate and Certificate Revocation List 2485 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2486 . 2488 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2489 the Network Configuration Protocol (NETCONF)", RFC 6020, 2490 DOI 10.17487/RFC6020, October 2010, 2491 . 2493 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2494 Verification of Domain-Based Application Service Identity 2495 within Internet Public Key Infrastructure Using X.509 2496 (PKIX) Certificates in the Context of Transport Layer 2497 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2498 2011, . 2500 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2501 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2502 DOI 10.17487/RFC6234, May 2011, 2503 . 2505 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2506 DOI 10.17487/RFC6762, February 2013, 2507 . 2509 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2510 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2511 . 2513 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2514 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2515 . 2517 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 2518 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 2519 April 2015, . 2521 [Std-802.1AR-2009] 2522 IEEE SA-Standards Board, "IEEE Standard for Local and 2523 metropolitan area networks - Secure Device Identity", 2524 December 2009, . 2527 14.2. Informative References 2529 [draft-ietf-anima-bootstrapping-keyinfra] 2530 Pritikin, M., Behringer, M., and S. Bjarnason, 2531 "Bootstrapping Key Infrastructures", draft-ietf-anima- 2532 bootstrapping-keyinfra-03 (work in progress), 2016, 2533 . 2536 [draft-ietf-netconf-call-home] 2537 Watsen, K., "NETCONF Call Home (work in progress)", draft- 2538 ieft-netconf-restconf-10 (work in progress), December 2539 2015, . 2542 [draft-ietf-netconf-server-model] 2543 Watsen, K., "NETCONF Server Model (work in progress)", 2544 draft-ieft-netconf-server-model-09 (work in progress), 2545 March 2016, . 2548 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 2549 of New DHCP Options and Message Types", BCP 43, RFC 2939, 2550 DOI 10.17487/RFC2939, September 2000, 2551 . 2553 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2554 DOI 10.17487/RFC3688, January 2004, 2555 . 2557 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2558 and A. Bierman, Ed., "Network Configuration Protocol 2559 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2560 . 2562 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 2563 of Named Entities (DANE) Transport Layer Security (TLS) 2564 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2565 2012, . 2567 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2568 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2569 2014, . 2571 Appendix A. API Examples 2573 This section presents some examples illustrating device interactions 2574 with a bootstrap server to access Redirect and Bootstrap information, 2575 both unsigned and signed, as well as to send a progress notification. 2576 These examples show the bootstrap information containing 2577 configuration from the YANG modules in [RFC7317] and 2578 [draft-ietf-netconf-server-model]. 2580 A.1. Unsigned Redirect Information 2582 The following example illustrates a device using the API to fetch its 2583 bootstrapping data. In this example, the device receives unsigned 2584 redirect information. This example is representative of a response a 2585 trusted redirect server might return. 2587 REQUEST 2588 ------- 2589 ['\' line wrapping added for formatting only] 2591 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 2592 device=123456 HTTP/1.1 2593 HOST: example.com 2594 Accept: application/yang.data+xml 2596 RESPONSE 2597 -------- 2599 HTTP/1.1 200 OK 2600 Date: Sat, 31 Oct 2015 17:02:40 GMT 2601 Server: example-server 2602 Content-Type: application/yang.data+xml 2604 2606 2608 123456789 2609 2610 2611
phs1.example.com
2612 8443 2613 2614 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 2615 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 2616 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 2617 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 2618 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 2619 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 2620 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 2621 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 2622 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 2623 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 2624 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 2625 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 2626 RJSUJQFRStS0Cg== 2627 2628 2629 2630
phs2.example.com
2631 8443 2632 2633 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 2634 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 2635 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 2636 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 2637 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 2638 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 2639 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 2640 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 2641 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 2642 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 2643 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 2644 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 2645 RJSUJQFRStS0Cg== 2646 2647 2648 2649 2651 A.2. Signed Redirect Information 2653 The following example illustrates a device using the API to fetch its 2654 bootstrapping data. In this example, the device receives signed 2655 redirect information. This example is representative of a response 2656 that redirect server might return if concerned the device might not 2657 be able to authenticate its TLS certificate. 2659 REQUEST 2660 ------- 2661 ['\' line wrapping added for formatting only] 2663 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 2664 device=123456 HTTP/1.1 2665 HOST: example.com 2666 Accept: application/yang.data+xml 2668 RESPONSE 2669 -------- 2671 HTTP/1.1 200 OK 2672 Date: Sat, 31 Oct 2015 17:02:40 GMT 2673 Server: example-server 2674 Content-Type: application/yang.data+xml 2676 2678 2680 123456789 2681 2682 2683
phs1.example.com
2684 8443 2685 2686 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 2687 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 2688 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 2689 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 2690 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 2691 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 2692 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 2693 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 2694 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 2695 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 2696 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 2697 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 2698 RJSUJQFRStS0Cg== 2699 2700 2701 2702
phs2.example.com
2703 8443 2704 2705 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 2706 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 2707 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 2708 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 2709 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 2710 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 2711 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 2712 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 2713 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 2714 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 2715 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 2716 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 2717 RJSUJQFRStS0Cg== 2718 2719 2720 2721 2722 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2723 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2724 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2725 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 2726 2727 2728 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2729 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2730 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2731 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2732 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2733 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2734 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2735 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2736 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2737 MjAO 2738 2739 2740 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\ 2741 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\ 2742 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2743 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2744 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2745 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2746 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2747 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2748 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\ 2749 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 2750 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 2751 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\ 2752 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 2753 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2754 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2755 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2756 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2757 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2758 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\ 2759 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\ 2760 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\ 2761 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\ 2762 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\ 2763 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\ 2764 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\ 2765 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 2766 2767 2768 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2769 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2770 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2771 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2772 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 2773 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 2774 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 2775 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2776 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 2777 2778 2779 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2780 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2781 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2782 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2783 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2784 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2785 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2786 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2787 MjAO== 2788 2789 2791 A.3. Unsigned Bootstrap Information 2793 The following example illustrates a device using the API to fetch its 2794 bootstrapping data. In this example, the device receives unsigned 2795 bootstrapping information. This example is representative of a 2796 response a locally deployed bootstrap server might return. 2798 REQUEST 2799 ------- 2800 ['\' line wrapping added for formatting only] 2802 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 2803 device=123456 HTTP/1.1 2804 HOST: example.com 2805 Accept: application/yang.data+xml 2807 RESPONSE 2808 -------- 2810 HTTP/1.1 200 OK 2811 Date: Sat, 31 Oct 2015 17:02:40 GMT 2812 Server: example-server 2813 Content-Type: application/yang.data+xml 2815 2817 2819 123456789 2820 2821 2822 2823 boot-image-v3.2R1.6.img 2824 2825 2826 SomeMD5String 2827 2828 2829 SomeSha1String 2830 2831 2832 ftp://ftp.example.com/path/to/file 2833 2834 2835 merge 2836 2837 2838 2839 2840 2841 admin 2842 2843 admin's rsa ssh host-key 2844 ssh-rsa 2845 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\ 2846 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\ 2847 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\ 2848 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\ 2849 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\ 2850 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\ 2851 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 2852 2853 2854 2855 2856 2857 2859 2860 2861 config-mgr 2862 2863 2864 2865 east-data-center 2866
11.22.33.44
2867 2868 2869 west-data-center 2870
55.66.77.88
2871 2872 2873 2874 my-call-home-x509-key 2875 2876 2877 2878 2879 2880 2881 2882 2884 A.4. Signed Bootstrap Information 2886 The following example illustrates a device using the API to fetch its 2887 bootstrapping data. In this example, the device receives signed 2888 bootstrap information. This example is representative of a response 2889 that bootstrap server might return if concerned the device might not 2890 be able to authenticate its TLS certificate. 2892 REQUEST 2893 ------- 2895 ['\' line wrapping added for formatting only] 2897 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 2898 device=123456 HTTP/1.1 2899 HOST: example.com 2900 Accept: application/yang.data+xml 2902 RESPONSE 2903 -------- 2905 HTTP/1.1 200 OK 2906 Date: Sat, 31 Oct 2015 17:02:40 GMT 2907 Server: example-server 2908 Content-Type: application/yang.data+xml 2910 2912 2914 123456789 2915 2916 2917 2918 boot-image-v3.2R1.6.img 2919 2920 2921 SomeMD5String 2922 2923 2924 SomeSha1String 2925 2926 2927 /path/to/on/same/bootserver 2928 2929 2930 2931 2932 2933 2934 2935 admin 2936 2937 admin's rsa ssh host-key 2938 ssh-rsa 2939 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\ 2940 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\ 2941 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\ 2942 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\ 2943 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\ 2944 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\ 2945 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 2946 2947 2948 2949 2950 2951 2953 2954 2955 config-mgr 2956 2957 2958 2959 east-data-center 2960
11.22.33.44
2961 2962 2963 west-data-center 2964
55.66.77.88
2965 2966 2967 2968 my-call-home-x509-key 2969 2970 2971 2972 2973 2974 2975 2976 2977 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 2978 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 2979 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2980 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 2981 2982 2983 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2984 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2985 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 2986 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 2987 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 2988 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 2989 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 2990 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 2991 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 2992 MjAO 2993 2994 2995 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx\ 2996 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE\ 2997 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu\ 2998 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 2999 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 3000 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 3001 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 3002 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 3003 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X\ 3004 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 3005 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 3006 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C\ 3007 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 3008 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 3009 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 3010 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 3011 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 3012 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 3013 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q\ 3014 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B\ 3015 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB\ 3016 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K\ 3017 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y\ 3018 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo\ 3019 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir\ 3020 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 3021 3022 3023 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET\ 3024 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 3025 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 3026 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii\ 3027 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF\ 3028 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4\ 3029 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF\ 3030 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 3031 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 3032 3033 3034 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh\ 3035 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC\ 3036 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI\ 3037 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal\ 3038 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES\ 3039 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w\ 3040 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0\ 3041 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v\ 3042 MjAO== 3043 3044 3045 A.5. Progress Notifications 3047 The following example illustrates a device using the API to post a 3048 notification to a trusted bootstrap server. Illustrated below is the 3049 'bootstrap-complete' message, but the device may send other 3050 notifications to the server while bootstrapping (e.g., to provide 3051 status updates). 3053 The bootstrap server MUST NOT process a notification from a device 3054 without first authenticating the device. This is in contrast to when 3055 a device is fetching data from the server, a read-only operation, in 3056 which case device authentication is not strictly required (e.g., when 3057 sending signed information). 3059 In this example, the device sends a notification indicating that it 3060 has completed bootstrapping off the data provided by the server. 3061 This example illustrates the device sending both its SSH host keys 3062 and TLS server certificate to the bootstrap server, which the 3063 bootstrap server may, for example, pass to an NMS, as discussed in 3064 Section 7.3. 3066 Note that devices that are able to present an IDevID certificate 3067 [Std-802.1AR-2009], when establishing SSH or TLS connections, do not 3068 need to include its DevID certificate in the bootstrap-complete 3069 message. It is unnecessary to send the DevID certificate in this 3070 case because the IDevID certificate does not need to be pinned by an 3071 NMS in order to be trusted. 3073 REQUEST 3074 ------- 3075 ['\' line wrapping added for formatting only] 3077 POST https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 3078 device=123456/notification HTTP/1.1 3079 HOST: example.com 3080 Content-Type: application/yang.data+xml 3082 3084 3086 bootstrap-complete 3087 example message 3088 3089 3090 ssh-rsa 3091 3092 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\ 3093 zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\ 3094 zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\ 3095 9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\ 3096 QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\ 3097 LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\ 3098 VOZZgQ8929uWjCWlGlqn2mPibp2Go1 3099 3100 3101 3102 ssh-dsa 3103 3104 zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxL\ 3105 zeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr\ 3106 9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLq\ 3107 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6\ 3108 QFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7\ 3109 LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakW\ 3110 VOZZgQ8929uWjCWlGlqn2mPibp2Go1 3111 3112 3113 3114 3115 3116 netconf-ssh 3117 netconf-tls 3118 restconf-tls 3119 netconf-ch-ssh 3120 netconf-ch-tls 3121 restconf-ch-tls 3122 3123 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 3124 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 3125 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 3126 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 3127 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 3128 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 3129 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 3130 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 3131 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 3132 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 3133 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 3134 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 3135 RJSUJQFRStS0Cg== 3136 3137 3138 3140 3141 RESPONSE 3142 -------- 3144 HTTP/1.1 204 No Content 3145 Date: Sat, 31 Oct 2015 17:02:40 GMT 3146 Server: example-server 3148 Appendix B. Artifact Examples 3150 This section presents examples for how the 'information type' 3151 artifact (Section 4.1) can be encoded into a document that can be 3152 distributed outside the bootstrap server's RESTCONF API. 3154 The inforamtion type artifact is encoded the same as if returned by a 3155 RESTCONF server for an HTTP GET request for the specific information- 3156 type resource. 3158 These examples show the bootstrap information containing 3159 configuration from the YANG modules in [RFC7317] and 3160 [draft-ietf-netconf-server-model]. 3162 Only examples for the information type artifact are provided, as the 3163 other five artifacts in Section 4 have binary encodings. 3165 B.1. Redirect Information 3167 The following example illustrates how redirect information can be 3168 encoded into an artifact. 3170 3172 3174 3175
phs1.example.com
3176 8443 3177 3178 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 3179 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 3180 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 3181 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 3182 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 3183 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 3184 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 3185 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 3186 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 3187 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 3188 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 3189 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2\ 3190 RJSUJQFRStS0Cg== 3191 3192 3193 3194
phs1.example.com
3195 8443 3196 3197 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM\ 3198 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk\ 3199 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot\ 3200 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd\ 3201 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER\ 3202 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF\ 3203 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC\ 3204 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN\ 3205 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW\ 3206 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ\ 3207 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ\ 3208 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 3209 3210 3211 3213 B.2. Bootstrap Information 3215 The following example illustrates how bootstrap information can be 3216 encoded into an artifact. 3218 3220 3222 3223 3224 boot-image-v3.2R1.6.img 3225 3226 3227 SomeMD5String 3228 3229 3230 SomeSha1String 3231 3232 3233 file:///some/path/to/raw/file 3234 3235 3236 merge 3237 3238 3239 3240 3241 3242 admin 3243 3244 admin's rsa ssh host-key 3245 ssh-rsa 3246 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC\ 3247 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj\ 3248 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC\ 3249 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5\ 3250 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq\ 3251 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6\ 3252 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 3253 3254 3255 3256 3257 3258 3260 3261 3262 config-mgr 3263 3264 3265 3266 east-data-center 3267
11.22.33.44
3268 3269 3270 west-data-center 3271
55.66.77.88
3272 3273 3274 3275 my-call-home-x509-key 3276 3277 3278 3279 3280 3281 3282 3284 Appendix C. Change Log 3286 C.1. ID to 00 3288 o Major structural update; the essence is the same. Most every 3289 section was rewritten to some degree. 3291 o Added a Use Cases section 3293 o Added diagrams for "Actors and Roles" and "NMS Precondition" 3294 sections, and greatly improved the "Device Boot Sequence" diagram 3296 o Removed support for physical presence or any ability for 3297 configlets to not be signed. 3299 o Defined the Zero Touch Information DHCP option 3301 o Added an ability for devices to also download images from 3302 configuration servers 3304 o Added an ability for configlets to be encrypted 3306 o Now configuration servers only have to support HTTP/S - no other 3307 schemes possible 3309 C.2. 00 to 01 3311 o Added boot-image and validate-owner annotations to the "Actors and 3312 Roles" diagram. 3314 o Fixed 2nd paragraph in section 7.1 to reflect current use of 3315 anyxml. 3317 o Added encrypted and signed-encrypted examples 3319 o Replaced YANG module with XSD schema 3321 o Added IANA request for the Zero Touch Information DHCP Option 3323 o Added IANA request for media types for boot-image and 3324 configuration 3326 C.3. 01 to 02 3328 o Replaced the need for a configuration signer with the ability for 3329 each NMS to be able to sign its own configurations, using 3330 manufacturer signed ownership vouchers and owner certificates. 3332 o Renamed configuration server to bootstrap server, a more 3333 representative name given the information devices download from 3334 it. 3336 o Replaced the concept of a configlet by defining a southbound 3337 interface for the bootstrap server using YANG. 3339 o Removed the IANA request for the boot-image and configuration 3340 media types 3342 C.4. 02 to 03 3344 o Minor update, mostly just to add an Editor's Note to show how this 3345 draft might integrate with the draft-pritikin-anima-bootstrapping- 3346 keyinfra. 3348 C.5. 03 to 04 3350 o Major update formally introducing unsigned data and support for 3351 Internet-based redirect servers. 3353 o Added many terms to Terminology section. 3355 o Added all new "Guiding Principles" section. 3357 o Added all new "Sources for Bootstrapping Data" section. 3359 o Rewrote the "Interactions" section and renamed it "Workflow 3360 Overview". 3362 C.6. 04 to 05 3364 o Semi-major update, refactoring the document into more logical 3365 parts 3367 o Created new section for information types 3369 o Added support for DNS servers 3371 o Now allows provisional TLS connections 3373 o Bootstrapping data now supports scripts 3375 o Device Details section overhauled 3377 o Security Considerations expanded 3379 o Filled in enumerations for notification types 3381 C.7. 05 to 06 3383 o Minor update 3385 o Added many Normative and Informative references. 3387 o Added new section Other Considerations. 3389 C.8. 06 to 07 3391 o Minor update 3393 o Added an Editorial Note section for RFC Editor. 3395 o Updated the IANA Considerations section. 3397 C.9. 07 to 08 3399 o Minor update 3401 o Updated to reflect review from Michael Richardson. 3403 C.10. 08 to 09 3405 o Added in missing "Signature" artifact example. 3407 o Added recommendation for manufacturers to use interoperable 3408 formats and file naming conventions for removable storage devices. 3410 o Added configuration-handling leaf to guide if config should be 3411 merged, replaced, or processed like an edit-config/yang-patch 3412 document. 3414 o Added a pre-configuration script, in addition to the post- 3415 configuration script from -05 (issue #15). 3417 C.11. 09 to 10 3419 o Factored ownership vocher and voucher revocation to a separate 3420 document: draft-kwatsen-netconf-voucher. (issue #11) 3422 o Removed options 'edit-config' and yang- 3423 patch'. (issue #12) 3425 o Defined how a signature over signed-data returned from a bootstrap 3426 server is processed. (issue #13) 3428 o Added recommendation for removable storage devices to use open/ 3429 standard file systems when possible. (issue #14) 3431 o Replaced notifications "script-[warning/error]" with "[pre/post]- 3432 script-[warning/error]". (goes with issue #15) 3434 o switched owner-certificate to be encoded using the pkcs#7 format. 3435 (issue #16) 3437 o Replaced md5/sha1 with sha256 inside a choice statement, for 3438 future extensibility. (issue #17) 3440 o A ton of editorial changes, as I went thru the entire draft with a 3441 fine-toothed comb. 3443 C.12. 10 to 11 3445 o fixed yang validation issues found by IETFYANGPageCompilation. 3446 note: these issues were NOT found by pyang --ietf or by the 3447 submission-time validator... 3449 o fixed a typo in the yang module, someone the config false 3450 statement was removed. 3452 C.13. 11 to 12 3454 o fixed more yang validation issues found by 3455 IETFYANGPageCompilation. note: again, these issues were NOT found 3456 by pyang --ietf or by the submission-time validator... 3458 o fixed typo that prevented Appendix B from loading the examples 3459 correctly. 3461 o updated a few of the notification enumerations to be more 3462 consistent with the other enumerations (following the warning/ 3463 error pattern). 3465 o updated the information artifact to state how it's encoded, 3466 matching the language that was in Appendix B. 3468 Authors' Addresses 3470 Kent Watsen 3471 Juniper Networks 3473 EMail: kwatsen@juniper.net 3475 Mikael Abrahamsson 3476 T-Systems 3478 EMail: "mikael.abrahamsson@t-systems.se