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