idnits 2.17.1 draft-ietf-netconf-zerotouch-03.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 10 instances of too long lines in the document, the longest one being 3 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 500 has weird spacing: '...ificate str...' == Line 507 has weird spacing: '...gnature str...' == Line 510 has weird spacing: '...gnature str...' == Line 520 has weird spacing: '...ey-data str...' == Line 1288 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 (July 6, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6187' is defined on line 1240, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: January 7, 2016 Cisco Systems 6 M. Abrahamsson 7 T-Systems 8 July 6, 2015 10 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) 11 draft-ietf-netconf-zerotouch-03 13 Abstract 15 This draft presents a technique for establishing a secure NETCONF 16 connection between a newly deployed IP-based 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 January 7, 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. Editor's Note . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 59 2. High-level Design . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Interactions . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Bootstrap Server . . . . . . . . . . . . . . . . . . . . . . 11 63 3.1. Northbound Interface . . . . . . . . . . . . . . . . . . 11 64 3.2. Southbound Interface . . . . . . . . . . . . . . . . . . 11 65 4. Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 4.1. Factory Default State . . . . . . . . . . . . . . . . . . 20 67 4.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 21 68 5. Network Management System (NMS) . . . . . . . . . . . . . . . 25 69 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25 70 5.2. Precondition . . . . . . . . . . . . . . . . . . . . . . 25 71 5.3. Connection Handling . . . . . . . . . . . . . . . . . . . 26 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 73 6.1. Entropy loss over time . . . . . . . . . . . . . . . . . 26 74 6.2. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 26 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 7.1. ZeroTouch Information DHCP Options . . . . . . . . . . . 27 77 7.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 27 78 7.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 27 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 82 9.2. Informative References . . . . . . . . . . . . . . . . . 28 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29 84 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 29 85 A.2. Bootstrap Server's API . . . . . . . . . . . . . . . . . 31 86 A.3. Bootstrap Configuration . . . . . . . . . . . . . . . . . 31 87 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 88 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 33 89 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 33 90 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 33 91 B.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 34 93 1. Introduction 95 A fundamental business requirement is to reduce costs where possible. 96 For network operators, deploying devices to many locations can be a 97 significant cost, as sending trained specialists to each site to do 98 installations is both cost prohibitive and does not scale. 100 The solution presented herein enables a device to securely obtain a 101 bootstrapping configuration from the network without any operator 102 input. Significantly, this configuration may configure the device to 103 securely call home using NETCONF Call Home 104 [draft-ietf-netconf-call-home]. 106 Central to this solution is the device being able to process a set of 107 files locally, without any need to reach out to the network again. 108 As consequence, how the files are obtained is not critical to the 109 security of the solution. The files can be read over any networking 110 layer or medium. By example, the files could be loaded using a USB 111 flash drive physically plugged into a device. 113 1.1. Editor's Note 115 This draft defines a solution that differs from the solution 116 presented in [draft-pritikin-anima-bootstrapping-keyinfra]. Yet it 117 is this author's opinion that it should be possible for both 118 solutions to co-exist simultaneously. How to integrate them is 119 discussed in this section. 121 Already the ANIMA draft defines in Section #3 the progression of 122 first searching link-local, then the local network (e.g., DHCP 123 options or DNS service records), and finally trying Internet-based 124 resources. This progression makes good sense and, in general, there 125 may be other searching options before, after, or in between the ones 126 listed here (e.g., USB flash drive). The important aspect to this 127 list of options is that they're ordered so as to give priority to the 128 "closest" option. 130 It seems right that a device try all comparably-secure bootstrapping 131 options at each stage of the searching progression. For instance, an 132 integrated solution might try all comparably-secure bootstrapping 133 options when at the link-local stage, and again try all comparably- 134 secure bootstrapping options when at the local network stage, and yet 135 again try all the comparably-secure bootstrapping options when at the 136 Internet stage. 138 By trying all comparably-secure options at each stage, it 1) 139 minimizes the number of times a device needs to reconfigure its 140 networking, 2) prevents a "further away" solution for one option 141 snuffing out a closer solution for a closer solution for another 142 option, and 3) avoids having devices reach out to remote options 143 unnecessarily, and thereby reduce tracking. 145 Bootstrapping options that are not comparably-secure should not be 146 integrated as described above. Specifically, all secure 147 bootstrapping options should be attempted prior to attempting any 148 unsecure option. For instance, a device should prefer a secure 149 option with a remote server over an unsecure option available on the 150 link-local network. 152 The solution presented below does not reflect the thoughts mentioned 153 in this note. Specifically, it has no provision for using a link- 154 local address or DNS service discovery. Instead, it only assumes the 155 use of a DHCP server, potentially with DHCP options to direct the 156 device to use resources on the local network. 158 1.2. Use Cases 160 o Connecting to a remotely administered network 162 This use-case involves scenarios, such as a remote branch 163 office or convenience store, whereby a device connects as an 164 access gateway to an ISP's network. Assuming it is not 165 possible to customize the ISP's network, and with no other 166 nearby device to leverage, the device has no recourse but to 167 reach out to the public Internet for a well-known services it 168 can use to bootstrap off of. 170 o Connecting to a locally administered network 172 This use-case covers all other scenarios (including link-local) 173 and differs only in that the device may additionally leverage 174 nearby devices, which may direct it to use a local service to 175 bootstrap off of. If no such site-specific information is 176 discovered, or the device is unable to use the information 177 provided, it can then reach out to network just as it would for 178 the remotely administered network case. 180 1.3. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 184 sections below are to be interpreted as described in RFC 2119 185 [RFC2119]. 187 1.4. Tree Diagrams 189 A simplified graphical representation of the data models is used in 190 this document. The meaning of the symbols in these diagrams is as 191 follows: 193 o Brackets "[" and "]" enclose list keys. 195 o Braces "{" and "}" enclose feature names, and indicate that the 196 named feature must be present for the subtree to be present. 198 o Abbreviations before data node names: "rw" means configuration 199 (read-write) and "ro" state data (read-only). 201 o Symbols after data node names: "?" means an optional node, "!" 202 means a presence container, and "*" denotes a list and leaf-list. 204 o Parentheses enclose choice and case nodes, and case nodes are also 205 marked with a colon (":"). 207 o Ellipsis ("...") stands for contents of subtrees that are not 208 shown. 210 2. High-level Design 212 2.1. Design Overview 214 The following diagram illustrates the overall solution presented in 215 this draft. Note that some of the interactions illustrated below 216 occur at different times, only the numbered interactions (1-3) occur 217 at the time a device is bootstrapping itself. 219 manufactures 220 +----------------------------------+ 221 | | 222 | 1.discover | 223 | bootstrap | 2.fetch bootstrap 224 | information v data and provide 225 | (optional) +------+ confirmation 226 | +---------------|Device|----------------+ 227 | | +------+ | 228 | | | | 229 | v | v 230 +------+ +------+ | +---------+ 231 |Vendor| | DHCP | |3.netconf |Bootstrap| 232 +------+ |Server| | callhome | Server | 233 | ^ +------+ | +---------+ 234 | | ^ | ^ 235 | | | stage | | 236 | | | bootstrap | stage | 237 | | | information v bootstrap | 238 | | | (optional) +-------+ data | 239 | | +---------------| NMS |---------------+ 240 | | +-------+ 241 | | imports trust anchor, | ^ 242 | | signups for owner cert, | | 243 | | and orders devices | | 244 | +-------------------------------+ | 245 +------------------------------------+ 246 ships devices, provides 247 serial-numbers and/or IDevID 248 certs, and ownership vouchers 250 The boxes in this diagram are described next. A sequence diagram 251 explaining the various calls follows in Section 2.2. 253 o Vendor 255 Vendors manufacture the devices supporting NETCONF ZeroTouch. 256 To support this solution, Vendors must support a one-time 257 enrollment process per business organization owning the NMS. 258 Vendors must also support sending additional information to the 259 business organization about the devices that have been shipped 260 for device orders it places. 262 o Device 264 The devices supporting NETCONF ZeroTouch will only attempt the 265 bootstrapping process when booting with its factory default 266 configuration. As illustrated above, the bootstrapping process 267 consists of three interactions: 269 1. When joining the network, the device will attempt to 270 configure IP networking from a DHCP server. If the device 271 is able to reach a DHCP server, it may discover additional 272 bootstrapping information. The additional bootstrapping 273 information consists of one or more additional Bootstrap 274 Servers the device should try to connect to. 276 2. The device sequentially processes its list of Bootstrap 277 Servers, prioritizing any that might have been learned from 278 the DHCP server. Once the device has successfully 279 configured itself using the bootstrapping information, it 280 notifies the bootstrapping server for monitoring purposes. 282 3. Assuming the bootstrapping information configures the 283 device appropriately, the device will initiate a NETCONF 284 Call Home connection [draft-ietf-netconf-call-home]. 286 More information about Devices is in Section 4. 288 o DHCP Server 290 This draft assumes the use of a DHCP server but, in reality, 291 the solution is not intrinsically tied to using a DHCP server. 292 Any mechanism or combination of mechanisms that can provide 293 dynamic networking assignment would equally do. 295 Assuming the use of DHCP, this draft defines a specific DHCP 296 Option for the discovering of addition bootstrapping 297 information. More information about the ZeroTouch DHCP Option 298 is in Section 7.1. 300 o Bootstrap Server 302 Bootstrap Servers host the bootstrapping information staged by 303 NMSs for the devices to find. The Bootstrap Server presents a 304 simple REST interface for devices to obtain both their 305 bootstrapping information as well as notify the Bootstrapping 306 Server when it has successfully completed the bootstrapping 307 process. 309 Bootstrap Servers may be deployed on the public Internet or on 310 a local network. Devices may be preconfigured with a list of 311 well-known Bootstrap Servers. Additional Bootstrap Servers 312 (i.e. not in the device's preconfigured list) must be 313 discovered from a DHCP server. 315 How Bootstrap Servers are deployed is out of scope of this 316 draft, but there are a couple points worth noting. Firstly, it 317 is expected that Internet based Bootstrap Servers will 318 initially be hosted by Vendors, whilst waiting for 3rd-party 319 servers to become available. Secondly, it is expected that 320 locally administrated networks with in-house solutions might 321 bundle the Bootstrap Server into another system (e.g., the 322 NMS), where having the features integrated can streamline 323 various workflows. 325 More information about Bootstrap Servers is in Section 3. 327 o Network Management System 329 The NMS is a term used here loosely to represent any system, or 330 collection of systems, deployed by a business organization to 331 manage its devices. An NMS being able to establish a secure 332 NETCONF connection with devices purchased by its organization 333 is the ultimate goal of this solution presented by this draft. 334 More information about the Network Management System is in 335 Section 5. 337 2.2. Interactions 339 The following diagram illustrates the interactions between the 340 entities described in the previous section. Note that the 341 interactions can be roughly categorized as those that occur before a 342 device powers on and those that occur after a device powers on. 344 +------+ +------+ +---+ +---------+ +------+ 345 |Vendor| |Device| |NMS| |Bootstrap| | DHCP | 346 +------+ +------+ +---+ | Server | |Server| 347 | | | +---------+ +------+ 348 | | | | | 349 | 1. imports trust anchor | | | 350 |<------------------------------| | | 351 | | | | | 352 | 2. signs up for owner cert | | | 353 |<------------------------------| | | 354 | | | | | 355 | 3. orders devices | | | 356 |<------------------------------| | | 357 | | | | | 358 | 4. ships | | | | 359 |-------------->| | | | 360 | | | | | 361 | 5. provides serial-numbers | | | 362 | and/or IDevID cert(s), | | | 363 | and ownership vouchers | | | 364 |------------------------------>| | | 365 | | | 6.stage | | 366 x | | bootstrap | | 367 | | data | | 368 | |-------------->| | 369 | | | | 370 | | 7. stage bootstrap | 371 | | info (optional) | 372 | |------------------------------>| 373 8. power on | | | | 374 -------------->| | | | 375 | 9. get networking settings and| | 376 | staged bootstrap info (if any) | 377 |---------------------------------------------->| 378 | | | | 379 | | | x 380 | 10. update boot-image, if | 381 | needed, and install | 382 | config, if valid | 383 |------------------------------>| 384 | | | 385 | | x 386 | 11. netconf | 387 | call-home | 388 |+------------->| 389 | | 390 v v 392 These interactions are described below. 394 1. An organization, upon deciding to deploy a Vendor's devices for 395 NETCONF ZeroTouch, would import into its NMS the IDevID trust 396 anchor certificate from the Vendor. This certificate is later 397 used by the NMS to authenticate device identities during NETCONF 398 call home connections. 400 2. An organization needs to sign up to a Vendor-provided ZeroTouch 401 program. This program entails the Vendor providing a signed 402 Owner certificate to the organization (depicted here), as well 403 as a commitment to sign Ownership Vouchers for future device 404 orders (interaction #5). 406 3. Subsequently, the organization may place orders to the Vendor 407 for devices supporting ZeroTouch. The ordering process may 408 entail an explicit request for ZeroTouch support, as the Vendor 409 providing the files in step #5 may not be enabled by default. 411 4. The Vendor ships the devices to the various addresses specified 412 in the device order. For example, to an organization's 413 inventory warehouse, where the devices are stored in batches to 414 supply internal requests. In another example, the devices may 415 be shipped to their final deployment destinations. 417 5. In order to support ZeroTouch, the Vendor sends to the 418 organization information about the devices it shipped. This 419 information may be sent to the organization via email or a 420 portal site. The information includes the serial-number and/or 421 IDevID certificate, for each device, as well as one more 422 Ownership Vouchers, assigning ownership for the devices to the 423 organization. 425 6. In anticipation for the devices performing the ZeroTouch 426 process, the NMS configures the Bootstrap Server. This This 427 configuration includes everything a device needs to securely 428 connect to the NMS. 430 7. For deployments where the DHCP server can be customized, the NMS 431 may configure the DHCP server to provide the device a list of 432 additional Bootstrap Servers to consider, in addition to those 433 the device knows of by default. This customization can be 434 configured at a global level in the DHCP server, as it is not 435 dependent on the type of device in any way. 437 8. At some point, the device powers on and, when having its factory 438 default configuration, initiates the ZeroTouch process. 440 9. The device obtains from the DHCP server a dynamic network 441 assignment. The device may also at this time discover a list of 442 additional bootstrap servers, as optionally configured by the 443 NMS in step #7. 445 10. The device iterates over its list of Bootstrap Servers, until it 446 can successfully bootstrap its initial configuration. If it is 447 unable to bootstrap an initial configuration, the device boots 448 as normal. If the staged information directs the device to load 449 a new image, it does so and reboots. If the device reboots, it 450 continues to have a factory default configuration state, which 451 then bring it back to this state, when it would then have the 452 correct image. The device then loads the staged configuration 453 into its running datastore, after validating that the 454 configuration was signed by its rightful owner, as designated by 455 the Ownership Voucher. 457 11. Assuming the bootstrapping information configures the device 458 appropriately, the device will initiate a NETCONF Call Home 459 [draft-ietf-netconf-call-home] connection to the NMS, which then 460 takes over the on-going management of the device. 462 3. Bootstrap Server 464 A Bootstrap Server MUST implement the southbound interface defined 465 below. In order to support the southbound interface, the Bootstrap 466 Server will also need to have a northbound interface, which is 467 described in general terms below. 469 3.1. Northbound Interface 471 The Bootstrap Server will need to provide a northbound interface of 472 some sort to enable configuration of the bootstrapping information 473 for the devices. Defining this interface is out of scope for this 474 document, but it northbound interface is generally expected to: 476 o Enable listing, creation, modification, and deletion of entries 478 o Enable determining a device's current bootstrapping state 480 o Enable alerting external systems when a device sends notifications 482 3.2. Southbound Interface 484 The Bootstrap Server's southbound interface is a REST API that is 485 described by the YANG [RFC6020] module defined in this section and 486 presented using RESTCONF [draft-ietf-netconf-restconf]. Example 487 usage of this API is provided in Appendix A.2. 489 A tree digram describing the Bootstrap Server's southbound interface 490 follows: 492 module: ietf-zerotouch-bootstrap-server 493 +--ro devices 494 +--ro device* [unique-id] 495 +--ro unique-id string 496 +--ro ownership-voucher 497 | +--ro voucher binary 498 | +--ro issuer-crl? string 499 +--ro owner-certificate 500 | +--ro certificate string 501 | +--ro issuer-crl? string 502 +--ro boot-image! 503 | +--ro name string 504 | +--ro md5 string 505 | +--ro sha1 string 506 | +--ro path string 507 | +--ro signature string 508 +--ro configuration 509 +--ro config 510 +--ro signature string 511 rpcs: 512 +---x notification 513 +---w input 514 +---w unique-id string 515 +---w type enumeration 516 +---w message? string 517 +---w ssh-host-keys! 518 +---w ssh-host-key* 519 +---w format enumeration 520 +---w key-data string 522 In the above diagram, notice that the entire data model is read-only, 523 as devices can only pull data from the Bootstrap Server. The data 524 model also defines a single RPC, which is used by the device to 525 provide asynchronous notifications. 527 The Bootstrap Server's southbound interface is normatively defined by 528 the following YANG module: 530 file "ietf-zerotouch-bootstrap-server@2015-07-06.yang" 532 module ietf-zerotouch-bootstrap-server { 534 namespace 535 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 536 prefix "ztbs"; 537 organization 538 "IETF NETCONF (Network Configuration) Working Group"; 540 contact 541 "WG Web: 542 WG List: 543 WG Chair: Mehmet Ersue 544 545 WG Chair: Mahesh Jethanandani 546 547 Editor: Kent Watsen 548 "; 550 description 551 "This module defines the southbound interface for ZeroTouch 552 Bootstrap Servers. 554 Copyright (c) 2014 IETF Trust and the persons identified as 555 authors of the code. All rights reserved. 557 Redistribution and use in source and binary forms, with or 558 without modification, is permitted pursuant to, and subject 559 to the license terms contained in, the Simplified BSD 560 License set forth in Section 4.c of the IETF Trust's 561 Legal Provisions Relating to IETF Documents 562 (http://trustee.ietf.org/license-info). 564 This version of this YANG module is part of RFC XXXX; see 565 the RFC itself for full legal notices."; 567 revision "2015-07-06" { 568 description 569 "Initial version"; 570 reference 571 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 572 } 574 // top-level container 575 container devices { 576 config false; 577 description 578 "A list of device entries"; 579 list device { 580 key unique-id; 581 leaf unique-id { 582 type string; 584 } 586 container ownership-voucher { 587 // presence? 588 description 589 "This container contains the Ownership Voucher that the 590 device uses to ascertain the identity of its rightful 591 owner, as certified by its Vendor."; 592 leaf voucher { 593 type binary; 594 mandatory true; 595 description 596 "A Vendor-specific encoding binding unique device 597 identifiers to an owner identifier value matching the 598 value encoded in the owner-certificate below. An 599 example format for a voucher is presented in the 600 Appendix of RFC XXXX."; 601 } 602 leaf issuer-crl { 603 type string; 604 description 605 "An absolute path to a CRL for the issuer used by the 606 Vendor to sign Ownership Vouchers. The CRL should be 607 as up to date as possible. This leaf is optional as 608 it is primarily to support deployments where the device 609 is unable to download the CRL from the CRL distribution 610 point URLs listed in the Vendor's trust anchor 611 certificate."; 612 } 613 } 615 container owner-certificate { 616 // presense? 617 description 618 "It is intended that the device will fetch this container 619 as a whole, as it contains values that need to be 620 processed together."; 621 leaf certificate { 622 type string; 623 mandatory true; 624 description 625 "This is an X.509 certificate, signed by a Vendor, for 626 a business organization. This certificate must encode a 627 Vendor-assigned value identifying the organization. This 628 identifier must match the owner identifier encoded in 629 the Ownership Voucher."; 630 } 631 leaf issuer-crl { 632 type string; 633 description 634 "An absolute path to a CRL for the issuer used by the 635 Vendor to sign Owner Certificates. The CRL should be 636 as up to date as possible. This leaf is optional as 637 it is primarily to support deployments where the device 638 is unable to download the CRL from the CRL distribution 639 point URLs listed in the Vendor's trust anchor 640 certificate."; 641 } 642 } 644 container boot-image { 645 presence 646 "Only present when boot image information has been configured"; 647 description 648 "It is intended that the device will fetch this container 649 as a whole, as it contains values that need to be 650 processed together."; 651 leaf name { 652 type string; 653 mandatory true; 654 description 655 "The name of the image of software the device is expected 656 to be running."; 657 } 658 leaf md5 { 659 type string; 660 mandatory true; 661 description 662 "The output of the MD5 hash algorithm over the image file."; 663 } 664 leaf sha1 { 665 type string; 666 mandatory true; 667 description 668 "The output of the SHA-1 hash algorithm over the image file."; 669 } 670 leaf path { 671 type string; 672 mandatory true; 673 description 674 "An absolute path to the boot-image file hosted on this 675 Bootstrap server."; 676 } 677 leaf signature { 678 type string; 679 mandatory true; 680 description 681 "The signature over the concatenation of the previous leafs 682 using the organization's private key. Specifically, 683 sign(name+md5+sha1+path), where simple string concatenation 684 to join values is used, resulting in a single null-terminated 685 string."; 686 } 687 } 689 container configuration { 690 description 691 "It is intended that the device will fetch this container 692 as a whole, as its contents need to be processed together."; 693 anyxml config { 694 mandatory true; 695 description 696 "Any configuration data model known to the device. It may 697 contain Vendor-specific and/or standards-based data models. 698 An example configuration using a couple IETF-defined data 699 models is presented the Appendix of RFC XXXX."; 700 } 701 leaf signature { 702 type string; 703 mandatory true; 704 description 705 "The signature over the concatenation of the previous leaf 706 using the organization's private key. Specifically, 707 sign(config), where 'config' is treated as a single null- 708 terminated string."; 709 } 710 } 711 /* 712 action notification { 713 input { 714 leaf type { 715 type enumeration { 716 enum boot-image-missing { 717 description 718 "Indicates that the device got an error when trying to 719 access the provided URL"; 720 } 721 enum boot-image-invalid { 722 description 723 "Indicates that the device had a problem processing the 724 boot-image file (corruption)"; 725 } 726 enum image-name-mismatch { 727 description 728 "Indicates that the processed boot-image contains a name 729 other than provided"; 730 } 731 enum voucher-invalid { 732 description 733 "Indicates that the device had a problem processing the 734 voucher (chain verification failed, revoked crl)"; 735 } 736 enum owner-cert-invalid { 737 description 738 "Indicates that the device had a problem processing the 739 voucher (chain verification failed, revoked crl)"; 740 } 741 enum owner-id-mismatch { 742 description 743 "Indicates that the owner-id in the voucher does not 744 match the one inside the owner-cert"; 745 } 746 enum signature-invalid { 747 description 748 "Indicates that the signature could not be verified 749 using the owner-cert"; 750 } 751 enum bootstrap-complete { 752 description 753 "Indicates that the device successfully processed the 754 bootstrap data. At this point, the device is running 755 the required boot-image and configuration. A device 756 is expected to only send this notification once, 757 assuming it does not receive an error in the HTTP 758 response from the Bootstrap Server."; 759 } 760 } 761 mandatory true; 762 } 763 leaf message { 764 type string; 765 description 766 "A human-readable value."; 767 } 768 container ssh-host-keys { 769 presence "Only present for bootstrap-complete messages."; 770 list ssh-host-key { 771 leaf format { 772 type enumeration { 773 enum ssh-dss; 774 enum ssh-rsa; 775 } 776 mandatory true; 777 } 778 leaf key-data { 779 type string; 780 mandatory true; 781 } 782 } 783 } 784 } 785 } // end action 786 */ 787 } 788 } 790 rpc notification { 791 input { 792 leaf unique-id { 793 type string; 794 mandatory true; 795 } 796 leaf type { 797 type enumeration { 798 enum boot-image-missing { 799 description 800 "Indicates that the device got an error when trying to 801 access the provided URL"; 802 } 803 enum boot-image-invalid { 804 description 805 "Indicates that the device had a problem processing the 806 boot-image file (corruption)"; 807 } 808 enum image-name-mismatch { 809 description 810 "Indicates that the processed boot-image contains a name 811 other than provided"; 812 } 813 enum voucher-invalid { 814 description 815 "Indicates that the device had a problem processing the 816 voucher (chain verification failed, revoked crl)"; 817 } 818 enum owner-cert-invalid { 819 description 820 "Indicates that the device had a problem processing the 821 voucher (chain verification failed, revoked crl)"; 822 } 823 enum owner-id-mismatch { 824 description 825 "Indicates that the owner-id in the voucher does not 826 match the one inside the owner-cert"; 827 } 828 enum signature-invalid { 829 description 830 "Indicates that the signature could not be verified 831 using the owner-cert"; 832 } 833 enum bootstrap-complete { 834 description 835 "Indicates that the device successfully processed the 836 bootstrap data. At this point, the device is running 837 the required boot-image and configuration. A device 838 is expected to only send this notification once, 839 assuming it does not receive an error in the HTTP 840 response from the Bootstrap Server."; 841 } 842 } 843 mandatory true; 844 } 845 leaf message { 846 type string; 847 description 848 "A human-readable value that might provide useful information"; 849 } 850 container ssh-host-keys { 851 presence "Only present for bootstrap-complete messages."; 852 list ssh-host-key { 853 leaf format { 854 type enumeration { 855 enum ssh-dss; 856 enum ssh-rsa; 857 } 858 mandatory true; 859 } 860 leaf key-data { 861 type string; 862 mandatory true; 863 } 864 } 865 } 866 } 867 } // end rpc notification 869 } 871 872 4. Device 874 Devices supporting ZeroTouch MUST have the preconfigured factory 875 default state and bootstrapping logic described in the following 876 sections. 878 4.1. Factory Default State 880 +------------------------------------------------------------------+ 881 | | 882 | | 883 | +----------------------------------------------------------+ | 884 | | | | 885 | | | | 886 | | 1. list of public Internet Bootstrap Servers | | 887 | | 2. list of trust anchor certs for Bootstrap Servers | | 888 | | 3. trust anchor cert for owner certificates | | 889 | | 4. trust anchor cert for device ownership vouchers | | 890 | | 5. IDevID cert & associated intermediate certificate(s) | | 891 | +----------------------------------------------------------+ | 892 | | 893 | +----------------------+ | 894 | | | | 895 | | | | 896 | | 6. private key | | 897 | +----------------------+ | 898 | | 899 +------------------------------------------------------------------+ 901 1. Devices MUST be manufactured with a list of default Bootstrap 902 Servers. Each Bootstrap Server may be identified via a hostname 903 or an IP address. This may be an empty list if for some reason 904 the Vendor prefers to force its devices to have to discover 905 Bootstrap Servers from a DHCP server. 907 2. Devices MUST be manufactured with a list of trust anchor 908 certificates that can be used to authenticate Bootstrap Server 909 connections with. To support Bootstrap Servers discovered from a 910 DHCP server, these certificates SHOULD include public certificate 911 authorities, such as those that are included in a web browser. 913 3. Devices MUST be manufactured with the trust anchor certificate 914 for Owner certificates that the Vendors provide to business 915 organizations when they enroll in the Vendor's ZeroTouch program. 916 This trust anchor certificate is later used by the device to 917 validate the Owner certificate it downloads from the Bootstrap 918 Server. 920 4. Devices MUST be manufactured with the trust anchor certificate 921 for the device ownership vouchers that the Vendors provide to 922 organizations when it ships out an order of ZeroTouch devices. 923 This trust anchor certificate is later used by the device to 924 validate the Ownership Vouchers it downloads from the Bootstrap 925 Server. 927 5. Devices MUST be manufactured with an initial device identifier 928 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 929 X.509 certificate, encoding a globally unique device identifier 930 (e.g., serial number). The device MUST also possess any 931 intermediate certificates between the IDevID certificate and the 932 Vendor's IDevID trust anchor certificate. These certificates are 933 later used by the device to identify itself when it calls home. 934 In particular, these certificates are to be used by the device's 935 NETCONF server, either as its SSH host-key or its TLS server 936 certificate. Please see NETCONF Call Home 937 [draft-ietf-netconf-call-home] for more information. 939 6. Device MUST be manufactured with a private key that corresponds 940 to the public key encoded in its IDevID certificate. This 941 private key SHOULD be securely stored, ideally by a cryptographic 942 processor (e.g., a TPM). 944 4.2. Boot Sequence 946 Power On 947 | 948 v No 949 1. Running default config? --------> Boot normally 950 | 951 | Yes 952 v No 953 2. Able to reach DHCP server? --------> Boot normally 954 | 955 | Yes 956 v 957 3. Prepend any additional Bootstrap Servers discovered 958 | 959 v No 960 4. Able to bootstrap off any Bootstrap Server? -------> Boot normally 961 (see next diagram for drill-down details) 962 | 963 | Yes 964 v 965 5. Run with new configuration 967 These interactions are described next. 969 1. When the device powers on, it first checks to see if it is 970 running the factory default configuration. If it is running a 971 modified configuration, then it boots normally. 973 2. The device tries to obtain a dynamic network assignment from a 974 DHCP server. If it is unable to reach a DHCP server, it boots 975 normally. 977 3. If the DHCP server's offer includes the ZeroTouch Information 978 DHCP option defined in Section 7.1, the device prepends the 979 specified Bootstrap Servers to its factory default list. 981 4. The device iterates over its list of Bootstrap Servers, as 982 described in the next section. If it is unable to bootstrap 983 itself off any of the servers, it boots normally. 985 5. If the device was able to bootstrap itself off any of the 986 Bootstrap Servers, it runs with the new configuration merged into 987 its running datastore. 989 Following are the actions performed by the device when bootstrap off 990 a Bootstrap Server (step #4 the in previous diagram). 992 Connect to port 443 993 | 994 v No 995 1. Able to validate server certificate? ------> Exit 996 | 997 | Yes 998 v No 999 2. Able to validate ownership voucher? ------> Post notification and exit 1000 | 1001 | Yes 1002 v No 1003 3. Able to validate owner certificate? ------> Post notification and exit 1004 | 1005 | Yes 1006 v No 1007 4. Able to validate boot image info? ------> Post notification and exit 1008 | 1009 | Yes 1010 v No 1011 5. Need to install boot image? ------> Install and reboot 1012 | 1013 | Yes 1014 v No 1015 6. Able to validate configuration? ------> Post notification and exit 1016 | 1017 | Yes 1018 v 1019 7. Merge configuration into running datastore 1020 | 1021 v 1022 8. Post bootstrap complete notification and exit 1024 These interactions are described next. 1026 1. As part of the HTTPS connection, the device will need to 1027 authenticate the server certificate presented by the Bootstrap 1028 Server. The device authenticates the server certificate using 1029 path-validation to one of its preconfigured Bootstrap Server 1030 trust anchors. If the device is unable to authenticate the 1031 server's certificate, it abandons this Bootstrap Server and 1032 exits. 1034 2. The device downloads the ownership voucher from the Bootstrap 1035 Server. The device validates the voucher is signed by its 1036 Vendor, using its preconfigured trust anchor for device ownership 1037 vouchers. The device also validates that its unique identifier 1038 is listed by the voucher. If the device is unable to validate 1039 the voucher or can not find its unique identifier listed, it 1040 posts a notification message to that effect and abandons this 1041 Bootstrap Server. 1043 3. The device downloads the owner certificate from the Bootstrap 1044 Server. The device validates that this certificate is signed by 1045 its Vendor, using path-validation to its preconfigured trust 1046 anchor for owner certificates. The device also validates that 1047 the organization identifier is the same as listed in the 1048 ownership voucher, validated in step #2. If the device is unable 1049 to validate the certificate or the owner identifier does not 1050 match, it posts a notification message to that effect and 1051 abandons this Bootstrap Server. 1053 4. The device tries to download the boot image information. If no 1054 boot image information is available, it skips the remainder of 1055 this step. Otherwise, the device validates the boot image 1056 information using the public key from the owner certificate 1057 obtained in step #3. If it is unable to authenticate the boot 1058 image information, it posts a notification message to that effect 1059 and abandons this Bootstrap Server. 1061 5. The device checks if the specified boot-image name matches what 1062 the device is currently running. If there is a mismatch, device 1063 downloads the new image from the Bootstrap Server and installs 1064 it. It is expected that the device will reboot itself in order 1065 to activate the new image and, further, that doing so preserves 1066 its factory default state such that it will return to this same 1067 check again, but then running the correct image. If the device 1068 is unable to install the boot-image, it posts a notification 1069 message to that effect and abandons this Bootstrap Server. 1071 6. The device downloads the configuration from the Bootstrap Server 1072 and validates the configuration using the public key from the 1073 owner certificate obtained in step #3. If it is unable to 1074 authenticate the configuration, it posts a notification message 1075 to that effect and abandons this Bootstrap Server. 1077 7. The device merges the configuration into its running datastore. 1078 It is expected that this configuration will provide the 1079 information necessary for the device to establish a secure 1080 NETCONF connection to its NMS using NETCONF Call Home 1081 ([draft-ietf-netconf-call-home]). 1083 8. The device posts a bootstrap completion notification message to 1084 the Bootstrap Server and exits. 1086 5. Network Management System (NMS) 1088 5.1. Overview 1090 It is expected that the bootstrapping configuration will guide the 1091 device to initiate a secure NETCONF connection to the NMS using 1092 NETCONF Call Home [draft-ietf-netconf-call-home]. This section 1093 describes what the NMS needs to do to ensure security for the 1094 device's connection. 1096 5.2. Precondition 1098 +-----------------------------------------------------------------+ 1099 | | 1100 | | 1101 | +-----------------------------------------------------+ | 1102 | | | | 1103 | | | | 1104 | | 1. list of IDevID trust anchor certificates | | 1105 | +-----------------------------------------------------+ | 1106 | | 1107 | +-----------------------------------------------------+ | 1108 | | | | 1109 | | | | 1110 | | 2. list of expected device unique identifiers | | 1111 | +-----------------------------------------------------+ | 1112 | | 1113 | +-----------------------------------------------------+ | 1114 | | | | 1115 | | | | 1116 | | 3. map of device identifiers to login credentials | | 1117 | +-----------------------------------------------------+ | 1118 | | 1119 +-----------------------------------------------------------------+ 1121 1. In order to authenticate a device, the NMS MUST possess the 1122 IDevID trust anchor provided by its Vendor to enable verification 1123 of the device's IDevID certificate. Specifically, the NMS uses 1124 this certificate to validate the identity certificate a device 1125 presents when negotiating the SSH or TLS transport for the 1126 NETCONF Call Home connection [draft-ietf-netconf-call-home]. 1127 Because an NMS may interoperate with multiple vendors, and a 1128 vendor may have more than one trust anchor for signing its 1129 devices IDevID certificates, this generalizes into the NMS 1130 needing a list of trust anchor certificates. These certificates 1131 SHOULD be stored in a way that prevents tampering, which is why 1132 they are shown in read-only storage in the diagram. 1134 2. In order for the NMS to validate that a specific device 1135 connecting to it is legitimate, it MUST have a list of expected 1136 unique device identifiers (e.g., serial-numbers). The unique 1137 identifier encoded into the device's IDevID certificate MUST 1138 match one of the expected identifiers in order for a device to be 1139 considered legitimate. 1141 3. The NMS must have login credentials for each device. These 1142 credentials may be, for instance, a private key used for SSH or 1143 TLS client authentication. It is expected that a device is able 1144 to authenticate the NMS's credentials by virtue of the 1145 configuration it downloads from the Bootstrap Server. These 1146 private-keys SHOULD be stored securely, such that they can not be 1147 easily compromised. 1149 5.3. Connection Handling 1151 When receiving a NETCONF call home connection from a device, the NSM 1152 completes the connection as specified NETCONF Call Home 1153 [draft-ietf-netconf-call-home]. 1155 6. Security Considerations 1157 6.1. Entropy loss over time 1159 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 1160 IDevID certificate should never expire (i.e. having a notAfter 1161 99991231235959Z). Given the long-lived nature of these certificates, 1162 it is paramount to use a strong key length (e.g., 512-bit ECC). 1163 Vendors SHOULD deploy Online Certificate State Protocol (OCSP) 1164 responders or CRL Distribution Points (CDP) to revoke certificates in 1165 case necessary. 1167 6.2. Serial Numbers 1169 This draft suggests using the device's serial number as the unique 1170 identifier in its IDevID certificate. This is because serial numbers 1171 are ubiquitous and prominently contained in invoices and on labels 1172 affixed to devices and their packaging. That said, serial numbers 1173 many times encode revealing information, such as the device's model 1174 number, manufacture date, and/or sequence number. Knowledge of this 1175 information may provide an adversary with details needed to launch an 1176 attack. 1178 7. IANA Considerations 1180 7.1. ZeroTouch Information DHCP Options 1182 The following registrations are in accordance to RFC 2939 for "BOOTP 1183 Vendor Extensions and DHCP Options" registry maintained at 1184 http://www.iana.org/assignments/bootp-dhcp-parameters. 1186 7.1.1. DHCP v4 Option 1188 Tag: XXX 1190 Name: Zero Touch Information 1192 Description: Returns a list of null-terminated Configuration 1193 Server hostnames and/or IP addresses. 1195 Code Len 1196 +-----+-----+------+------+---- 1197 | XXX | n | svr1 | svr2 | ... 1198 +-----+-----+------+------+---- 1200 Reference: RFC XXXX 1202 7.1.2. DHCP v6 Option 1204 Tag: YYY 1206 Name: Zero Touch Information 1208 Description: Returns a list of null-terminated Configuration 1209 Server hostnames and/or IP addresses. 1211 Code Len 1212 +-----+-----+------+------+---- 1213 | YYY | n | svr1 | svr2 | ... 1214 +-----+-----+------+------+---- 1216 Reference: RFC XXXX 1218 8. Acknowledgements 1220 The authors would like to thank for following for lively discussions 1221 on list and in the halls (ordered by last name): David Harrington, 1222 Dean Bogdanovic, Martin Bjorklund, Stephen Hanna, Wes Hardaker, Russ 1223 Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder. 1225 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 1226 brainstorming the original I-D's solution during the IETF 87 meeting 1227 in Berlin. 1229 9. References 1231 9.1. Normative References 1233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1234 Requirement Levels", BCP 14, RFC 2119, March 1997. 1236 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1237 Network Configuration Protocol (NETCONF)", RFC 6020, 1238 October 2010. 1240 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 1241 Shell Authentication", RFC 6187, March 2011. 1243 [Std-802.1AR-2009] 1244 IEEE SA-Standards Board, "IEEE Standard for Local and 1245 metropolitan area networks - Secure Device Identity", 1246 December 2009, . 1249 [draft-ietf-netconf-call-home] 1250 Watsen, K., "NETCONF Call Home (work in progress)", 1251 October 2014, . 1254 [draft-ietf-netconf-restconf] 1255 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1256 Protocol", draft-ieft-netconf-restconf-04 (work in 1257 progress), 2014, . 1260 [draft-ietf-netconf-server-model] 1261 Watsen, K., "NETCONF Server Model (work in progress)", 1262 September 2014, . 1265 9.2. Informative References 1267 [draft-pritikin-anima-bootstrapping-keyinfra] 1268 Pritikin, M., Behringer, M., and S. Bjarnason, 1269 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 1270 bootstrapping-keyinfra-01 (work in progress), 2015, 1271 . 1274 Appendix A. Examples 1276 A.1. Ownership Voucher 1278 Following describes an example data-model for an Ownership Voucher. 1279 Real vouchers are expected to be encoded in a Vendor-specific format 1280 outside the of scope for this draft. 1282 A tree digram describing an Ownership Voucher: 1284 module: ietf-zerotouch-ownership-voucher 1285 +--rw voucher 1286 +--rw unique-id* string 1287 +--rw owner-id string 1288 +--rw created-on yang:date-and-time 1289 +--rw expires-on? yang:date-and-time 1290 +--rw signature string 1292 The YANG module for this example voucher: 1294 file "ietf-zerotouch-ownership-voucher@2015-07-06.yang" 1296 module ietf-zerotouch-ownership-voucher { 1298 namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher"; 1299 prefix "ztov"; 1301 import ietf-yang-types { prefix yang; } 1303 organization 1304 "IETF NETCONF (Network Configuration) Working Group"; 1306 contact 1307 "WG Web: 1308 WG List: 1309 WG Chair: Mehmet Ersue 1310 1311 WG Chair: Mahesh Jethanandani 1312 1313 Editor: Kent Watsen 1314 "; 1316 description 1317 "This module defines the format for a ZeroTouch ownership voucher, 1318 which is produced by Vendors, relayed by Bootstrap Servers, and 1319 consumed by devices. The purpose of the voucher is to enable a 1320 device to ascertain the identity of its rightful owner, as 1321 certified by its Vendor. 1323 Copyright (c) 2014 IETF Trust and the persons identified as 1324 authors of the code. All rights reserved. 1326 Redistribution and use in source and binary forms, with or 1327 without modification, is permitted pursuant to, and subject 1328 to the license terms contained in, the Simplified BSD 1329 License set forth in Section 4.c of the IETF Trust's 1330 Legal Provisions Relating to IETF Documents 1331 (http://trustee.ietf.org/license-info). 1333 This version of this YANG module is part of RFC XXXX; see 1334 the RFC itself for full legal notices."; 1336 revision "2015-07-06" { 1337 description 1338 "Initial version"; 1339 reference 1340 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 1341 } 1343 // top-level container 1344 container voucher { 1345 leaf-list unique-id { 1346 type string; 1347 min-elements 1; 1348 description 1349 "The unique identifier (e.g., serial-number) for a device. 1350 The value must match the value in the device's IDevID 1351 certificate. A device uses this value to determine if 1352 the voucher applies to it."; 1353 } 1354 leaf owner-id { 1355 type string; 1356 mandatory true; 1357 description 1358 "A Vendor-assigned value for the rightful owner of the 1359 devices enumerated by this voucher. The owner-id value 1360 must match the value in the owner-certificate below"; 1361 } 1362 leaf created-on { 1363 type yang:date-and-time; 1364 mandatory true; 1365 description 1366 "The date this voucher was created"; 1367 } 1368 leaf expires-on { 1369 type yang:date-and-time; 1370 description 1371 "The date this voucher expires, if any"; 1372 } 1373 leaf signature { 1374 type string; 1375 mandatory true; 1376 description 1377 "The signature over the concatenation of all the previous 1378 values"; 1379 } 1380 } 1381 } 1383 1385 A.2. Bootstrap Server's API 1387 ['\' line wrapping added for formatting only] 1389 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1390 devices/device=123456/ownership-voucher 1392 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1393 devices/device=123456/owner-certificate 1395 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1396 devices/device=123456/boot-image 1398 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1399 devices/device=123456/configuration 1401 POST https://example.com/restconf/operations/ietf-zerotouch-bootstrap-\ 1402 server:notification 1404 A.3. Bootstrap Configuration 1406 This example illustrates a configuration enabling secure NETCONF 1407 call-home using standards-based YANG modules. 1409 1410 1412 1413 1414 1415 1416 admin 1417 1418 admin's rsa ssh host-key 1419 ssh-rsa 1420 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1421 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1422 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1423 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1424 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1425 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1426 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1427 1428 1429 1430 1432 1433 1434 1435 1436 config-mgr 1437 1438 1439 1440 east-data-center 1441
11.22.33.44
1442 1443 1444 west-data-center 1445
55.66.77.88
1446 1447 1448 1449 my-call-home-x509-key 1450 1451 1452 1453 1454 1456 1457 Appendix B. Change Log 1459 B.1. ID to 00 1461 o Major structural update; the essence is the same. Most every 1462 section was rewritten to some degree. 1464 o Added a Use Cases section 1466 o Added diagrams for "Actors and Roles" and "NMS Precondition" 1467 sections, and greatly improved the "Device Boot Sequence" diagram 1469 o Removed support for physical presence or any ability for 1470 Configlets to not be signed. 1472 o Defined the ZeroTouch Information DHCP option 1474 o Added an ability for devices to also download images from 1475 Configuration Servers 1477 o Added an ability for Configlets to be encrypted 1479 o Now Configuration Servers only have to support HTTP/S - no other 1480 schemes possible 1482 B.2. 00 to 01 1484 o Added boot-image and validate-owner annotations to the "Actors and 1485 Roles" diagram. 1487 o Fixed 2nd paragraph in section 7.1 to reflect current use of 1488 anyxml. 1490 o Added encrypted and signed-encrypted examples 1492 o Replaced YANG module with XSD schema 1494 o Added IANA request for the ZeroTouch Information DHCP Option 1496 o Added IANA request for media types for boot-image and 1497 configuration 1499 B.3. 01 to 02 1501 o Replaced the need for a Configuration Signer with the ability for 1502 each NMS to be able to sign its own configurations, using Vendor 1503 signed Ownership Vouchers and Owner certificates. 1505 o Renamed Configuration Server to Bootstrap Server, a more 1506 representative name given the information devices download from 1507 it. 1509 o Replaced the concept of a Configlet by defining a southbound 1510 interface for the Bootstrap Server using YANG. 1512 o Removed the IANA request for the boot-image and configuration 1513 media types 1515 B.4. 02 to 03 1517 o Minor update, mostly just to add an Editor's Note to show how this 1518 draft might integrate with the draft-pritikin-anima-bootstrapping- 1519 keyinfra. 1521 Authors' Addresses 1523 Kent Watsen 1524 Juniper Networks 1526 EMail: kwatsen@juniper.net 1528 Joe Clarke 1529 Cisco Systems 1531 EMail: jclarke@cisco.com 1533 Mikael Abrahamsson 1534 T-Systems 1536 EMail: "mikael.abrahamsson@t-systems.se