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