idnits 2.17.1 draft-ietf-netconf-zerotouch-04.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 42 instances of too long lines in the document, the longest one being 327 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 912 has weird spacing: '...-anchor bin...' == Line 929 has weird spacing: '...ificate str...' == Line 938 has weird spacing: '...ey-data str...' == Line 2093 has weird spacing: '...ated-on yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2015) is 3112 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Clarke 5 Expires: April 21, 2016 Cisco Systems 6 M. Abrahamsson 7 T-Systems 8 October 19, 2015 10 Zero Touch Provisioning for NETCONF Call Home 11 draft-ietf-netconf-zerotouch-04 13 Abstract 15 This draft presents a technique for establishing a secure NETCONF or 16 RESTCONF connection between a newly deployed device, configured with 17 just its factory default settings, and its rightful owner's network 18 management system (NMS). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Conveying Trust . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Ownership . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.4. Information Types . . . . . . . . . . . . . . . . . . . . 7 63 3. Sources for Bootstrapping Data . . . . . . . . . . . . . . . 8 64 3.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 8 65 3.2. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Internet Based Service . . . . . . . . . . . . . . . . . 9 67 4. Workflow Overview . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Onboarding and Ordering Devices . . . . . . . . . . . . . 9 69 4.2. Owner Stages the Network for Bootstrap . . . . . . . . . 11 70 4.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 13 71 5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.1. Factory Default State . . . . . . . . . . . . . . . . . . 16 73 5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 17 74 5.3. Validating Signed Data . . . . . . . . . . . . . . . . . 19 75 5.4. Processing Bootstrap Data . . . . . . . . . . . . . . . . 19 76 6. YANG-defined API and Artifacts . . . . . . . . . . . . . . . 20 77 6.1. Module Overview . . . . . . . . . . . . . . . . . . . . . 20 78 6.2. API Examples . . . . . . . . . . . . . . . . . . . . . . 22 79 6.2.1. Unsigned Redirect Information . . . . . . . . . . . . 22 80 6.2.2. Signed Redirect Information . . . . . . . . . . . . . 23 81 6.2.3. Unsigned Bootstrap Information . . . . . . . . . . . 26 82 6.2.4. Signed Bootstrap Information . . . . . . . . . . . . 28 83 6.2.5. Progress Notifications . . . . . . . . . . . . . . . 31 84 6.3. Artifact Examples . . . . . . . . . . . . . . . . . . . . 32 85 6.3.1. Signed Redirect Information . . . . . . . . . . . . . 32 86 6.3.2. Signed Bootstrap Information . . . . . . . . . . . . 33 87 6.3.3. Owner Certificate . . . . . . . . . . . . . . . . . . 35 88 6.3.4. Ownership Voucher . . . . . . . . . . . . . . . . . . 36 89 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 37 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 91 7.1. Immutable storage for trust anchors . . . . . . . . . . . 44 92 7.2. Real time clock . . . . . . . . . . . . . . . . . . . . . 44 93 7.3. Entropy loss over time . . . . . . . . . . . . . . . . . 44 94 7.4. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 44 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 96 8.1. Zero Touch Information DHCP Options . . . . . . . . . . . 45 97 8.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 45 98 8.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 45 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 102 10.2. Informative References . . . . . . . . . . . . . . . . . 47 103 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 48 104 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 48 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 106 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 50 107 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 51 108 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 51 109 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 51 110 B.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 51 112 1. Introduction 114 A fundamental business requirement is to reduce costs where possible. 115 For network operators, deploying devices to many locations can be a 116 significant cost, as sending trained specialists to each site to do 117 installations is both cost prohibitive and does not scale. 119 This document defines bootstrapping strategies enabling a device to 120 securely obtain bootstrapping data with no installer input beyond 121 racking the device and applying power. This bootstrapping data 122 directs the device to install a boot image and an initial 123 configuration, which enables the establishment of a NETCONF [RFC6241] 124 or RESTCONF [draft-ietf-netconf-restconf] connection to its rightful 125 owner's network management system (NMS). 127 In order to enable a NETCONF or RESTCONF connection to be 128 established, the initial configuration should include settings such 129 as enabling the NETCONF/RESTCONF service, including parameters needed 130 to support an NMS-initiated or device-initiated connection, and 131 configuring a local administrator account. Examples used in this 132 draft illustrate this using models defined by [RFC7317] and 133 [draft-ietf-netconf-server-model]. 135 1.1. Use Cases 137 o Connecting to a remotely administered network 139 This use-case involves scenarios, such as a remote branch 140 office or convenience store, whereby a device connects as an 141 access gateway to an ISP's network. Assuming it is not 142 possible to customize the ISP's network, and with no other 143 nearby device to leverage, the device has no recourse but to 144 reach out to the public Internet for a well-known service it 145 can bootstrap off of. 147 o Connecting to a locally administered network 149 This use-case covers all other scenarios and differs only in 150 that the device may additionally leverage nearby devices, which 151 may direct it to use a local service to bootstrap off of. If 152 no such site-specific information is available, or the device 153 is unable to use the information provided, it can then reach 154 out to network just as it would for the remotely administered 155 network use-case. 157 1.2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 161 sections below are to be interpreted as described in RFC 2119 162 [RFC2119]. 164 This document defines the following terms: 166 Artifact: The term "artifact" is used throughout to represent 167 bootstrapping data that can be encoded outside of the RESTCONF 168 protocol. For example, an artifact may be a file on disk or a 169 message in another protocol. Unless used inside a secure 170 protocol, artifacts must be signed and need to be provided along 171 with an Owner Certificate and an Ownership Voucher (see terms), 172 so the a device can validate the artifact's signature to its 173 Rightful Owner (see term). 175 Bootstrap Server: The term "bootstrap server" is used within this 176 document to mean any RESTCONF server implementing the YANG module 177 defined in Section 6.4. 179 Device: The term "device" is used throughout this document to refer 180 to the network element that needs to be bootstrapped. The device 181 is the RESTCONF client to a Bootstrap Server (see above) and, at 182 the end of bootstrapping process, the device is the NETCONF or 183 RESTCONF server to a deployment-specific NMS. See Section 5 for 184 more information about devices. 186 Network Management System (NMS): The acronym "NMS" is used 187 throughout this document to refer to the deployment specific 188 management system that the bootstrapping process ultimately 189 connects the devices to. From a device's perspective, when the 190 bootstrapping process has completed, the NMS is a NETCONF or 191 RESTCONF client. 193 Owner: See Rightful Owner. 195 Owner Certificate: An owner certificate, signed by the device's 196 manufacturer or delegate, binds an owner identity to the owner's 197 private key, which the owner can subsequently use to sign 198 artifacts. The owner certificate is an X.509 certificate 199 encoding the owner's identity in the Subject field of the X.509 200 certificate. The owner certificate is used by devices only when 201 validating owner signatures on Signed Data (see term). 203 Ownership Voucher: An ownership voucher, signed by the device's 204 manufacturer or delegate, binds an owner identity to one or more 205 device identities (e.g., serial numbers). The ownership voucher 206 is used by devices only when validating owner signatures on 207 Signed Data (see term). 209 Redirect Server: The term "redirect server" is used to refer to a 210 Bootstrap Server (see above) that only returns Redirect 211 Information (Section 2.4). 213 Rightful Owner: The rightful owner of a device is the person or 214 organization that purchased the device. How ownership can be 215 conveyed to a device is described in Section 2.3. 217 Secure Redirect: Secure redirect is like an HTTP Redirect except 218 that it also returns TLS certificates that can be used as trust 219 anchors to validate the secure connection to the Bootstrap Server 220 the device is being redirected to. 222 Signed Data: The term "signed data" is used throughout to mean data 223 that has been signed by a device's Rightful Owner's private key. 224 Any time data is signed, it must be presented along with an Owner 225 Certificate and Ownership Voucher (see terms). 227 Unsigned Data: The term "unsigned data" is used throughout to mean 228 data that has not been signed by a device's Rightful Owner's 229 private key. The option to use unsigned data is available only 230 when the data is obtained over a secure connection, such as to a 231 Redirect Server or a Bootstrap Server (see terms). 233 1.3. Tree Diagrams 235 A simplified graphical representation of the data models is used in 236 this document. The meaning of the symbols in these diagrams is as 237 follows: 239 o Brackets "[" and "]" enclose list keys. 241 o Braces "{" and "}" enclose feature names, and indicate that the 242 named feature must be present for the subtree to be present. 244 o Abbreviations before data node names: "rw" means configuration 245 (read-write) and "ro" state data (read-only). 247 o Symbols after data node names: "?" means an optional node, "!" 248 means a presence container, and "*" denotes a list and leaf-list. 250 o Parentheses enclose choice and case nodes, and case nodes are also 251 marked with a colon (":"). 253 o Ellipsis ("...") stands for contents of subtrees that are not 254 shown. 256 2. Guiding Principles 258 This section provides overarching principles guiding the solution 259 presented in this document. 261 2.1. Trust Anchors 263 A device in its factory default state can only trust remote keys for 264 which it has preconfigured trust anchors. For instance, the device 265 may have a trust anchor (e.g., a X.509 certificate) for when 266 authenticating a very specific HTTPS server, and another trust anchor 267 for when validating boot-image files, and yet another trust anchor 268 for when verifying software licenses. 270 2.2. Conveying Trust 272 Trust can be conveyed by either transport level security or artifact 273 signing. For instance, if a device connects to an HTTPS server, 274 authenticating the TLS certificate to a known trust anchor, then any 275 data the device receives from the HTTPS server can also be trusted. 276 Likewise, if a device can authenticate the signature over some data 277 to a known trust anchor, then that data can also be trusted. In 278 general, any data obtained from a trusted source MAY be trusted and, 279 any data obtained from an untrusted source MUST NOT be trusted. 281 It is possible but unnecessary to provide signed data over a secure 282 connection. For instance, a device connecting to a trusted HTTPS 283 server may retrieve data that has been signed by its rightful owner, 284 but this is not required, as the device is already assured by the 285 server that its data was staged by its rightful owner. That said, 286 when an insecure connection is used (e.g., DHCP), the device has no 287 choice but to require that the data be signed, in order to trust the 288 data. 290 2.3. Ownership 292 The goal of this document is to enable a device to connect with its 293 rightful owner's NMS. This entails the manufacturer being able to 294 track who owns which devices (out of the scope of this document), as 295 well as an ability to convey that information to devices (in scope). 296 Matching the two ways to convey trust, this document provides both a 297 protocol-oriented solution as well as an artifact based solution for 298 conveying ownership. 300 The protocol based solution conveys ownership by API contract, in 301 that the server asserts that it will only return data that it is sure 302 was staged by that device's rightful owner. How ownership for a 303 device is assured is out of scope of this document. 305 The artifact based solution involves the manufacturer signing an 306 owner key and then later, when the ownership for devices is 307 established, the manufacturer signing a voucher that assigns those 308 devices to the owner, and then the owner using their private key to 309 sign the artifacts. Thus, from the device's perspective, it can use 310 the presented "ownership voucher" to validate the presented "owner 311 certificate", which it can then use to validate the signature over 312 the presented artifact. 314 The YANG module in Section 6.4 includes grouping statements defining 315 the format for the owner certificates and ownership vouchers used by 316 the bootstrapping solution presented in this document. 318 2.4. Information Types 320 This document presumes there exists two types of zero touch 321 information: redirect information and bootstrapping information. 322 Either type of data may by accessed as unsigned data over a secure 323 connection to a trusted server (e.g., HTTPS), or as signed artifacts 324 obtained via an insecure method (DHCP server, removable storage 325 device, etc.). 327 The redirect information type of data provides two bits of 328 information: bootstrap server locations and trust anchors. The trust 329 anchors are provided to enable the device to authentic the specified 330 bootstrap servers (TLS certificate-based authentication). This is 331 what distinguishes this technique from a standard HTTP Redirect and 332 why it may sometimes be called "secure redirect". 334 The bootstrap information type of data provides information 335 describing the boot-image and configuration the device should be 336 running, in order to be considered bootstrapped. The boot-image 337 information is optional but, if it is provided, the device should 338 install the boot image prior to installing the configuration. 340 The YANG module in Section 6.4 includes grouping statements defining 341 the format for redirect and bootstrap information types used by the 342 bootstrapping solution presented in this document. 344 3. Sources for Bootstrapping Data 346 Following are the sources of bootstrapping data that are referenced 347 by the workflow presented in Section 4.3. Other sources for 348 bootstrapping information may be described in other documents, so 349 long as the principles for when the bootstrapping data needs to be 350 signed or not are enforced. 352 Each of the descriptions below show how the bootstrapping data needs 353 to be handled in a manner consistent with the guiding principles in 354 Section 2. 356 For devices supporting more than one source for bootstrapping data, 357 no particular sequencing order has to be observed, as each source is 358 equally secure, in that the chain of trust always goes back to the 359 same root of trust, the manufacturer. 361 3.1. Removable Storage 363 A device may attempt to read bootstrapping information from a 364 directly attached removable storage device. This information would 365 most likely have to be signed, as removable storage devices are 366 generally not trustworthy. 368 The information loaded from a removable storage device may redirect 369 the device to a bootstrap server (i.e., redirect information) or it 370 may provide the boot image and configuration (i.e., bootstrapping 371 information) directly. For when providing the information directly, 372 even the raw boot image file could be on the removable storage 373 device, making it a fully self-standing solution. 375 3.2. DHCP Server 377 A device may attempt to read bootstrapping information from a DHCP 378 server (e.g., DHCP options). This information would have to be 379 signed, as the DHCP protocol is not a secure protocol. 381 The information may again be either redirect or bootstrapping 382 information. If bootstrapping information is provided, the URI to 383 the boot image would have to specify a file server (e.g., ftp://, 384 tftp://, etc.), as DHCP servers do not themselves distribute files. 386 Note that it is acceptable for boot images to be fetched using an 387 insecure protocol when having an embedded signature, as is commonly 388 the case. 390 3.3. Internet Based Service 392 A device may attempt to read bootstrapping information from a trusted 393 Internet based service. The hosted information would not have to be 394 signed, as the device would authenticate the service when 395 establishing a secure connection to it, using trust anchors the 396 device is manufactured with in its factory default state. 398 This document defines a RESTCONF API for a bootstrap server that may 399 be hosted on the Internet. The YANG module describing this API is 400 provided in Section 6.4. 402 The information may again redirect the device to a bootstrap server 403 (i.e., redirect information) or it may direct the device to load a 404 boot image and a configuration (i.e., bootstrapping information). If 405 bootstrapping information is provided, the URI to the boot image 406 would not have to be to a server the device has a trust anchor for, 407 assuming the boot image has an embedded signature, as is commonly the 408 case. 410 4. Workflow Overview 412 The zero touch solution presented in this document is conceptualized 413 to be composed of the workflows described in this section. 414 Implementations MAY vary in details. 416 4.1. Onboarding and Ordering Devices 418 The following diagram illustrates key interactions that occur from 419 when a manufacturer or delegate onboards a prospective device owner 420 to when the manufacturer ships devices for an order placed by the 421 prospective device owner. 423 +-----------+ 424 +------------+ |Prospective| +---+ 425 |Manufacturer| | Owner | |NMS| 426 +------------+ +-----------+ +---+ 427 | | | 428 | | | 429 | 1. enroll me please | | 430 #<----------------------------| | 431 # | | 432 # account credentials and/or | | 433 # and/or owner certificate | | 434 #---------------------------->| | 435 | | | 436 | | | 437 | | | 438 | 2. get IDevID trust anchor | | 439 |<----------------------------# set IDevID trust anchor | 440 | #------------------------->| 441 | | | 442 | | | 443 | 3. place device order | | 444 |<----------------------------# model devices | 445 | #------------------------->| 446 | | | 447 | 4. ship devices and send | | 448 | device identifiers and | | 449 | ownership vouchers | | 450 |----------------------------># set device identifiers | 451 | # and ownership vouchers | 452 | #------------------------->| 453 | | | 454 | | | 456 The interactions in the above diagram are described below. 458 1. A prospective owner establishes a trust relationship with a 459 manufacturer in order to place zero touch orders. Assuming the 460 manufacturer or delegate hosts a secure redirect server, this 461 onbording interaction might entail the creation of an online 462 account that the owner can use to configure redirect information 463 for future device orders. Alternatively, the onbording 464 interaction may include the manufacturer signing an owner 465 certificate (see Section 1.2), to be used for bootstrapping 466 devices not using the manufacturer's redirect server. The 467 onboarding interaction may also do both, giving the choice to the 468 owner for how specific devices should bootstrap. 470 2. The prospective owner downloads from the manufacturer the X.509 471 based trust anchor certificate that can be used to validate the 472 IDevID certificate [Std-802.1AR-2009] the devices will present as 473 their SSH host key or TLS server certificate, when establishing a 474 NETCONF or RESTCONF connection with the prospective owner's 475 deployment-specific NMS. 477 3. Some time later, the prospective owner places an order with the 478 manufacturer, perhaps with a special flag checked for zero touch 479 handling. At this time, perhaps before placing the order, the 480 owner may model the devices in their NMS. That is, create 481 virtual objects for the devices with no real-world device 482 associations. For instance the model can be used to simulate the 483 device's location in the network and the configuration it should 484 have when fully operational. 486 4. When the manufacturer ships the devices for the order, the 487 manufacturer notifies the owner of the devices' unique 488 identifiers and shipping destinations, which the owner can use to 489 stage the network for when the devices powers on. Additionally, 490 the manufacturer may send a ownership voucher assigning ownership 491 of those devices to the rightful owner and/or configure backend 492 systems so the secure redirect service can associate the redirect 493 information to the devices. The owner sets this information on 494 the NMS, perhaps binding specific device identifiers and 495 ownership vouchers (if supported) to specific modeled devices. 497 4.2. Owner Stages the Network for Bootstrap 499 The following diagram illustrates how an owner stages the network for 500 bootstrapping devices. 502 +----------+ +------------+ 503 |Deployment| |Manufacturer| +------+ 504 | Specific | | Hosted | | Local| +---------+ 505 +---+ |Bootstrap | | Redirect | | DHCP | |Removable| 506 |NMS| | Server | | Server | |Server| | Storage | 507 +---+ +----------+ +------------+ +------+ +---------+ 508 | | | | | 509 activate | | | | | 510 modeled | | | | | 511 1. device | | | | | 512 ----------->| | | | | 513 | | | | | 514 | 2. stage bootstrap | | | 515 | information | | | 516 |---------->| | | | 517 | | | | | 518 | 3. (optional) configure | | | 519 | redirect server | | | 520 |-------------------------->| | | 521 | | | | | 522 | | | | | 523 | 4. (optional) configure DHCP server | | 524 |---------------------------------------->| | 525 | | | | | 526 | | | | | 527 | 5. (optional) store bootstrapping artifacts on media | 528 |----------------------------------------------------->| 529 | | | | | 530 | | | | | 532 The interactions in the above diagram are described below. 534 1. Having previously modeled the devices, including setting their 535 fully operational configurations, associating device identifiers 536 and ownership vouchers (if supported), the owner may "activate" 537 one or more modeled devices. That is, tell the NMS to perform 538 the steps necessary to prepare for when the real-world devices 539 are powered up. 541 2. One thing the NMS must do is configure the deployment specific 542 bootstrap server. Illustrated here as an external component, the 543 bootstrap server may be implemented as an internal component of 544 the NMS itself. Configuring the bootstrap server may occur via a 545 programmatic API not defined by this document. This step sets 546 signed or unsigned bootstrap information, as shown in 547 Section 6.2, for the devices being activated. The configuration 548 set MUST be at least enough to enable a secure NETCONF or 549 RESTCONF connection to be established and MAY be the device's 550 fully operational configuration. 552 3. If it is desired to use a manufacturer or delegate hosted 553 redirect service to supply the bootstrapping information, the 554 redirect server would need to be configured to supply the 555 redirect information to the devices. Configuring the redirect 556 server may occur via a programmatic API not defined by this 557 document. This step sets signed or unsigned redirect 558 information, as shown in Section 6.2, for the devices being 559 activated. The redirect information MUST set the IP address or 560 hostname of the deployment specific bootstrap server and MAY set 561 the X.509 trust anchor certificate to authenticate the bootstrap 562 server's TLS certificate. 564 4. If it is desired to use a DHCP server to supply bootstrapping 565 information, the DHCP server would need to be configured to 566 supply the redirect information to the devices. Configuring the 567 DHCP server may occur via a programmatic API (not defined by this 568 document). Since DHCP is an insecure protocol, the information 569 would have to be signed. That is, either signed redirect or 570 signed bootstrap information, as shown in Section 6.2. 572 5. If it is desired to use a removable storage device (e.g., USB 573 flash drive) to supply bootstrapping information, the information 574 would need to be placed onto it. Since a removable storage 575 device is insecure, the information would have to be signed. 576 That is, either signed redirect or signed bootstrap information, 577 as shown in Section 6.2. 579 4.3. Device Powers On 581 The following diagram illustrates how a device might behave when 582 powered on. Note that this is merely exemplary, subject to which 583 bootstrapping strategies the device supports, which may be more or 584 less than depicted below. 586 This example sequences the sources of information (see Section 3) 587 based on locality, or how "close" to the device the data is. Whether 588 this sequence makes sense for a specific type of device needs to be 589 determined by the manufacturer. 591 +------------+ +----------+ 592 +------+ |Manufacturer| |Deployment| 593 +---------+ | Local| | Hosted | | Specific | 594 +------+ |Removable| | DHCP | | Redirect | |Bootstrap | +---+ 595 |Device| | Storage | |Server| | Server | | Server | |NMS| 596 +------+ +---------+ +------+ +------------+ +----------+ +---+ 597 | | | | | | 598 | | | | | | 599 | 1. if not factory default, then exit. | | | 600 | | | | | | 601 | | | | | | 602 | 2. check | | | | | 603 #----------->| | | | | 604 # if signed redirect information found | | web- | 605 #------------------------------------------------------># hook | 606 # either NMS-initiated connection | #---------># 607 #<-----------------------------------------------------------------# 608 # or device-initiated connection | | | 609 #----------------------------------------------------------------->| 610 # else if signed bootstrap information found (call home)| | 611 #----------------------------------------------------------------->| 612 | | | | | | 613 | | | | | | 614 | | | | | | 615 | 3. Get IP assignment | | | | 616 #------------------------>| | | | 617 # if signed redirect information found | web- | 618 #------------------------------------------------------># hook | 619 # either NMS-initiated connection | #---------># 620 #<-----------------------------------------------------------------# 621 # or device-initiated connection | | | 622 #----------------------------------------------------------------->| 623 | | | | | | 624 | | | | | | 625 | | | | | | 626 | 4. check | | | | | 627 #-------------------------------------->| | | 628 # if signed or unsigned redirect information found | web- | 629 #------------------------------------------------------># hook | 630 # either NMS-initiated connection | #---------># 631 #<-----------------------------------------------------------------# 632 # or device-initiated connection | | | 633 #----------------------------------------------------------------->| 634 | | | | | | 635 | 636 | 5. loop or wait for manual provisioning. 637 | 638 The interactions in the above diagram are described below. 640 1. Upon power being applied, the device's bootstrapping logic first 641 checks to see if it is running in its factory default state. If 642 it has a modified state, then the bootstrapping logic would exit 643 and none to the following interactions would occur. 645 2. If the device is able to load bootstrapping data from a removable 646 storage device (e.g., USB flash drive), it might choose to do so 647 first. The removable storage may have either signed redirect 648 information or signed bootstrap information, as shown in 649 Section 6.3. 651 In the case that signed redirect information is found, the 652 device would use it to established a connection to the 653 deployment-specific bootstrap server, which would set its boot 654 image and configure it to enable connections with the 655 deployment-specific NMS to be established. If the bootstrap 656 supports notifying (e.g., via a web-hook) external systems 657 when a device sends its bootstrap-complete notification 658 (Section 6.4), it would be possible for the NMS to initiate a 659 NETCONF or RESTCONF connection to the device. Otherwise the 660 configuration could configure the device it initiate a NETCONF 661 or RESTCONF call home [draft-ietf-netconf-call-home] 662 connection to the deployment-specific NMS. 664 In the case that signed bootstrap information is found, the 665 device would use it to set its boot image and initial 666 configuration, which would have to direct it to initiate a 667 NETCONF or RESTCONF call home connection to the deployment- 668 specific NMS. 670 If the device is unable to bootstrap using any of the 671 information on the removable storage device, it would proceed 672 to the next source of bootstrapping information, if any. 674 3. If the device is able to load bootstrapping data from a DHCP 675 server, when obtaining a DHCP assignment, it may receive signed 676 redirect information in a DHCP Option (Section 8). The device 677 would process the signed redirect information in the same manner 678 as described above for when it's loaded from a removable storage 679 device. If the device is unable to bootstrap using information 680 provided by a DHCP server, it would proceed to the next source of 681 bootstrapping information, if any. 683 4. If the device is able to obtain a routable address to the 684 Internet, it may attempt to establish a connection to a redirect 685 server that is set by its factory default state (Section 5.1). 687 These connections would use the RESTCONF API described in this 688 document and would be secured using trust anchors also set in the 689 device's factory default state. The redirect server may provide 690 signed or unsigned redirect information. In either case, the 691 device would process the redirect information in the same manner 692 as described above for when it's loaded from a removable storage 693 device. If the device is unable to bootstrap using information 694 provided by any redirect servers, it would proceed to the next 695 source of bootstrapping information, if any. 697 5. If no more sources of bootstrapping information are available, 698 the device may fall into a loop to try again or it may provide 699 manageability interfaces for manual configuration (e.g., CLI, 700 HTTP, NETCONF, etc.). 702 5. Device Details 704 Devices supporting Zero Touch MUST have the preconfigured factory 705 default state and bootstrapping logic described in the following 706 sections. 708 5.1. Factory Default State 710 +------------------------------------------------------------------+ 711 | | 712 | | 713 | +----------------------------------------------------------+ | 714 | | | | 715 | | | | 716 | | 1. list of public Internet Bootstrap Servers | | 717 | | 2. list of trust anchor certs for Bootstrap Servers | | 718 | | 3. trust anchor cert for owner certificates | | 719 | | 4. trust anchor cert for device ownership vouchers | | 720 | | 5. IDevID cert & associated intermediate certificate(s) | | 721 | +----------------------------------------------------------+ | 722 | | 723 | +----------------------+ | 724 | | | | 725 | | | | 726 | | 6. private key | | 727 | +----------------------+ | 728 | | 729 +------------------------------------------------------------------+ 731 1. Devices that support loading bootstrapping information from the 732 Internet (see Section 3) MUST be manufactured with a list of 733 default Bootstrap Servers. Each Bootstrap Server may be 734 identified via a hostname or an IP address. 736 2. Devices that support loading bootstrapping information from the 737 Internet (see Section 3) SHOULD be manufactured with a list of 738 trust anchor certificates that can be used to authenticate the 739 Bootstrap Server connections with. 741 3. Devices that support loading owner signed data (see Section 1.2) 742 MUST be manufactured with the trust anchor certificate for the 743 Owner Certificates that the Manufacturer provides to prospective 744 owners when they enroll in the Manufacturer's Zero Touch program 745 (see Section 4.1). 747 4. Devices that support loading owner signed data (see Section 1.2) 748 MUST also be manufactured with the trust anchor certificate for 749 the device Ownership Vouchers that the Manufacturer provides to 750 prospective owners when it ships out an order of Zero Touch 751 devices (see Section 4.1). 753 5. Devices MUST be manufactured with an initial device identifier 754 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 755 X.509 certificate, encoding a globally unique device identifier 756 (e.g., serial number). The device MUST also possess any 757 intermediate certificates between the IDevID certificate and the 758 Manufacturer's IDevID trust anchor certificate. 760 6. Device MUST be manufactured with a private key that corresponds 761 to the public key encoded in the device's IDevID certificate. 762 This private key SHOULD be securely stored, ideally by a 763 cryptographic processor (e.g., a TPM). 765 5.2. Boot Sequence 767 A device claiming to support Zero Touch MUST support the boot 768 sequence described in this section. 770 Power On 771 | 772 v No 773 1. Running default config? --------> Boot normally 774 | 775 | Yes 776 v 777 2. For each supported source for bootstrapping information, 778 try to load bootstrapping data from the source 779 | 780 | 781 v Yes 782 3. Able to bootstrap off any source? -----> Run with new configuration 783 | 784 | No 785 v 786 4. Loop or wait for manual provisioning. 788 These interactions are described next. 790 1. When the device powers on, it first checks to see if it is 791 running the factory default configuration. If it is running a 792 modified configuration, then it boots normally. 794 2. The device iterates over its list of sources for bootstrapping 795 information. Details for handling different types of sources are 796 provided in subsequent sections. 798 3. If the device is able to bootstrap itself off any of the sources 799 for bootstrapping information, it runs with the new bootstrapped 800 configuration merged into its running datastore. 802 4. Otherwise the device MAY loop back through the list of 803 bootstrapping sources again or wait for manual provisioning. 805 When the source is a removable storage device, the device MUST be 806 able to read from it signed data (see term) and validate that the 807 data was signed by its rightful owner, using the algorithm in 808 Section 5.3. 810 When the source is a DHCP server, the device MUST be able to read 811 from it signed data (see term) and validate that the data was signed 812 by its rightful owner, using the algorithm in Section 5.3. 814 When the source is a bootstrap server, that is, using the RESTCONF 815 API presented in Section 6.4, the device MUST be able to authenticate 816 the server using one of the the device's preconfigured trust anchors. 818 Once done authenticating the bootstrap server, the device MUST 819 attempt to fetch the bootstrapping data hosted for it there, using 820 its unique identifier (e.g., serial number) as the key into the 821 "device" list. If bootstrapping data is found and it is signed, then 822 the device MUST first validate that the data was signed by its 823 rightful owner using the algorithm in Section 5.3. The device then 824 processes the bootstrapping data as described in Section 5.4. The 825 device MAY post progress notification messages to the server, but 826 SHOULD only do so if it has first authenticated itself to the server 827 (e.g., client authentication). 829 5.3. Validating Signed Data 831 If the device is ever presented signed data, it MUST validate the 832 signed data as described in this section. 834 Whenever there is signed data, the device MUST also be provided an 835 Ownership Voucher and an Owner Certificate. 837 The device MUST first authenticate the Ownership Voucher by 838 validating the signature on it to one of its preconfigured trust 839 anchors (see Section 5.1) and verify that the voucher contains the 840 device's unique identifier (e.g., serial number). If the 841 authentication of the voucher is successful, the device extracts the 842 Rightful Owner's identity from the voucher for use in the next step. 844 Next the device MUST authenticate the Owner Certificate by performing 845 X.509 certificate path validation on it to one of its preconfigured 846 trust anchors (see Section 5.1) and by verifying that the Subject 847 contained in the certificate matches the Rightful Owner identity 848 extracted from the voucher in the previous step. If the 849 authentication of the certificate is successful, the device extracts 850 the Owner's public key from the certificate for use in the next step. 852 Finally the device MUST authenticate the signed data by verifying the 853 signature on it was generated by the private key matching the public 854 key extracted from the Owner Certificate in the previous step. 856 If any of these steps fail, then the device MUST mark the data as 857 invalid and not perform any of the subsequent steps. 859 5.4. Processing Bootstrap Data 861 In order to process bootstrapping data, the device MUST follow the 862 steps presented in this section. 864 If the data is redirect-information (see Section 2.4), the device 865 MUST immediately attempt to establish a RESTCONF connection to the 866 provided bootstrap server IP address or hostname. If a hostname is 867 provided and DNS resolves it to more than one IP address, the device 868 MUST attempt to try to connect to all of them, until it is able to 869 successfully bootstrap off one of them. The device MUST authenticate 870 the bootstrap server's TLS certificate using the X.509 certificate 871 provided by the redirect information. 873 If the data is bootstrap-information (see Section 2.4), the device 874 MUST first check if it contains any boot-image information and, if 875 so, check to see if it differs from what the device is currently 876 running and, if so, install the boot-image using the provided URI and 877 reboot (Note, it is assumed that the boot-image contains an embedded 878 signature that the installation step will verify). This will cause 879 the device's bootstrap logic to restart, which will again come to 880 this point, though with a matching boot-image, thus letting the 881 device to proceed past this step. Next the device MUST process the 882 configuration contained in the bootstrapping information, by merging 883 it into its running configuration. 885 At this point, the device has completely processed the bootstrapping 886 data and is "bootstrap complete". If the configuration configured 887 the device it initiate a call home connection, it would proceed to do 888 so now. Otherwise, the device would wait for a NETCONF or RESTCONF 889 client to connect to it. 891 6. YANG-defined API and Artifacts 893 Central to the solution presented in this document is the use of a 894 YANG module [RFC6020] to simultaneously define a RESTCONF based API 895 for a bootstrap/redirect server as well as the encoding for signed 896 artifacts that can be conveyed outside of the RESTCONF protocol 897 (DHCP, FTP, TFTP, etc.). 899 6.1. Module Overview 901 The following tree diagram Section 1.3 provides an overview for both 902 the API and artifacts that can be used outside of RESTCONF. 904 module: ietf-zerotouch-bootstrap-server 905 +--ro devices 906 +--ro device* [unique-id] 907 +--ro unique-id string 908 +--ro (type)? 909 | +--:(redirect-information) 910 | | +--ro redirect-information 911 | | +--ro address inet:host 912 | | +--ro trust-anchor binary 913 | | +--ro signature? string 914 | +--:(bootstrap-information) 915 | +--ro bootstrap-information 916 | +--ro boot-image 917 | | +--ro name string 918 | | +--ro md5 string 919 | | +--ro sha1 string 920 | | +--ro path string 921 | | +--ro signature? string 922 | +--ro configuration 923 | +--ro config 924 | +--ro signature? string 925 +--ro ownership-voucher 926 | +--ro voucher binary 927 | +--ro issuer-crl? string 928 +--ro owner-certificate 929 | +--ro certificate string 930 | +--ro issuer-crl? string 931 +---x notification 932 +---w input 933 +---w type enumeration 934 +---w message? string 935 +---w ssh-host-keys 936 +---w ssh-host-key* 937 +---w format enumeration 938 +---w key-data string 940 In the above diagram, notice that all of the protocol accessible node 941 are read-only, to assert that devices can only pull data from the 942 bootstrap server. 944 Also notice that the module defines an action statement, which 945 devices may use to provide progress notifications to the Bootstrap 946 Server. 948 6.2. API Examples 950 This section presents some examples illustrating device interactions 951 with a Bootstrap Server to access Redirect and Bootstrap information, 952 both unsigned and signed, as well as to send a progress notification. 954 6.2.1. Unsigned Redirect Information 956 The following example illustrates a device using the API to fetch its 957 bootstrapping data. In this example, the device receives unsigned 958 redirect information. This example is representative of a response a 959 well-known Internet facing redirect service might return. 961 REQUEST 962 ------- 963 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 964 HOST: example.com 965 Accept: application/yang.data+xml 967 RESPONSE 968 -------- 969 HTTP/1.1 200 OK 970 Date: Sat, 31 Oct 2015 17:02:40 GMT 971 Server: example-server 972 Content-Type: application/yang.data+xml 974 975 976 123456789 977 978
phs.example.com
979 980 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 981 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 982 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 983 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 984 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 985 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 986 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 987 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 988 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 989 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 990 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 991 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 992 RJSUJQFRStS0Cg== 993 994 995 996 998 6.2.2. Signed Redirect Information 1000 The following example illustrates a device using the API to fetch its 1001 bootstrapping data. In this example, the device receives signed 1002 redirect information. This example is representative of a response 1003 that redirect service might return if concerned the device might not 1004 be able to authenticate its TLS certificate. 1006 REQUEST 1007 ------- 1008 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 1009 HOST: example.com 1010 Accept: application/yang.data+xml 1012 RESPONSE 1013 -------- 1014 HTTP/1.1 200 OK 1015 Date: Sat, 31 Oct 2015 17:02:40 GMT 1016 Server: example-server 1017 Content-Type: application/yang.data+xml 1019 1020 1021 123456789 1022 1023
phs.example.com
1024 1025 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 1026 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 1027 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 1028 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 1029 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 1030 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 1031 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 1032 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 1033 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 1034 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 1035 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 1036 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 1037 RJSUJQFRStS0Cg== 1038 1039 1040 SomeSignatureString 1041 1042 1043 1044 1045 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1046 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1047 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1048 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1049 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1050 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1051 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1052 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1053 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1054 MjAO 1055 1056 1057 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1058 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1059 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1060 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1061 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1062 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1063 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1064 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1065 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1066 1067 1068 1069 1070 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1071 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1072 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1073 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1074 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1075 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1076 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1077 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1078 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X 1079 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1080 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1081 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C 1082 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1083 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1084 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1085 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1086 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1087 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1088 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1089 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1090 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 1091 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K 1092 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y 1093 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo 1094 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 1095 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1096 1097 1098 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1099 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1100 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1101 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1102 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1103 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1104 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1105 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1106 MjAO== 1107 1108 1109 1110 1112 6.2.3. Unsigned Bootstrap Information 1114 The following example illustrates a device using the API to fetch its 1115 bootstrapping data. In this example, the device receives unsigned 1116 bootstrapping information. This example is representative of a 1117 response a locally deployed bootstrap server might return. 1119 REQUEST 1120 ------- 1121 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 1122 HOST: example.com 1123 Accept: application/yang.data+xml 1125 RESPONSE 1126 -------- 1127 HTTP/1.1 200 OK 1128 Date: Sat, 31 Oct 2015 17:02:40 GMT 1129 Server: example-server 1130 Content-Type: application/yang.data+xml 1132 1133 1134 123456789 1135 1136 1137 1138 boot-image-v3.2R1.6.img 1139 1140 1141 SomeMD5String 1142 1143 1144 SomeSha1String 1145 1146 1147 /some/path/to/raw/file 1149 1150 1151 1152 1153 1154 1155 1156 1157 admin 1158 1159 admin's rsa ssh host-key 1160 ssh-rsa 1161 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1162 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1163 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1164 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1165 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1166 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1167 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1168 1169 1170 1171 1172 1173 1174 1175 1176 config-mgr 1177 1178 1179 1180 east-data-center 1181
11.22.33.44
1182 1183 1184 west-data-center 1185
55.66.77.88
1186 1187 1188 1189 my-call-home-x509-key 1190 1191 1192 1193 1194 1195 1196 1198 1199 1200 1202 6.2.4. Signed Bootstrap Information 1204 The following example illustrates a device using the API to fetch its 1205 bootstrapping data. In this example, the device receives signed 1206 bootstrapping information. This example is representative of a 1207 response that bootstrap service might return if concerned the device 1208 might not be able to authenticate its TLS certificate. 1210 REQUEST 1211 ------- 1212 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456 HTTP/1.1 1213 HOST: example.com 1214 Accept: application/yang.data+xml 1216 RESPONSE 1217 -------- 1218 HTTP/1.1 200 OK 1219 Date: Sat, 31 Oct 2015 17:02:40 GMT 1220 Server: example-server 1221 Content-Type: application/yang.data+xml 1223 1224 1225 123456789 1226 1227 1228 1229 boot-image-v3.2R1.6.img 1230 1231 1232 SomeMD5String 1233 1234 1235 SomeSha1String 1236 1237 1238 /some/path/to/raw/file 1239 1240 1241 SomeSignatureString 1242 1243 1244 1245 1246 1247 1248 1249 1250 admin 1251 1252 admin's rsa ssh host-key 1253 ssh-rsa 1254 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1255 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1256 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1257 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1258 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1259 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1260 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1261 1262 1263 1264 1265 1266 1267 1268 1269 config-mgr 1270 1271 1272 1273 east-data-center 1274
11.22.33.44
1275 1276 1277 west-data-center 1278
55.66.77.88
1279 1280 1281 1282 my-call-home-x509-key 1283 1284 1285 1286 1287 1288 1289 1290 SomeSignatureString 1291 1292 1294 1295 1296 1297 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1298 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1299 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1300 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1301 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1302 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1303 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1304 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1305 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1306 MjAO 1307 1308 1309 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1310 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1311 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1312 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1313 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1314 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1315 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1316 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1317 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1318 1319 1320 1321 1322 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1323 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1324 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1325 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1326 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1327 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1328 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1329 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1330 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X 1331 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1332 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1333 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C 1334 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1335 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1336 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1337 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1338 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1339 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1340 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1341 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1342 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 1343 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K 1344 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y 1345 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo 1346 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 1347 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1348 1349 1350 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1351 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1352 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1353 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1354 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1355 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1356 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1357 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1358 MjAO== 1359 1360 1361 1362 1364 6.2.5. Progress Notifications 1366 The following example illustrates a device using the API to post a 1367 notification to the server. The device may send more than one 1368 notification to the server (e.g., to provide status updates). The 1369 YANG module defines only one notification type, bootstrap-complete. 1370 Other notification types may be defined through YANG augmentation. 1372 The bootstrap server MUST NOT process a notification from a device 1373 without first authenticating the device. This is in contrast to when 1374 a device is fetching data from the server, a read-only operation, in 1375 which case device authentication is not strictly required. 1377 In this example, the device sends a notification indicating that it 1378 has completed bootstrapping off the data provided by the server. 1379 This example also illustrates the device sending its SSH host keys to 1380 the bootstrap server, which it might, for example, forward onto a 1381 downstream NMS component, so that it can subsequently authenticate 1382 the device when establishing a NETCONF over SSH connection to it. 1384 A device providing its SSH host key or TLS server certificate is not 1385 needed when the device has an IDevID certificate [Std-802.1AR-2009] 1386 and is able to present the IDevID certificate as its SSH host key or 1387 TLS server certificate, when establishing a NETCONF or RESTCONF 1388 connection. 1390 REQUEST 1391 ------- 1392 POST https://example.com/restconf/data/ietf-zerotouch-bootstrap-server::devices/device=123456/notification HTTP/1.1 1393 HOST: example.com 1394 Content-Type: application/yang.data+xml 1396 1397 bootstrap-complete 1398 example message 1399 1400 1401 ssh-rsa 1402 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1403 1404 1405 ssh-dsa 1406 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRCjCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2MwjE1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcCWAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWqEIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1407 1408 1409 1411 RESPONSE 1412 -------- 1413 HTTP/1.1 204 No Content 1414 Date: Sat, 31 Oct 2015 17:02:40 GMT 1415 Server: example-server 1417 6.3. Artifact Examples 1419 This section presents some examples for how the same information 1420 provided by the API can be packaged into stand alone artifacts. The 1421 encoding for these artifacts is the same as if an HTTP GET request 1422 had been sent to the RESTCONF URL for the specific resource. 1424 Encoding these artifacts for use outside of the RESTCONF protocol 1425 extends their utility for other deployment scenarios, such as when a 1426 local DHCP server or a removable storage device is used. By way of 1427 example, this may be done to address an inability for the device to 1428 access an Internet facing bootstrap/redirect server, or just for a 1429 preference to use locally deployed infrastructure. 1431 6.3.1. Signed Redirect Information 1433 The following example illustrates how a redirect can be encoded into 1434 an artifact for use outside of the RESTCONF protocol. The redirect 1435 information is signed so that it is secure even when no transport- 1436 level security is provided. 1438 1439
phs.example.com
1440 1441 WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM 1442 lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk 1443 zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot 1444 NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd 1445 VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER 1446 V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF 1447 NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC 1448 Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN 1449 WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW 1450 QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ 1451 MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ 1452 25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2 1453 RJSUJQFRStS0Cg== 1454 1455 1456 SomeSignatureString 1457 1458 1460 6.3.2. Signed Bootstrap Information 1462 The following example illustrates how bootstrapping data can be 1463 encoded into an artifact for use outside of the RESTCONF protocol. 1464 The bootstrapping information is signed so that it is secure when no 1465 transport-level security is provided. 1467 1468 1469 1470 boot-image-v3.2R1.6.img 1471 1472 1473 SomeMD5String 1474 1475 1476 SomeSha1String 1477 1478 1479 /some/path/to/raw/file 1480 1481 1482 SomeSignatureString 1483 1484 1485 1486 1487 1488 1489 1490 1491 admin 1492 1493 admin's rsa ssh host-key 1494 ssh-rsa 1495 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1496 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1497 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1498 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1499 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1500 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1501 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1502 1503 1504 1505 1506 1507 1508 1509 1510 config-mgr 1511 1512 1513 1514 east-data-center 1515
11.22.33.44
1516 1517 1518 west-data-center 1519
55.66.77.88
1520 1521 1522 1523 my-call-home-x509-key 1524 1525 1526 1527 1528 1529 1530 1531 SomeSignatureString 1532 1533 1535 1537 6.3.3. Owner Certificate 1539 The following example illustrates how the owner certificate, along 1540 with its CRL, can be encoded into an artifact for use outside of the 1541 RESTCONF protocol. As the Owner Certificate and CRL are already 1542 signed by the manufacturer, an additional owner signature is 1543 unnecessary. 1545 1546 1547 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1548 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1549 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1550 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1551 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1552 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1553 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1554 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1555 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X 1556 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1557 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1558 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C 1559 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1560 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1561 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1562 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1563 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1564 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1565 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1566 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1567 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 1568 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K 1569 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y 1570 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo 1571 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 1572 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1573 1574 1575 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1576 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1577 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1578 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1579 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1580 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1581 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1582 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1583 MjAO== 1584 1585 1587 6.3.4. Ownership Voucher 1589 The following example illustrates how the ownership voucher, along 1590 with its CRL, can be encoded into an artifact for use outside of the 1591 RESTCONF protocol. As the Ownership Voucher and CRL are already 1592 signed by the manufacturer, an additional owner signature is 1593 unnecessary. 1595 1596 1597 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1598 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1599 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1600 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1601 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1602 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1603 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1604 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1605 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1606 MjAO 1607 1608 1609 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1610 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1611 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1612 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1613 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1614 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1615 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1616 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1617 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX= 1618 1619 1621 6.4. YANG Module 1623 The bootstrap server's device-facing interface is normatively defined 1624 by the following YANG module: 1626 file "ietf-zerotouch-bootstrap-server@2015-10-19.yang" 1628 module ietf-zerotouch-bootstrap-server { 1630 namespace 1631 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 1632 prefix "ztbs"; 1634 import ietf-inet-types { // RFC 6991 1635 prefix inet; 1636 } 1638 organization 1639 "IETF NETCONF (Network Configuration) Working Group"; 1641 contact 1642 "WG Web: 1643 WG List: 1644 WG Chair: Mehmet Ersue 1645 1646 WG Chair: Mahesh Jethanandani 1647 1648 Editor: Kent Watsen 1649 "; 1651 description 1652 "This module defines the southbound interface for Zero Touch 1653 bootstrap servers. 1655 Copyright (c) 2014 IETF Trust and the persons identified as 1656 authors of the code. All rights reserved. 1658 Redistribution and use in source and binary forms, with or 1659 without modification, is permitted pursuant to, and subject 1660 to the license terms contained in, the Simplified BSD 1661 License set forth in Section 4.c of the IETF Trust's 1662 Legal Provisions Relating to IETF Documents 1663 (http://trustee.ietf.org/license-info). 1665 This version of this YANG module is part of RFC XXXX; see 1666 the RFC itself for full legal notices."; 1668 revision "2015-10-19" { 1669 description 1670 "Initial version"; 1671 reference 1672 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 1673 } 1675 grouping redirect-information-grouping { 1676 description 1677 "This container contains information the device may use 1678 to redirect it to another bootstrap server."; 1680 leaf address { 1681 type inet:host; 1682 mandatory true; 1683 description 1684 "The IP address or hostname of the bootstrap server 1685 the device should redirect to."; 1686 } 1687 leaf trust-anchor { 1688 type binary; 1689 mandatory true; 1690 description 1691 "A certificate that a device can use as a trust anchor to 1692 authenticate the bootstrap server it is being redirected 1693 to. The binary certificate structure as specified by RFC 1694 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>; 1695 "; 1696 reference 1697 "RFC 5246: The Transport Layer Security (TLS) 1698 Protocol Version 1.2"; 1699 } 1701 leaf signature { 1702 type string; 1703 must "../../ownership-voucher"; 1704 description 1705 "The signature over the concatenation of the previous leafs 1706 using the organization's private key. Specifically, 1707 sign(name+md5+sha1+path), where simple string concatenation 1708 to join values is used, resulting in a single null-terminated 1709 string."; 1710 } 1712 } 1714 grouping bootstrap-information-grouping { 1716 container boot-image { 1717 description 1718 "It is intended that the device will fetch this container 1719 as a whole, as it contains values that need to be 1720 processed together."; 1721 leaf name { 1722 type string; 1723 mandatory true; 1724 description 1725 "The name of the image of software the device is expected 1726 to be running."; 1727 } 1728 leaf md5 { 1729 type string; 1730 mandatory true; 1731 description 1732 "The output of the MD5 hash algorithm over the image file."; 1734 } 1735 leaf sha1 { 1736 type string; 1737 mandatory true; 1738 description 1739 "The output of the SHA-1 hash algorithm over the image file."; 1740 } 1741 leaf path { 1742 type string; 1743 mandatory true; 1744 description 1745 "An absolute path to the boot-image file hosted on this 1746 Bootstrap server."; 1747 } 1748 leaf signature { 1749 type string; 1750 must "../../../ownership-voucher"; 1751 description 1752 "The signature over the concatenation of the previous leafs 1753 using the organization's private key. Specifically, 1754 sign(name+md5+sha1+path), where simple string concatenation 1755 to join values is used, resulting in a single null-terminated 1756 string."; 1757 } 1758 } 1760 container configuration { 1761 description 1762 "It is intended that the device will fetch this container 1763 as a whole, as its contents need to be processed together."; 1764 anyxml config { 1765 mandatory true; 1766 description 1767 "Any configuration data model known to the device. It may 1768 contain Vendor-specific and/or standards-based data models. 1769 An example configuration using a couple IETF-defined data 1770 models is presented the Appendix of RFC XXXX."; 1771 } 1772 leaf signature { 1773 type string; 1774 must "../../../ownership-voucher"; 1775 description 1776 "The signature over the concatenation of the previous leaf 1777 using the organization's private key. Specifically, 1778 sign(config), where 'config' is treated as a single null- 1779 terminated string."; 1780 } 1781 } 1783 } 1785 grouping owner-certificate-grouping { 1787 leaf certificate { 1788 type string; 1789 mandatory true; 1790 description 1791 "This is an X.509 certificate, signed by a Vendor, for 1792 a business organization. This certificate must encode a 1793 Vendor-assigned value identifying the organization. This 1794 identifier must match the owner identifier encoded in 1795 the Ownership Voucher."; 1796 } 1797 leaf issuer-crl { 1798 type string; 1799 description 1800 "An optional CRL for the issuer used by the 1801 Vendor to sign Owner Certificates. The CRL should be 1802 as up to date as possible. This leaf is optional as 1803 it is primarily to support deployments where the device 1804 is unable to download the CRL from the CRL distribution 1805 point URLs listed in the Vendor's trust anchor 1806 certificate."; 1807 } 1808 } 1810 grouping ownership-voucher-grouping { 1811 leaf voucher { 1812 type binary; 1813 mandatory true; 1814 description 1815 "A Vendor-specific encoding binding unique device 1816 identifiers to an owner identifier value matching the 1817 value encoded in the owner-certificate below. An 1818 example format for a voucher is presented in the 1819 Appendix of RFC XXXX."; 1820 } 1821 leaf issuer-crl { 1822 type string; 1823 description 1824 "An optional CRL for the issuer used by the 1825 Vendor to sign Ownership Vouchers. The CRL should be 1826 as up to date as possible. This leaf is optional as 1827 it is primarily to support deployments where the device 1828 is unable to download the CRL from the CRL distribution 1829 point URLs listed in the Vendor's trust anchor 1830 certificate."; 1831 } 1832 } 1834 container devices { 1835 config false; 1836 description 1837 "A read-only list of device entries"; 1838 list device { 1840 key unique-id; 1841 leaf unique-id { 1842 type string; 1843 description 1844 "A unique identifier for the device (e.g., serial number). 1845 Each device accesses its bootstrapping record by its unique 1846 identifier."; 1847 } 1849 choice type { 1851 container redirect-information { 1852 uses redirect-information-grouping; 1853 } 1855 container bootstrap-information { 1856 uses bootstrap-information-grouping; 1857 } 1859 } 1861 container ownership-voucher { 1862 description 1863 "This container contains the Ownership Voucher that the 1864 device uses to ascertain the identity of its rightful 1865 owner, as certified by its Vendor."; 1867 when "../redirect-information/signature or ../bootstrap-information/*/signature"; 1868 //must "../owner-certificate and ../redirect-information/signature or ../bootstrap-information/*/signature"; 1869 must "../owner-certificate"; 1871 uses ownership-voucher-grouping; 1872 } 1874 container owner-certificate { 1875 description 1876 "It is intended that the device will fetch this container 1877 as a whole, as it contains values that need to be 1878 processed together."; 1880 when "../ownership-voucher"; 1881 //must "../ownership-voucher and ../redirect-information/signature or ../bootstrap-information/*/signature"; 1883 uses owner-certificate-grouping; 1884 } 1886 action notification { 1887 input { 1888 leaf type { 1889 type enumeration { 1890 enum bootstrap-complete { 1891 description 1892 "Indicates that the device successfully processed the 1893 bootstrap data, that is currently running the specified 1894 boot image and has committed the configuration. At 1895 this point, the device is ready to be managed by an 1896 external NMS system. The device is never expected 1897 access the bootstrap server again, unless reset to 1898 its factory default again."; 1899 } 1900 } 1901 mandatory true; 1902 } 1903 leaf message { 1904 type string; 1905 description 1906 "A human-readable value."; 1907 } 1908 container ssh-host-keys { 1909 list ssh-host-key { 1910 when "../type = bootstrap-complete"; 1911 leaf format { 1912 type enumeration { 1913 enum ssh-dss; 1914 enum ssh-rsa; 1915 } 1916 mandatory true; 1917 } 1918 leaf key-data { 1919 type string; 1920 mandatory true; 1921 } 1922 } 1923 } 1924 } 1926 } // end action 1927 } 1928 } 1930 } 1932 1934 7. Security Considerations 1936 7.1. Immutable storage for trust anchors 1938 Devices MUST ensure that all their trust anchor certificates, 1939 including those for the Owner Certificate and Ownership Voucher, are 1940 protected from external modification. 1942 It may be necessary to update these certificates over time (e.g., the 1943 manufacturer wants to delegate trust to a new CA). It is therefore 1944 expected that devices MAY update these trust anchors when needed 1945 through a verifiable process, such as a software upgrade using signed 1946 software images. 1948 7.2. Real time clock 1950 The solution for signed data includes validating Owner Certificates 1951 and Ownership Vouchers, each of which may contain expirations. 1952 Further, the solution includes using a CRLs, which also require 1953 freshness. Device implementations should take care to ensure the 1954 devices have a reliable clock when processing signed data. 1956 7.3. Entropy loss over time 1958 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 1959 IDevID certificate should never expire (i.e. having a notAfter 1960 99991231235959Z). Given the long-lived nature of these certificates, 1961 it is paramount to use a strong key length (e.g., 512-bit ECC). 1962 Manufacturers SHOULD deploy Online Certificate State Protocol (OCSP) 1963 responders or CRL Distribution Points (CDP) to revoke certificates in 1964 case necessary. 1966 7.4. Serial Numbers 1968 This draft suggests using the device's serial number as the unique 1969 identifier in its IDevID certificate. This is because serial numbers 1970 are ubiquitous and prominently contained in invoices and on labels 1971 affixed to devices and their packaging. That said, serial numbers 1972 many times encode revealing information, such as the device's model 1973 number, manufacture date, and/or sequence number. Knowledge of this 1974 information may provide an adversary with details needed to launch an 1975 attack. 1977 8. IANA Considerations 1979 Editor Note: this section needs to be rewritten to use the redirect 1980 and bootstrap information types (see Section 2.4). 1982 8.1. Zero Touch Information DHCP Options 1984 The following registrations are in accordance to RFC 2939 for "BOOTP 1985 Manufacturer Extensions and DHCP Options" registry maintained at 1986 http://www.iana.org/assignments/bootp-dhcp-parameters. 1988 8.1.1. DHCP v4 Option 1990 Tag: XXX 1992 Name: Zero Touch Information 1994 Description: Returns a list of null-terminated Configuration 1995 Server hostnames and/or IP addresses. 1997 Code Len 1998 +-----+-----+------+------+---- 1999 | XXX | n | svr1 | svr2 | ... 2000 +-----+-----+------+------+---- 2002 Reference: RFC XXXX 2004 8.1.2. DHCP v6 Option 2006 Tag: YYY 2008 Name: Zero Touch Information 2010 Description: Returns a list of null-terminated Configuration 2011 Server hostnames and/or IP addresses. 2013 Code Len 2014 +-----+-----+------+------+---- 2015 | YYY | n | svr1 | svr2 | ... 2016 +-----+-----+------+------+---- 2018 Reference: RFC XXXX 2020 9. Acknowledgements 2022 The authors would like to thank for following for lively discussions 2023 on list and in the halls (ordered by last name): David Harrington, 2024 Dean Bogdanovic, Martin Bjorklund, Max Pritikin, Stephen Hanna, Wes 2025 Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Juergen 2026 Schoenwaelder. 2028 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 2029 brainstorming the original I-D's solution during the IETF 87 meeting 2030 in Berlin. 2032 10. References 2034 10.1. Normative References 2036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2037 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2038 RFC2119, March 1997, 2039 . 2041 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2042 the Network Configuration Protocol (NETCONF)", RFC 6020, 2043 DOI 10.17487/RFC6020, October 2010, 2044 . 2046 [Std-802.1AR-2009] 2047 IEEE SA-Standards Board, "IEEE Standard for Local and 2048 metropolitan area networks - Secure Device Identity", 2049 December 2009, . 2052 [draft-ietf-netconf-call-home] 2053 Watsen, K., "NETCONF Call Home (work in progress)", 2054 October 2014, . 2057 [draft-ietf-netconf-restconf] 2058 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2059 Protocol", draft-ieft-netconf-restconf-04 (work in 2060 progress), 2014, . 2063 [draft-ietf-netconf-server-model] 2064 Watsen, K., "NETCONF Server Model (work in progress)", 2065 September 2014, . 2068 10.2. Informative References 2070 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2071 and A. Bierman, Ed., "Network Configuration Protocol 2072 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2073 . 2075 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2076 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2077 2014, . 2079 Appendix A. Examples 2081 A.1. Ownership Voucher 2083 Following describes an example data-model for an Ownership Voucher. 2084 Real vouchers are expected to be encoded in a Manufacturer-specific 2085 format outside the of scope for this draft. 2087 A tree diagram describing an Ownership Voucher: 2089 module: ietf-zerotouch-ownership-voucher 2090 +--rw voucher 2091 +--rw owner-id string 2092 +--rw unique-id* string 2093 +--rw created-on yang:date-and-time 2094 +--rw expires-on? yang:date-and-time 2095 +--rw signature string 2097 The YANG module for this example voucher: 2099 file "ietf-zerotouch-ownership-voucher@2015-10-19.yang" 2101 module ietf-zerotouch-ownership-voucher { 2103 namespace 2104 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher"; 2105 prefix "ztov"; 2107 import ietf-yang-types { prefix yang; } 2109 organization 2110 "IETF NETCONF (Network Configuration) Working Group"; 2112 contact 2113 "WG Web: 2114 WG List: 2115 WG Chair: Mehmet Ersue 2116 2117 WG Chair: Mahesh Jethanandani 2118 2119 Editor: Kent Watsen 2120 "; 2122 description 2123 "This module defines the format for a ZeroTouch ownership voucher, 2124 which is produced by Vendors, relayed by Bootstrap Servers, and 2125 consumed by devices. The purpose of the voucher is to enable a 2126 device to ascertain the identity of its rightful owner, as 2127 certified by its Vendor. 2129 Copyright (c) 2014 IETF Trust and the persons identified as 2130 authors of the code. All rights reserved. 2132 Redistribution and use in source and binary forms, with or 2133 without modification, is permitted pursuant to, and subject 2134 to the license terms contained in, the Simplified BSD 2135 License set forth in Section 4.c of the IETF Trust's 2136 Legal Provisions Relating to IETF Documents 2137 (http://trustee.ietf.org/license-info). 2139 This version of this YANG module is part of RFC XXXX; see 2140 the RFC itself for full legal notices."; 2142 revision "2015-10-19" { 2143 description 2144 "Initial version"; 2145 reference 2146 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 2147 } 2149 // top-level container 2150 container voucher { 2151 description 2152 "A voucher, containing the owner's identifier, a list of 2153 device's unique identifiers, information on when the 2154 voucher was created, when it might expire, and the 2155 vendor's signature over the above values."; 2156 leaf owner-id { 2157 type string; 2158 mandatory true; 2159 description 2160 "A Vendor-assigned value for the rightful owner of the 2161 devices enumerated by this voucher. The owner-id value 2162 must match the value in the owner-certificate below"; 2163 } 2164 leaf-list unique-id { 2165 type string; 2166 min-elements 1; 2167 description 2168 "The unique identifier (e.g., serial-number) for a device. 2169 The value must match the value in the device's IDevID 2170 certificate. A device uses this value to determine if 2171 the voucher applies to it."; 2172 } 2173 leaf created-on { 2174 type yang:date-and-time; 2175 mandatory true; 2176 description 2177 "The date this voucher was created"; 2178 } 2179 leaf expires-on { 2180 type yang:date-and-time; 2181 description 2182 "The date this voucher expires, if at all. Use of this 2183 value requires that the device has access to a trusted 2184 real time clock"; 2185 } 2186 leaf signature { 2187 type string; 2188 mandatory true; 2189 description 2190 "The signature over the concatenation of all the previous 2191 values"; 2192 } 2193 } 2194 } 2196 2198 Appendix B. Change Log 2200 B.1. ID to 00 2202 o Major structural update; the essence is the same. Most every 2203 section was rewritten to some degree. 2205 o Added a Use Cases section 2207 o Added diagrams for "Actors and Roles" and "NMS Precondition" 2208 sections, and greatly improved the "Device Boot Sequence" diagram 2210 o Removed support for physical presence or any ability for 2211 Configlets to not be signed. 2213 o Defined the Zero Touch Information DHCP option 2215 o Added an ability for devices to also download images from 2216 Configuration Servers 2218 o Added an ability for Configlets to be encrypted 2219 o Now Configuration Servers only have to support HTTP/S - no other 2220 schemes possible 2222 B.2. 00 to 01 2224 o Added boot-image and validate-owner annotations to the "Actors and 2225 Roles" diagram. 2227 o Fixed 2nd paragraph in section 7.1 to reflect current use of 2228 anyxml. 2230 o Added encrypted and signed-encrypted examples 2232 o Replaced YANG module with XSD schema 2234 o Added IANA request for the Zero Touch Information DHCP Option 2236 o Added IANA request for media types for boot-image and 2237 configuration 2239 B.3. 01 to 02 2241 o Replaced the need for a Configuration Signer with the ability for 2242 each NMS to be able to sign its own configurations, using 2243 Manufacturer signed Ownership Vouchers and Owner certificates. 2245 o Renamed Configuration Server to Bootstrap Server, a more 2246 representative name given the information devices download from 2247 it. 2249 o Replaced the concept of a Configlet by defining a southbound 2250 interface for the Bootstrap Server using YANG. 2252 o Removed the IANA request for the boot-image and configuration 2253 media types 2255 B.4. 02 to 03 2257 o Minor update, mostly just to add an Editor's Note to show how this 2258 draft might integrate with the draft-pritikin-anima-bootstrapping- 2259 keyinfra. 2261 B.5. 03 to 04 2263 o Major update formally introducing unsigned data and support for 2264 Internet-based redirect servers. 2266 o Added many terms to Terminology section. 2268 o Added all new "Guiding Principles" section. 2270 o Added all new "Sources for Bootstrapping Data" section. 2272 o Rewrote the "Interactions" section and renamed it "Workflow 2273 Overview". 2275 Authors' Addresses 2277 Kent Watsen 2278 Juniper Networks 2280 EMail: kwatsen@juniper.net 2282 Joe Clarke 2283 Cisco Systems 2285 EMail: jclarke@cisco.com 2287 Mikael Abrahamsson 2288 T-Systems 2290 EMail: "mikael.abrahamsson@t-systems.se