idnits 2.17.1 draft-ietf-netconf-zerotouch-02.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 7 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 455 has weird spacing: '...ificate str...' == Line 460 has weird spacing: '...gnature str...' == Line 463 has weird spacing: '...gnature str...' == Line 467 has weird spacing: '...ique-id str...' == Line 1117 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 (March 9, 2015) is 3328 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 1078, 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: September 10, 2015 Cisco Systems 6 M. Abrahamsson 7 T-Systems 8 March 9, 2015 10 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) 11 draft-ietf-netconf-zerotouch-02 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 September 10, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 58 2. High-level Design . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Interactions . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Bootstrap Server . . . . . . . . . . . . . . . . . . . . . . 10 62 3.1. Northbound Interface . . . . . . . . . . . . . . . . . . 10 63 3.2. Southbound Interface . . . . . . . . . . . . . . . . . . 10 64 4. Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 4.1. Factory Default State . . . . . . . . . . . . . . . . . . 16 66 4.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 18 67 5. Network Management System (NMS) . . . . . . . . . . . . . . . 22 68 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 69 5.2. Precondition . . . . . . . . . . . . . . . . . . . . . . 22 70 5.3. Connection Handling . . . . . . . . . . . . . . . . . . . 23 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 72 6.1. Entropy loss over time . . . . . . . . . . . . . . . . . 23 73 6.2. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 23 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 75 7.1. ZeroTouch Information DHCP Options . . . . . . . . . . . 24 76 7.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 24 77 7.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 24 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 81 A.1. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 26 82 A.2. Bootstrap Server's API . . . . . . . . . . . . . . . . . 28 83 A.3. Bootstrap Configuration . . . . . . . . . . . . . . . . . 28 84 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 85 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 30 86 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 30 87 B.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 30 89 1. Introduction 91 A fundamental business requirement is to reduce costs where possible. 92 For network operators, deploying devices to many locations can be a 93 significant cost, as sending trained specialists to each site to do 94 installations is both cost prohibitive and does not scale. 96 The solution presented herein enables a device to securely obtain a 97 bootstrapping configuration from the network without any operator 98 input. Significantly, this configuration may configure the device to 99 securely call home using NETCONF Call Home 100 [draft-ietf-netconf-call-home]. 102 Central to this solution is the device being able to process a set of 103 files locally, without any need to reach out to the network again. 104 As consequence, how the files are obtained is not critical to the 105 security of the solution. The files can be read over any networking 106 layer or medium. By example, the files could be loaded using a USB 107 flash drive physically plugged into a device. 109 The solution presented below focuses on supporting IP networks that 110 may have a DHCP server. Solutions for other deployment scenarios may 111 be defined by drafts in the future. 113 1.1. Use Cases 115 o Connecting to a remotely administered network 117 This use-case involves scenarios, such as a remote branch 118 office or convenience store, whereby the device connects an 119 access gateway device to an ISP's network. In this case, the 120 device receives only generic networking settings provided by 121 the ISP's DHCP server, with no site-specific customizations 122 possible. In such a case, the device has no recourse but to 123 reach out to the public Internet its initial configuration. 125 o Connecting to a locally administered network 127 This use-case covers all other scenarios and differs only in 128 that the device may additionally receive site-specific 129 information from the network, which could direct it to use a 130 local server for its initial configuration. If no site- 131 specific information is provided, or the device is unable to 132 use the information provided, it can then reach out to network 133 just as it would for a remotely administered network. 135 1.2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 139 sections below are to be interpreted as described in RFC 2119 140 [RFC2119]. 142 1.3. Tree Diagrams 144 A simplified graphical representation of the data models is used in 145 this document. The meaning of the symbols in these diagrams is as 146 follows: 148 o Brackets "[" and "]" enclose list keys. 150 o Braces "{" and "}" enclose feature names, and indicate that the 151 named feature must be present for the subtree to be present. 153 o Abbreviations before data node names: "rw" means configuration 154 (read-write) and "ro" state data (read-only). 156 o Symbols after data node names: "?" means an optional node, "!" 157 means a presence container, and "*" denotes a list and leaf-list. 159 o Parentheses enclose choice and case nodes, and case nodes are also 160 marked with a colon (":"). 162 o Ellipsis ("...") stands for contents of subtrees that are not 163 shown. 165 2. High-level Design 167 2.1. Design Overview 169 The following diagram illustrates the overall solution presented in 170 this draft. Note that some of the interactions illustrated below 171 occur at different times, only the numbered interactions (1-3) occur 172 at the time a device is bootstrapping itself. 174 manufactures 175 +----------------------------------+ 176 | | 177 | 1.discover | 178 | bootstrap | 2.fetch bootstrap 179 | information v data and provide 180 | (optional) +------+ confirmation 181 | +---------------|Device|----------------+ 182 | | +------+ | 183 | | | | 184 | v | v 185 +------+ +------+ | +---------+ 186 |Vendor| | DHCP | |3.netconf |Bootstrap| 187 +------+ |Server| | callhome | Server | 188 | ^ +------+ | +---------+ 189 | | ^ | ^ 190 | | | stage | | 191 | | | bootstrap | stage | 192 | | | information v bootstrap | 193 | | | (optional) +-------+ data | 194 | | +---------------| NMS |---------------+ 195 | | +-------+ 196 | | imports trust anchor, | ^ 197 | | signups for owner cert, | | 198 | | and orders devices | | 199 | +-------------------------------+ | 200 +------------------------------------+ 201 ships devices, provides 202 serial-numbers and/or IDevID 203 certs, and ownership vouchers 205 The boxes in this diagram are described next. A sequence diagram 206 explaining the various calls follows in Section 2.2. 208 o Vendor 210 Vendors manufacture the devices supporting NETCONF ZeroTouch. 211 To support this solution, Vendors must support a one-time 212 enrollment process per business organization owning the NMS. 213 Vendors must also support sending additional information to the 214 business organization about the devices that have been shipped 215 for device orders it places. 217 o Device 219 The devices supporting NETCONF ZeroTouch will only attempt the 220 bootstrapping process when booting with its factory default 221 configuration. As illustrated above, the bootstrapping process 222 consists of three interactions: 224 1. When joining the network, the device will attempt to 225 configure IP networking from a DHCP server. If the device 226 is able to reach a DHCP server, it may discover additional 227 bootstrapping information. The additional bootstrapping 228 information consists of one or more additional Bootstrap 229 Servers the device should try to connect to. 231 2. The device sequentially processes its list of Bootstrap 232 Servers, prioritizing any that might have been learned from 233 the DHCP server. Once the device has successfully 234 configured itself using the bootstrapping information, it 235 notifies the bootstrapping server for monitoring purposes. 237 3. Assuming the bootstrapping information configures the 238 device appropriately, the device will initiate a NETCONF 239 Call Home connection [draft-ietf-netconf-call-home]. 241 More information about Devices is in Section 4. 243 o DHCP Server 245 This draft assumes the use of a DHCP server but, in reality, 246 the solution is not intrinsically tied to using a DHCP server. 247 Any mechanism or combination of mechanisms that can provide 248 dynamic networking assignment would equally do. 250 Assuming the use of DHCP, this draft defines a specific DHCP 251 Option for the discovering of addition bootstrapping 252 information. More information about the ZeroTouch DHCP Option 253 is in Section 7.1. 255 o Bootstrap Server 257 Bootstrap Servers host the bootstrapping information staged by 258 NMSs for the devices to find. The Bootstrap Server presents a 259 simple REST interface for devices to obtain both their 260 bootstrapping information as well as notify the Bootstrapping 261 Server when it has successfully completed the bootstrapping 262 process. 264 Bootstrap Servers may be deployed on the public Internet or on 265 a local network. Devices may be preconfigured with a list of 266 well-known Bootstrap Servers. Additional Bootstrap Servers 267 (i.e. not in the device's preconfigured list) must be 268 discovered from a DHCP server. 270 How Bootstrap Servers are deployed is out of scope of this 271 draft, but there are a couple points worth noting. Firstly, it 272 is expected that Internet based Bootstrap Servers will 273 initially be hosted by Vendors, whilst waiting for 3rd-party 274 servers to become available. Secondly, it is expected that 275 locally administrated networks with in-house solutions might 276 bundle the Bootstrap Server into another system (e.g., the 277 NMS), where having the features integrated can streamline 278 various workflows. 280 More information about Bootstrap Servers is in Section 3. 282 o Network Management System 284 The NMS is a term used here loosely to represent any system, or 285 collection of systems, deployed by a business organization to 286 manage its devices. An NMS being able to establish a secure 287 NETCONF connection with devices purchased by its organization 288 is the ultimate goal of this solution presented by this draft. 289 More information about the Network Management System is in 290 Section 5. 292 2.2. Interactions 294 The following diagram illustrates the interactions between the 295 entities described in the previous section. Note that the 296 interactions can be roughly categorized as those that occur before a 297 device powers on and those that occur after a device powers on. 299 +------+ +------+ +---+ +---------+ +------+ 300 |Vendor| |Device| |NMS| |Bootstrap| | DHCP | 301 +------+ +------+ +---+ | Server | |Server| 302 | | | +---------+ +------+ 303 | | | | | 304 | 1. imports trust anchor | | | 305 |<------------------------------| | | 306 | | | | | 307 | 2. signs up for owner cert | | | 308 |<------------------------------| | | 309 | | | | | 310 | 3. orders devices | | | 311 |<------------------------------| | | 312 | | | | | 313 | 4. ships | | | | 314 |-------------->| | | | 315 | | | | | 316 | 5. provides serial-numbers | | | 317 | and/or IDevID cert(s), | | | 318 | and ownership vouchers | | | 319 |------------------------------>| | | 320 | | | 6.stage | | 321 x | | bootstrap | | 322 | | data | | 323 | |-------------->| | 324 | | | | 325 | | 7. stage bootstrap | 326 | | info (optional) | 327 | |------------------------------>| 328 8. power on | | | | 329 -------------->| | | | 330 | 9. get networking settings and| | 331 | staged bootstrap info (if any) | 332 |---------------------------------------------->| 333 | | | | 334 | | | x 335 | 10. update boot-image, if | 336 | needed, and install | 337 | config, if valid | 338 |------------------------------>| 339 | | | 340 | | x 341 | 11. netconf | 342 | call-home | 343 |+------------->| 344 | | 345 v v 347 These interactions are described below. 349 1. An organization, upon deciding to deploy a Vendor's devices for 350 NETCONF ZeroTouch, would import into its NMS the IDevID trust 351 anchor certificate from the Vendor. This certificate is later 352 used by the NMS to authenticate device identities during NETCONF 353 call home connections. 355 2. An organization needs to sign up to a Vendor-provided ZeroTouch 356 program. This program entails the Vendor providing a signed 357 Owner certificate to the organization (depicted here), as well 358 as a commitment to sign Ownership Vouchers for future device 359 orders (interaction #5). 361 3. Subsequently, the organization may place orders to the Vendor 362 for devices supporting ZeroTouch. The ordering process may 363 entail an explicit request for ZeroTouch support, as the Vendor 364 providing the files in step #5 may not be enabled by default. 366 4. The Vendor ships the devices to the various addresses specified 367 in the device order. For example, to an organization's 368 inventory warehouse, where the devices are stored in batches to 369 supply internal requests. In another example, the devices may 370 be shipped to their final deployment destinations. 372 5. In order to support ZeroTouch, the Vendor sends to the 373 organization information about the devices it shipped. This 374 information may be sent to the organization via email or a 375 portal site. The information includes the serial-number and/or 376 IDevID certificate, for each device, as well as one more 377 Ownership Vouchers, assigning ownership for the devices to the 378 organization. 380 6. In anticipation for the devices performing the ZeroTouch 381 process, the NMS configures the Bootstrap Server. This This 382 configuration includes everything a device needs to securely 383 connect to the NMS. 385 7. For deployments where the DHCP server can be customized, the NMS 386 may configure the DHCP server to provide the device a list of 387 additional Bootstrap Servers to consider, in addition to those 388 the device knows of by default. This customization can be 389 configured at a global level in the DHCP server, as it is not 390 dependent on the type of device in any way. 392 8. At some point, the device powers on and, when having its factory 393 default configuration, initiates the ZeroTouch process. 395 9. The device obtains from the DHCP server a dynamic network 396 assignment. The device may also at this time discover a list of 397 additional bootstrap servers, as optionally configured by the 398 NMS in step #7. 400 10. The device iterates over its list of Bootstrap Servers, until it 401 can successfully bootstrap its initial configuration. If it is 402 unable to bootstrap an initial configuration, the device boots 403 as normal. If the staged information directs the device to load 404 a new image, it does so and reboots. If the device reboots, it 405 continues to have a factory default configuration state, which 406 then bring it back to this state, when it would then have the 407 correct image. The device then loads the staged configuration 408 into its running datastore, after validating that the 409 configuration was signed by its rightful owner, as designated by 410 the Ownership Voucher. 412 11. Assuming the bootstrapping information configures the device 413 appropriately, the device will initiate a NETCONF Call Home 414 [draft-ietf-netconf-call-home] connection to the NMS, which then 415 takes over the on-going management of the device. 417 3. Bootstrap Server 419 A Bootstrap Server MUST implement the southbound interface defined 420 below. In order to support the southbound interface, the Bootstrap 421 Server will also need to have a northbound interface, which is 422 described in general terms below. 424 3.1. Northbound Interface 426 The Bootstrap Server will need to provide a northbound interface of 427 some sort to enable configuration of the bootstrapping information 428 for the devices. Defining this interface is out of scope for this 429 document, but it northbound interface is generally expected to: 431 o Enable listing, creation, modification, and deletion of entries 433 o Enable determining a device's current bootstrapping state 435 o Enable alerting external systems when a device sends notifications 437 3.2. Southbound Interface 439 The Bootstrap Server's southbound interface is a REST API that is 440 described by the YANG [RFC6020] module defined in this section and 441 presented using RESTCONF [draft-ietf-netconf-restconf]. Example 442 usage of this API is provided in Appendix A.2. 444 A tree digram describing the Bootstrap Server's southbound interface 445 follows: 447 module: ietf-zerotouch-bootstrap-server 448 +--ro devices 449 +--ro device* [unique-id] 450 +--ro unique-id string 451 +--ro ownership-voucher 452 | +--ro voucher binary 453 | +--ro issuer-crl? string 454 +--ro owner-certificate 455 | +--ro certificate string 456 | +--ro issuer-crl? string 457 +--ro boot-image! 458 | +--ro name string 459 | +--ro path string 460 | +--ro signature string 461 +--ro configuration 462 +--ro config 463 +--ro signature string 464 rpcs: 465 +---x notification 466 +---w input 467 +---w unique-id string 468 +---w type enumeration 469 +---w message? string 471 In the above diagram, notice that the entire data model is read-only, 472 as devices can only pull data from the Bootstrap Server. The data 473 model also defines a single RPC, which is used by the device to 474 provide asynchronous notifications. 476 The Bootstrap Server's southbound interface is normatively defined by 477 the following YANG module: 479 file "ietf-zerotouch-bootstrap-server@2015-03-09.yang" 481 module ietf-zerotouch-bootstrap-server { 483 namespace 484 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 485 prefix "ztbs"; 487 organization 488 "IETF NETCONF (Network Configuration) Working Group"; 490 contact 491 "WG Web: 492 WG List: 493 WG Chair: Mehmet Ersue 494 495 WG Chair: Mahesh Jethanandani 496 497 Editor: Kent Watsen 498 "; 500 description 501 "This module defines the southbound interface for ZeroTouch 502 Bootstrap Servers. 504 Copyright (c) 2014 IETF Trust and the persons identified as 505 authors of the code. All rights reserved. 507 Redistribution and use in source and binary forms, with or 508 without modification, is permitted pursuant to, and subject 509 to the license terms contained in, the Simplified BSD 510 License set forth in Section 4.c of the IETF Trust's 511 Legal Provisions Relating to IETF Documents 512 (http://trustee.ietf.org/license-info). 514 This version of this YANG module is part of RFC XXXX; see 515 the RFC itself for full legal notices."; 517 revision "2015-03-09" { 518 description 519 "Initial version"; 520 reference 521 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 522 } 524 // top-level container 525 container devices { 526 config false; 527 description 528 "A list of device entries"; 529 list device { 530 key unique-id; 531 leaf unique-id { 532 type string; 533 } 535 container ownership-voucher { 536 description 537 "This container contains the Ownership Voucher that the 538 device uses to ascertain the identity of its rightful 539 owner, as certified by its Vendor."; 540 leaf voucher { 541 type binary; 542 mandatory true; 543 description 544 "A Vendor-specific encoding binding unique device 545 identifiers to an owner identifier value matching the 546 value encoded in the owner-certificate below. An 547 example format for a voucher is presented in the 548 Appendix of RFC XXXX."; 549 } 550 leaf issuer-crl { 551 type string; 552 description 553 "An absolute path to a CRL for the issuer used by the 554 Vendor to sign Ownership Vouchers. The CRL should be 555 as up to date as possible. This leaf is optional as 556 it is primarily to support deployments where the device 557 is unable to download the CRL from the CRL distribution 558 point URLs listed in the Vendor's trust anchor 559 certificate."; 560 } 561 } 563 container owner-certificate { 564 description 565 "It is intended that the device will fetch this container 566 as a whole, as it contains values that need to be 567 processed together."; 568 leaf certificate { 569 type string; 570 mandatory true; 571 description 572 "This is an X.509 certificate, signed by a Vendor, for 573 a business organization. This certificate must encode a 574 Vendor-assigned value identifying the organization. This 575 identifier must match the owner identifier encoded in 576 the Ownership Voucher."; 577 } 578 leaf issuer-crl { 579 type string; 580 description 581 "An absolute path to a CRL for the issuer used by the 582 Vendor to sign Owner Certificates. The CRL should be 583 as up to date as possible. This leaf is optional as 584 it is primarily to support deployments where the device 585 is unable to download the CRL from the CRL distribution 586 point URLs listed in the Vendor's trust anchor 587 certificate."; 588 } 589 } 591 container boot-image { 592 presence 593 "Only present when boot image information has been configured"; 594 description 595 "It is intended that the device will fetch this container 596 as a whole, as it contains values that need to be 597 processed together."; 598 leaf name { 599 type string; 600 mandatory true; 601 description 602 "The name of the image of software the device is expected 603 to be running."; 604 } 605 leaf path { 606 type string; 607 mandatory true; 608 description 609 "An absolute path to the boot-image file hosted on this 610 Bootstrap server."; 611 } 612 leaf signature { 613 type string; 614 mandatory true; 615 description 616 "The signature over the concatenation of the previous two 617 leafs using the organization's private key."; 618 } 619 } 621 container configuration { 622 description 623 "It is intended that the device will fetch this container 624 as a whole, as its contents need to be processed together."; 625 anyxml config { 626 mandatory true; 627 description 628 "Any configuration data model known to the device. It may 629 contain Vendor-specific and/or standards-based data models. 630 An example configuration using a couple IETF-defined data 631 models is presented the Appendix of RFC XXXX."; 632 } 633 leaf signature { 634 type string; 635 mandatory true; 636 description 637 "The signature over the config leaf using the 638 organization's private key."; 639 } 640 } 642 } 643 } 645 rpc notification { 646 input { 647 leaf unique-id { 648 type string; 649 mandatory true; 650 } 651 leaf type { 652 type enumeration { 653 enum boot-image-missing { 654 description 655 "Indicates that the device got an error when trying to 656 access the provided URL"; 657 } 658 enum boot-image-invalid { 659 description 660 "Indicates that the device had a problem processing the 661 boot-image file (corruption)"; 662 } 663 enum image-name-mismatch { 664 description 665 "Indicates that the processed boot-image contains a name 666 other than provided"; 667 } 668 enum voucher-invalid { 669 description 670 "Indicates that the device had a problem processing the 671 voucher (chain verification failed, revoked crl)"; 672 } 673 enum owner-cert-invalid { 674 description 675 "Indicates that the device had a problem processing the 676 voucher (chain verification failed, revoked crl)"; 677 } 678 enum owner-id-mismatch { 679 description 680 "Indicates that the owner-id in the voucher does not 681 match the one inside the owner-cert"; 683 } 684 enum signature-invalid { 685 description 686 "Indicates that the signature could not be verified 687 using the owner-cert"; 688 } 689 enum bootstrap-complete { 690 description 691 "Indicates that the device successfully processed the 692 bootstrap data. At this point, the device is running 693 the required boot-image and configuration. A device 694 is expected to only send this notification once, 695 assuming it does not receive an error in the HTTP 696 response from the Bootstrap Server."; 697 } 698 } 699 mandatory true; 700 } 701 leaf message { 702 type string; 703 description 704 "A human-readable value that might provide useful information"; 705 } 706 } 707 } 709 } 711 713 4. Device 715 Devices supporting ZeroTouch MUST have the preconfigured factory 716 default state and bootstrapping logic described in the following 717 sections. 719 4.1. Factory Default State 720 +------------------------------------------------------------------+ 721 | | 722 | | 723 | +----------------------------------------------------------+ | 724 | | | | 725 | | | | 726 | | 1. list of public Internet Bootstrap Servers | | 727 | | 2. list of trust anchor certs for Bootstrap Servers | | 728 | | 3. trust anchor cert for owner certificates | | 729 | | 4. trust anchor cert for device ownership vouchers | | 730 | | 5. IDevID cert & associated intermediate certificate(s) | | 731 | +----------------------------------------------------------+ | 732 | | 733 | +----------------------+ | 734 | | | | 735 | | | | 736 | | 6. private key | | 737 | +----------------------+ | 738 | | 739 +------------------------------------------------------------------+ 741 1. Devices MUST be manufactured with a list of default Bootstrap 742 Servers. Each Bootstrap Server may be identified via a hostname 743 or an IP address. This may be an empty list if for some reason 744 the Vendor prefers to force its devices to have to discover 745 Bootstrap Servers from a DHCP server. 747 2. Devices MUST be manufactured with a list of trust anchor 748 certificates that can be used to authenticate Bootstrap Server 749 connections with. To support Bootstrap Servers discovered from a 750 DHCP server, these certificates SHOULD include public certificate 751 authorities, such as those that are included in a web browser. 753 3. Devices MUST be manufactured with the trust anchor certificate 754 for Owner certificates that the Vendors provide to business 755 organizations when they enroll in the Vendor's ZeroTouch program. 756 This trust anchor certificate is later used by the device to 757 validate the Owner certificate it downloads from the Bootstrap 758 Server. 760 4. Devices MUST be manufactured with the trust anchor certificate 761 for the device ownership vouchers that the Vendors provide to 762 organizations when it ships out an order of ZeroTouch devices. 763 This trust anchor certificate is later used by the device to 764 validate the Ownership Vouchers it downloads from the Bootstrap 765 Server. 767 5. Devices MUST be manufactured with an initial device identifier 768 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 769 X.509 certificate, encoding a globally unique device identifier 770 (e.g., serial number). The device MUST also possess any 771 intermediate certificates between the IDevID certificate and the 772 Vendor's IDevID trust anchor certificate. These certificates are 773 later used by the device to identify itself when it calls home. 774 In particular, these certificates are to be used by the device's 775 NETCONF server, either as its SSH host-key or its TLS server 776 certificate. Please see NETCONF Call Home 777 [draft-ietf-netconf-call-home] for more information. 779 6. Device MUST be manufactured with a private key that corresponds 780 to the public key encoded in its IDevID certificate. This 781 private key SHOULD be securely stored, ideally by a cryptographic 782 processor (e.g., a TPM). 784 4.2. Boot Sequence 786 Power On 787 | 788 v No 789 1. Running default config? --------> Boot normally 790 | 791 | Yes 792 v No 793 2. Able to reach DHCP server? --------> Boot normally 794 | 795 | Yes 796 v 797 3. Prepend any additional Bootstrap Servers discovered 798 | 799 v No 800 4. Able to bootstrap off any Bootstrap Server? -------> Boot normally 801 (see next diagram for drill-down details) 802 | 803 | Yes 804 v 805 5. Run with new configuration 807 These interactions are described next. 809 1. When the device powers on, it first checks to see if it is 810 running the factory default configuration. If it is running a 811 modified configuration, then it boots normally. 813 2. The device tries to obtain a dynamic network assignment from a 814 DHCP server. If it is unable to reach a DHCP server, it boots 815 normally. 817 3. If the DHCP server's offer includes the ZeroTouch Information 818 DHCP option defined in Section 7.1, the device prepends the 819 specified Bootstrap Servers to its factory default list. 821 4. The device iterates over its list of Bootstrap Servers, as 822 described in the next section. If it is unable to bootstrap 823 itself off any of the servers, it boots normally. 825 5. If the device was able to bootstrap itself off any of the 826 Bootstrap Servers, it runs with the new configuration merged into 827 its running datastore. 829 Following are the actions performed by the device when bootstrap off 830 a Bootstrap Server (step #4 the in previous diagram). 832 Connect to port 443 833 | 834 v No 835 1. Able to validate server certificate? ------> Exit 836 | 837 | Yes 838 v No 839 2. Able to validate ownership voucher? ------> Post notification and exit 840 | 841 | Yes 842 v No 843 3. Able to validate owner certificate? ------> Post notification and exit 844 | 845 | Yes 846 v No 847 4. Able to validate boot image info? ------> Post notification and exit 848 | 849 | Yes 850 v No 851 5. Need to install boot image? ------> Install and reboot 852 | 853 | Yes 854 v No 855 6. Able to validate configuration? ------> Post notification and exit 856 | 857 | Yes 858 v 859 7. Merge configuration into running datastore 860 | 861 v 862 8. Post bootstrap complete notification and exit 864 These interactions are described next. 866 1. As part of the HTTPS connection, the device will need to 867 authenticate the server certificate presented by the Bootstrap 868 Server. The device authenticates the server certificate using 869 path-validation to one of its preconfigured Bootstrap Server 870 trust anchors. If the device is unable to authenticate the 871 server's certificate, it abandons this Bootstrap Server and 872 exits. 874 2. The device downloads the ownership voucher from the Bootstrap 875 Server. The device validates the voucher is signed by its 876 Vendor, using its preconfigured trust anchor for device ownership 877 vouchers. The device also validates that its unique identifier 878 is listed by the voucher. If the device is unable to validate 879 the voucher or can not find its unique identifier listed, it 880 posts a notification message to that effect and abandons this 881 Bootstrap Server. 883 3. The device downloads the owner certificate from the Bootstrap 884 Server. The device validates that this certificate is signed by 885 its Vendor, using path-validation to its preconfigured trust 886 anchor for owner certificates. The device also validates that 887 the organization identifier is the same as listed in the 888 ownership voucher, validated in step #2. If the device is unable 889 to validate the certificate or the owner identifier does not 890 match, it posts a notification message to that effect and 891 abandons this Bootstrap Server. 893 4. The device tries to download the boot image information. If no 894 boot image information is available, it skips the remainder of 895 this step. Otherwise, the device validates the boot image 896 information using the public key from the owner certificate 897 obtained in step #3. If it is unable to authenticate the boot 898 image information, it posts a notification message to that effect 899 and abandons this Bootstrap Server. 901 5. The device checks if the specified boot-image name matches what 902 the device is currently running. If there is a mismatch, device 903 downloads the new image from the Bootstrap Server and installs 904 it. It is expected that the device will reboot itself in order 905 to activate the new image and, further, that doing so preserves 906 its factory default state such that it will return to this same 907 check again, but then running the correct image. If the device 908 is unable to install the boot-image, it posts a notification 909 message to that effect and abandons this Bootstrap Server. 911 6. The device downloads the configuration from the Bootstrap Server 912 and validates the configuration using the public key from the 913 owner certificate obtained in step #3. If it is unable to 914 authenticate the configuration, it posts a notification message 915 to that effect and abandons this Bootstrap Server. 917 7. The device merges the configuration into its running datastore. 918 It is expected that this configuration will provide the 919 information necessary for the device to establish a secure 920 NETCONF connection to its NMS using NETCONF Call Home 921 ([draft-ietf-netconf-call-home]). 923 8. The device posts a bootstrap completion notification message to 924 the Bootstrap Server and exits. 926 5. Network Management System (NMS) 928 5.1. Overview 930 It is expected that the bootstrapping configuration will guide the 931 device to initiate a secure NETCONF connection to the NMS using 932 NETCONF Call Home [draft-ietf-netconf-call-home]. This section 933 describes what the NMS needs to do to ensure security for the 934 device's connection. 936 5.2. Precondition 938 +-----------------------------------------------------------------+ 939 | | 940 | | 941 | +-----------------------------------------------------+ | 942 | | | | 943 | | | | 944 | | 1. list of IDevID trust anchor certificates | | 945 | +-----------------------------------------------------+ | 946 | | 947 | +-----------------------------------------------------+ | 948 | | | | 949 | | | | 950 | | 2. list of expected device unique identifiers | | 951 | +-----------------------------------------------------+ | 952 | | 953 | +-----------------------------------------------------+ | 954 | | | | 955 | | | | 956 | | 3. map of device identifiers to login credentials | | 957 | +-----------------------------------------------------+ | 958 | | 959 +-----------------------------------------------------------------+ 961 1. In order to authenticate a device, the NMS MUST possess the 962 IDevID trust anchor provided by its Vendor to enable verification 963 of the device's IDevID certificate. Specifically, the NMS uses 964 this certificate to validate the identity certificate a device 965 presents when negotiating the SSH or TLS transport for the 966 NETCONF Call Home connection [draft-ietf-netconf-call-home]. 967 Because an NMS may interoperate with multiple vendors, and a 968 vendor may have more than one trust anchor for signing its 969 devices IDevID certificates, this generalizes into the NMS 970 needing a list of trust anchor certificates. These certificates 971 SHOULD be stored in a way that prevents tampering, which is why 972 they are shown in read-only storage in the diagram. 974 2. In order for the NMS to validate that a specific device 975 connecting to it is legitimate, it MUST have a list of expected 976 unique device identifiers (e.g., serial-numbers). The unique 977 identifier encoded into the device's IDevID certificate MUST 978 match one of the expected identifiers in order for a device to be 979 considered legitimate. 981 3. The NMS must have login credentials for each device. These 982 credentials may be, for instance, a private key used for SSH or 983 TLS client authentication. It is expected that a device is able 984 to authenticate the NMS's credentials by virtue of the 985 configuration it downloads from the Bootstrap Server. These 986 private-keys SHOULD be stored securely, such that they can not be 987 easily compromised. 989 5.3. Connection Handling 991 When receiving a NETCONF call home connection from a device, the NSM 992 completes the connection as specified NETCONF Call Home 993 [draft-ietf-netconf-call-home]. 995 6. Security Considerations 997 6.1. Entropy loss over time 999 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 1000 IDevID certificate should never expire (i.e. having a notAfter 1001 99991231235959Z). Given the long-lived nature of these certificates, 1002 it is paramount to use a strong key length (e.g., 512-bit ECC). 1003 Vendors SHOULD deploy Online Certificate State Protocol (OCSP) 1004 responders or CRL Distribution Points (CDP) to revoke certificates in 1005 case necessary. 1007 6.2. Serial Numbers 1009 This draft suggests using the device's serial number as the unique 1010 identifier in its IDevID certificate. This is because serial numbers 1011 are ubiquitous and prominently contained in invoices and on labels 1012 affixed to devices and their packaging. That said, serial numbers 1013 many times encode revealing information, such as the device's model 1014 number, manufacture date, and/or sequence number. Knowledge of this 1015 information may provide an adversary with details needed to launch an 1016 attack. 1018 7. IANA Considerations 1020 7.1. ZeroTouch Information DHCP Options 1022 The following registrations are in accordance to RFC 2939 for "BOOTP 1023 Vendor Extensions and DHCP Options" registry maintained at 1024 http://www.iana.org/assignments/bootp-dhcp-parameters. 1026 7.1.1. DHCP v4 Option 1028 Tag: XXX 1030 Name: Zero Touch Information 1032 Description: Returns a list of null-terminated Configuration 1033 Server hostnames and/or IP addresses. 1035 Code Len 1036 +-----+-----+------+------+---- 1037 | XXX | n | svr1 | svr2 | ... 1038 +-----+-----+------+------+---- 1040 Reference: RFC XXXX 1042 7.1.2. DHCP v6 Option 1044 Tag: YYY 1046 Name: Zero Touch Information 1048 Description: Returns a list of null-terminated Configuration 1049 Server hostnames and/or IP addresses. 1051 Code Len 1052 +-----+-----+------+------+---- 1053 | YYY | n | svr1 | svr2 | ... 1054 +-----+-----+------+------+---- 1056 Reference: RFC XXXX 1058 8. Acknowledgements 1060 The authors would like to thank for following for lively discussions 1061 on list and in the halls (ordered by last name): David Harrington, 1062 Dean Bogdanovic, Martin Bjorklund, Stephen Hanna, Wes Hardaker, Russ 1063 Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder. 1065 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 1066 brainstorming the original I-D's solution during the IETF 87 meeting 1067 in Berlin. 1069 9. Normative References 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1075 Network Configuration Protocol (NETCONF)", RFC 6020, 1076 October 2010. 1078 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 1079 Shell Authentication", RFC 6187, March 2011. 1081 [Std-802.1AR-2009] 1082 IEEE SA-Standards Board, "IEEE Standard for Local and 1083 metropolitan area networks - Secure Device Identity", 1084 December 2009, . 1087 [draft-ietf-netconf-call-home] 1088 Watsen, K., "NETCONF Call Home (work in progress)", 1089 October 2014, . 1092 [draft-ietf-netconf-restconf] 1093 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1094 Protocol", draft-ieft-netconf-restconf-04 (work in 1095 progress), 2014, . 1098 [draft-ietf-netconf-server-model] 1099 Watsen, K., "NETCONF Server Model (work in progress)", 1100 September 2014, . 1103 Appendix A. Examples 1105 A.1. Ownership Voucher 1107 Following describes an example data-model for an Ownership Voucher. 1108 Real vouchers are expected to be encoded in a Vendor-specific format 1109 outside the of scope for this draft. 1111 A tree digram describing an Ownership Voucher: 1113 module: ietf-zerotouch-ownership-voucher 1114 +--rw voucher 1115 +--rw unique-id* string 1116 +--rw owner-id string 1117 +--rw created-on yang:date-and-time 1118 +--rw expires-on? yang:date-and-time 1119 +--rw signature string 1121 The YANG module for this example voucher: 1123 file "ietf-zerotouch-ownership-voucher@2015-03-09.yang" 1125 module ietf-zerotouch-ownership-voucher { 1127 namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher"; 1128 prefix "ztov"; 1130 import ietf-yang-types { prefix yang; } 1132 organization 1133 "IETF NETCONF (Network Configuration) Working Group"; 1135 contact 1136 "WG Web: 1137 WG List: 1138 WG Chair: Mehmet Ersue 1139 1140 WG Chair: Mahesh Jethanandani 1141 1142 Editor: Kent Watsen 1143 "; 1145 description 1146 "This module defines the format for a ZeroTouch ownership voucher, 1147 which is produced by Vendors, relayed by Bootstrap Servers, and 1148 consumed by devices. The purpose of the voucher is to enable a 1149 device to ascertain the identity of its rightful owner, as 1150 certified by its Vendor. 1152 Copyright (c) 2014 IETF Trust and the persons identified as 1153 authors of the code. All rights reserved. 1155 Redistribution and use in source and binary forms, with or 1156 without modification, is permitted pursuant to, and subject 1157 to the license terms contained in, the Simplified BSD 1158 License set forth in Section 4.c of the IETF Trust's 1159 Legal Provisions Relating to IETF Documents 1160 (http://trustee.ietf.org/license-info). 1162 This version of this YANG module is part of RFC XXXX; see 1163 the RFC itself for full legal notices."; 1165 revision "2015-03-09" { 1166 description 1167 "Initial version"; 1168 reference 1169 "RFC XXXX: Zero Touch Provisioning for NETCONF Call Home"; 1170 } 1172 // top-level container 1173 container voucher { 1174 leaf-list unique-id { 1175 type string; 1176 min-elements 1; 1177 description 1178 "The unique identifier (e.g., serial-number) for a device. 1179 The value must match the value in the device's IDevID 1180 certificate. A device uses this value to determine if 1181 the voucher applies to it."; 1182 } 1183 leaf owner-id { 1184 type string; 1185 mandatory true; 1186 description 1187 "A Vendor-assigned value for the rightful owner of the 1188 devices enumerated by this voucher. The owner-id value 1189 must match the value in the owner-certificate below"; 1190 } 1191 leaf created-on { 1192 type yang:date-and-time; 1193 mandatory true; 1194 description 1195 "The date this voucher was created"; 1196 } 1197 leaf expires-on { 1198 type yang:date-and-time; 1199 description 1200 "The date this voucher expires, if any"; 1201 } 1202 leaf signature { 1203 type string; 1204 mandatory true; 1205 description 1206 "The signature over the concatenation of all the previous 1207 values"; 1208 } 1209 } 1210 } 1212 1214 A.2. Bootstrap Server's API 1216 ['\' line wrapping added for formatting only] 1218 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1219 devices/device=123456/ownership-voucher 1221 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1222 devices/device=123456/owner-certificate 1224 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1225 devices/device=123456/boot-image 1227 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1228 devices/device=123456/configuration 1230 POST https://example.com/restconf/operations/ietf-zerotouch-bootstrap-\ 1231 server:notification 1233 A.3. Bootstrap Configuration 1235 This example illustrates a configuration enabling secure NETCONF 1236 call-home using standards-based YANG modules. 1238 1239 1241 1242 1243 1244 1245 admin 1246 1247 admin's rsa ssh host-key 1248 ssh-rsa 1249 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1250 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1251 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1252 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1253 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1254 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1255 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1256 1257 1258 1259 1261 1262 1263 1264 1265 config-mgr 1266 1267 1268 1269 east-data-center 1270
11.22.33.44
1271 1272 1273 west-data-center 1274
55.66.77.88
1275 1276 1277 1278 my-call-home-x509-key 1279 1280 1281 1282 1283 1285 1286 Appendix B. Change Log 1288 B.1. ID to 00 1290 o Major structural update; the essence is the same. Most every 1291 section was rewritten to some degree. 1293 o Added a Use Cases section 1295 o Added diagrams for "Actors and Roles" and "NMS Precondition" 1296 sections, and greatly improved the "Device Boot Sequence" diagram 1298 o Removed support for physical presence or any ability for 1299 Configlets to not be signed. 1301 o Defined the ZeroTouch Information DHCP option 1303 o Added an ability for devices to also download images from 1304 Configuration Servers 1306 o Added an ability for Configlets to be encrypted 1308 o Now Configuration Servers only have to support HTTP/S - no other 1309 schemes possible 1311 B.2. 00 to 01 1313 o Added boot-image and validate-owner annotations to the "Actors and 1314 Roles" diagram. 1316 o Fixed 2nd paragraph in section 7.1 to reflect current use of 1317 anyxml. 1319 o Added encrypted and signed-encrypted examples 1321 o Replaced YANG module with XSD schema 1323 o Added IANA request for the ZeroTouch Information DHCP Option 1325 o Added IANA request for media types for boot-image and 1326 configuration 1328 B.3. 01 to 02 1330 o Replaced the need for a Configuration Signer with the ability for 1331 each NMS to be able to sign its own configurations, using Vendor 1332 signed Ownership Vouchers and Owner certificates. 1334 o Renamed Configuration Server to Bootstrap Server, a more 1335 representative name given the information devices download from 1336 it. 1338 o Replaced the concept of a Configlet by defining a southbound 1339 interface for the Bootstrap Server using YANG. 1341 o Removed the IANA request for the boot-image and configuration 1342 media types 1344 Authors' Addresses 1346 Kent Watsen 1347 Juniper Networks 1349 EMail: kwatsen@juniper.net 1351 Joe Clarke 1352 Cisco Systems 1354 EMail: jclarke@cisco.com 1356 Mikael Abrahamsson 1357 T-Systems 1359 EMail: "mikael.abrahamsson@t-systems.se