idnits 2.17.1 draft-ietf-netconf-zerotouch-00.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 8 instances of too long lines in the document, the longest one being 7 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 776 has weird spacing: '...ntifier str...' -- The document date (July 1, 2014) is 3580 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3365' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC4252' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1054, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) -- Possible downref: Non-RFC (?) normative reference: ref. 'NETCONF-REVERSE-SSH' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft S. Hanna 4 Intended status: Standards Track Juniper Networks 5 Expires: January 02, 2015 J. Clarke 6 Cisco Systems 7 M. Abrahamsson 8 T-Systems 9 July 1, 2014 11 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) 12 draft-ietf-netconf-zerotouch-00 14 Abstract 16 This draft presents a technique for establishing a secure NETCONF 17 connection between a newly deployed IP-based device, configured with 18 just its factory default settings, and the new owner's Network 19 Management System (NMS). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 02, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.4. Actors and Roles . . . . . . . . . . . . . . . . . . . . 5 60 2. Configuration Server . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Service Interface . . . . . . . . . . . . . . . . . . . . 7 62 2.2. Interactive Interface . . . . . . . . . . . . . . . . . . 7 63 2.3. Transport Security . . . . . . . . . . . . . . . . . . . 8 64 2.4. Expiration Policy . . . . . . . . . . . . . . . . . . . . 8 65 2.5. Troubleshooting and Auditing . . . . . . . . . . . . . . 8 66 3. Configuration Signer . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Signing Configurations . . . . . . . . . . . . . . . . . 9 69 3.3. Optional Encryption . . . . . . . . . . . . . . . . . . . 9 70 3.4. Delegation of Trust . . . . . . . . . . . . . . . . . . . 9 71 3.5. Delegation to a Specific Customer . . . . . . . . . . . . 10 72 4. Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Factory Default State . . . . . . . . . . . . . . . . . . 11 75 4.3. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Network Management System (NMS) . . . . . . . . . . . . . . . 15 77 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.2. Precondition . . . . . . . . . . . . . . . . . . . . . . 16 79 5.3. Connection Handling . . . . . . . . . . . . . . . . . . . 17 80 6. Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.1. Order Information . . . . . . . . . . . . . . . . . . . . 17 82 6.2. Ownership Validation . . . . . . . . . . . . . . . . . . 17 83 7. Configlet . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 18 86 7.3. Signature . . . . . . . . . . . . . . . . . . . . . . . . 19 87 7.4. Encryption (optional) . . . . . . . . . . . . . . . . . . 19 88 7.5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 8.1. Immutable storage for trust anchors . . . . . . . . . . . 22 91 8.2. Substitutions . . . . . . . . . . . . . . . . . . . . . . 22 92 8.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 22 93 8.4. Entropy loss over time . . . . . . . . . . . . . . . . . 23 94 8.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 23 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 9.1. ZeroTouch Information DHCP Option . . . . . . . . . . . . 23 97 9.2. Media Types for Images and Configurations . . . . . . . . 23 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 101 11.2. Informative References . . . . . . . . . . . . . . . . . 24 102 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24 103 A.1. Signed Configlet . . . . . . . . . . . . . . . . . . . . 25 104 A.2. Signed Encypted Configlet . . . . . . . . . . . . . . . . 28 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 106 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 28 107 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 1.2. Objectives 119 A fundamental business requirement is to reduce operational costs 120 where possible. Deploying new IP-based devices is many times one of 121 the largest costs in running a network, as sending trained 122 specialists to each site to do an installation is both cost 123 prohibitive and does not scale. 125 Both networking vendors and standard bodies have tried to address 126 this issue, with varying levels of success. For instance, the 127 Broadband Forum TR-069 specification [TR069] relies solely on DHCP 128 for NMS discovery, but this can only work in environments where the 129 DHCP server is locally administered, which is not the case when the 130 device is connected to an ISP's network. In another example, some 131 network vendors have enabled their devices to load an initial 132 configuration from removable storage media (e.g., a USB flash drive), 133 but not all devices have such ports. 135 The solution presented herein, ZeroTouch, enables a device to 136 securely obtain an initial configuration from the network without any 137 operator intervention. The discovered configuration initiates the 138 device to "call home" using either the SSH or TLS, as described in 139 [NETCONF-REVERSE-SSH] and [RFC5539bis] respectively. 141 1.3. Use Cases 143 o Connecting to a remotely administered network 145 This use-case involves scenarios, such as a remote branch 146 office or convenience store, whereby the device connects to an 147 ISP's network. In this case, the device receives only generic 148 networking settings (address, netmask, gateway, DNS servers, 149 etc.) provided by the ISP, with no site-specific 150 customizations, such that the device has no recourse but to 151 reach out to the presumably insecure network for its initial 152 configuration. 154 o Connecting to a locally administered network 156 This use-case covers all other scenarios and differs only in 157 that the device may additionally receive some site-specific 158 information to guide its call home process, which could then 159 direct it to a local server for its initial configuration. If 160 no site-specific information is provided, or the device is 161 unable to use the information provided, it can then reach out 162 to network just as it would for a remotely administered 163 network. 165 1.4. Actors and Roles 167 +----------+ fetches Configlet 168 +-------| Device |-------------------+ 169 | +----------+ | 170 | ^ | 171 | | V 172 | call home | +----------+ 173 | | | Config | 174 | | | Server |<----+ 175 | | produces +----------+ | 176 | | | 177 | | | 178 | +----------+ delegates trust | 179 | | Vendor |-------------------+ | 180 | +----------+ | | 181 | ^ | | 182 | | V | 183 | | +----------+ | 184 | | imports | Config | | 185 | | trust | Signer | | 186 | | anchor +----------+ | 187 | | ^ | 188 | | | | 189 | +---------+ requests signing | | 190 +------>| NMS |--------------------+ | 191 +---------+ | 192 | places signed Configlet onto | 193 +-------------------------------------+ 195 Though not represented as a box in the diagram, the Configlet is also 196 a first-class object in the solution. 198 o Configlet 200 A Configlet is an XML document that, when loaded onto a device, 201 configures the device to initiate a call home connection to a 202 deployment specific NMS, as well as set a local administrator 203 account for the NMS to log into. The Configlet is signed and 204 optionally encrypted. More information about Configlets is in 205 Section 7. 207 o Configuration Server 209 A Configuration Server hosts configurations to be downloaded 210 over a network. Configuration Servers can be deployed either 211 on the locally administered network or on some external network 212 (e.g., the Internet). Configuration Servers are known to 213 devices in the form of a URI, which can be either preconfigured 214 or dynamically discovered. More information about 215 Configuration Servers is in Section 2. 217 o Configuration Signer 219 A Configuration Signer is an entity that the device's vendor 220 has delegated the signing function to. A Configuration Signer 221 only needs to ensure that the requestor is the rightful owner 222 of the device to which a configuration is destined. A 223 Configuration Signer may be site-specific or an external 224 entity. More information about Configuration Signers is in 225 Section 3. 227 o Device 229 The device is the networking entity that initiates ZeroTouch, 230 whenever booting with its factory default settings. The device 231 is preconfigured with a secure device identity, for 232 Configuration Servers URIs, and certificates for Configuration 233 Signers and Configuration Servers it trusts by default. A 234 device may dynamically discover additional URIs and 235 certificates from a locally-administered network. More 236 information about Devices is in Section 4. 238 o Network Management System 240 The NMS is the deployment-specific system that devices initiate 241 their call home connections to. The NMS must be configured 242 with vendor-specific trust anchors and unique device 243 identifiers. The administrators of the NMS system interact 244 with Configuration Signer and Configuration Server systems to 245 stage the the device configurations. More information about 246 Network Management Systems is in Section 5. 248 o Vendor 250 Vendors manufacture the devices with secure device identities 251 and preconfigured Configuration URIs, and Configuration Signer 252 certificates. Vendors are the de facto Configuration Signer 253 for the devices it manufactures, but may delegate that role to 254 external Configuration Signers. More information about Vendors 255 is in Section 6. 257 2. Configuration Server 259 A Configuration Server is the entity hosting configurations that can 260 be downloaded over a network. This section describes the service 261 interface a Configuration Server must implement as well as what's 262 needed for transport security. 264 2.1. Service Interface 266 Configuration Servers are known to devices in the form of a URI. 267 Configuration Servers MUST support the URI schemes "https" and 268 "http". Other URI schemes are not supported. 270 When accessing a Configuration Server, the device appends its unique 271 device identifier (UID) to the URI. The unique identifies MUST be 272 the same as the identifier stored within the device's IDevID 273 certificate. 275 For instance, if the URI were: 277 http://example.com/zerotouch/devices/ 278 https://example.com/zerotouch?id= 280 then the device would try to access: 282 http://example.com/zerotouch/devices/ 283 https://example.com/zerotouch?id= 285 When accessing the Configuration Server, the HTTP Accept-Type MUST be 286 set to either "application/zerotouch-config" or "application/ 287 zerotouch-bootimage". Please see Section 9.2. A wildcard Accept- 288 Type (e.g., */*) SHOULD default to "application/zerotouch-config". 290 2.2. Interactive Interface 292 The Configuration server SHOULD to provide some user-facing interface 293 to enable to the end-user to provide a Configlet and, optionally, an 294 bootimage file. How the Configlet and bootimage file are provided to 295 the Configuration Server is outside the scope of this document. 297 2.3. Transport Security 299 As described in Section 3, configurations MUST be signed and MAY be 300 encrypted. As such, transport-level security is not needed to assure 301 authenticity or confidentiality of the configuration itself. 302 However, transport-level security enables devices to authenticate the 303 Configuration Server and also extends confidentiality to the 304 application-level protocol. Therefore, it is RECOMMENDED for 305 Configuration Servers to support transport-level encryption. 307 If a Configuration Server uses X.509-based encryption, then its X.509 308 certificate MUST have a chain of trust to a trust anchor known to 309 devices (see Section 4.2. More specifically, the Configuration 310 Server MUST possess all the intermediate certificates leading to the 311 trust anchor. 313 When a Configuration Server negotiates encryption with the device, it 314 provides the chain of certificates, from its own to, but not 315 including, the trust anchor. Including the trust anchor's 316 certificate is unnecessary since the device MUST be pre-provisioned 317 with it. Devices need the chain of certificates to be passed so they 318 can validate the server using only a list of Configuration Server 319 trust anchors. 321 2.4. Expiration Policy 323 An expiration policy is needed to limit how long a Configuration 324 Server needs to retain a configuration and, in turn, how many 325 configurations it might need to retain at a given time. 327 It is expected that Configuration Servers will enable retention 328 information to be given at the same time as when the configuration is 329 provided to it. Options should be temporal in nature, not based on 330 access counts, so as to thwart a DoS attack whereby the configuration 331 is accessed by an entity other than the device. Configuration 332 Servers SHOULD put a limit on the maximum amount of time it will hold 333 onto a configuration before purging it, even if the configuration had 334 never been accessed. 336 2.5. Troubleshooting and Auditing 338 In order to facilitate troubleshooting and auditing, the 339 Configuration Server SHOULD record into a log a record of the various 340 Configlet download requests. This draft does not define what 341 information should be kept or for how long. 343 3. Configuration Signer 345 3.1. Overview 347 A Configuration Signer MUST be able to sign configurations. This 348 function requires the Configuration Signer be able to authenticate 349 that the requestor is the true owner of the device, as identified 350 within the contents of the configuration being signed. 352 The user interface a Configuration Signer provides to perform its 353 role is outside the scope of this document. However, in order to 354 meet operational expectations, the time it takes to respond to a 355 request should be as expeditious as possible. 357 A Configuration Signer does not need to retain a configuration after 358 signing it. The Configuration Signer SHOULD retain an audit log for 359 indemnification purposes. 361 3.2. Signing Configurations 363 A Configlet Signer MUST have an X.509 certificate with Key Usage 364 capable of signing data (digitalSignature) and be signed by a 365 certificate authority having a chain of trust leading to a trust 366 anchor known to the devices loading its Configlets. The Configlet 367 Signer MUST possess all intermediate certificates leading to its 368 trust anchor. 370 When a Configlet Signer signs a Configlet, it attaches both the 371 signature and the chain of X.509 certificates, including its own, but 372 not necessarily including the trust anchor's certificate. This chain 373 of certificates is needed so a device can validate a Configlet using 374 only the Configlet Signer trust anchors known to it. 376 3.3. Optional Encryption 378 A Configuration Signer MAY optionally encrypt configurations prior to 379 signing them. This function requires the Configuration Signer know 380 the device's unique public key, as encoded within its secure device 381 identity certificate. 383 3.4. Delegation of Trust 385 A device's vendor is the root of trust for all of its devices. That 386 is, the vendor's devices implicitly trust the vendor for such things 387 as software images, subscription updates, and licenses. As such, the 388 vendor is the ultimate Configuration Signer for its devices. 390 However, both vendors and its customers may prefer a this role be 391 performed by another entity. For instance, a vendor may not want 392 this role due to it being outside its primary business function, and 393 customers may not want the vendor to have this role for privacy 394 reasons. 396 It is therefore provided that a vendor MAY delegate the Configuration 397 Signer role to other entities. Using X.509 certificates, the Vendor 398 need only sign the delegate's certificate signing request (CSR), 399 providing back to the delegate a signed X.509 certificate 400 authenticating its ability to perform the signing function. 402 In order enable a delegate to fulfill its operational role, as 403 described in Section 3.1, the vendor MUST provide a mechanism that 404 can be used to authenticate if a given requestor is the true owner of 405 a specific device. Additionally, to support Configuration Signers 406 that want to encrypt configurations, the vendor MUST also provide a 407 means for the Configuration Signer to know the public key for a given 408 device. How the vendor provides this information to Configuration 409 Signers is outside the scope of this document. 411 3.5. Delegation to a Specific Customer 413 The general expectation is that the Configuration Signer is an 414 impartial 3rd-party. However, certain deployments may want to be 415 able to perform the function for themselves. Yet without 416 constraints, that deployment could sign configurations for devices 417 that do not belong to it. 419 Resolving this concern is possible when 1) the deployment specific 420 Configuration Signer's certificate is annotated with a customer 421 identifier and 2) the devices sold to that customer have that same 422 identifier encoded into their secure device identifier. 424 This entails the vendor augmenting its manufacturing process for 425 these special devices, which would likely be sold directly to the 426 customer, as opposed to through a sales channel. This takes 427 extraordinary effort and likely only implemented for the most 428 important customers, if at all. 430 4. Device 432 4.1. Overview 434 While the wholistic solution, ZeroTouch, involves a number of 435 entities, a device being powered-on is the essential event that sets 436 things in motion. 438 Whenever a device boots with its factory default settings, it 439 initiates ZeroTouch with the goal of finding a configuration to 440 initialize itself with. Once a configuration is found, the device 441 initializes its running datastore with it and then enters normal 442 operation. Since the configuration initializes the device to call 443 home upon entering its normal operating mode, the device immediately 444 begins trying to establish a secure connection with the deployment 445 specific NMS. 447 4.2. Factory Default State 449 +------------------------------------------------------------------+ 450 | | 451 | | 452 | +------------------------------------------------------+ | 453 | | | | 454 | | | | 455 | | list of Configlet Signer trust anchor certificates | | 456 | | list of Configuration Server trust anchor certs | | 457 | +------------------------------------------------------+ | 458 | | 459 | +----------------------------------------------------------+ | 460 | | | | 461 | | | | 462 | | two sets of Configuration Server URIs | | 463 | | IDevID entity & associated intermediate certificate(s) | | 464 | +----------------------------------------------------------+ | 465 | | 466 | +----------------------+ | 467 | | | | 468 | | | | 469 | | IDevID private key | | 470 | +----------------------+ | 471 | | 472 +------------------------------------------------------------------+ 474 Devices supporting ZeroTouch MUST have a manufacturer-provisioned 475 secure device identifier, as defined in [Std-802.1AR-2009]. This 476 identifier is known by the IEEE standard as the Initial Device 477 Identifier (IDevID). The IDevID includes both an X.509 certificate, 478 encoding a globally unique per-device identifier, and a chain of 479 X.509 certificates leading to the manufacturer's well-known trust 480 anchor. The IDevID is needed in order for the NMS to positively 481 authenticate a device. For NETCONF over SSH Call Home 482 ([NETCONF-REVERSE-SSH]), this certificate requirement constrains the 483 SSH host key algorithms the device is allowed to advertise to those 484 defined in [RFC6187]. 486 Devices supporting ZeroTouch MUST be pre-provisioned with one or more 487 URIs for Internet-based Configuration Servers. These URIs SHOULD be 488 partitioned into one set that contains secure schemes (e.g. https://) 489 and another set that contains insecure schemes (e.g., http://). The 490 reason for partitioning the URIs is so all the secure schemes can 491 attempted before any of the insecure schemes (see Section 4.3). When 492 using a secure scheme, the Configuration Server MUST be authenticated 493 using a trust anchor the device possesses. As each Configuration 494 Server may use a different trust anchor, this generalizes to a list 495 of Configuration Server trust anchor certificates. 497 In order to verify the signature on retrieved configurations, devices 498 supporting ZeroTouch MUST also possess the trust anchor for the 499 Configuration Signer that signed the configuration. Generally, only 500 the manufacturer's trust anchor is needed, as it can then delegate 501 trust for 3rd-party Configuration Signers (see Section 3.4). 502 However, for various reasons, there may be a need for more than one 503 root anchor and therefore this generalizes to a list of Configuration 504 Signer trust anchor certificates. 506 Devices SHOULD ensure that the certificates for its trust anchors are 507 protected from external modification. It is for this reason that the 508 diagram shows the Configuration Signer and Configuration Server 509 certificates in immutable storage. Similarly, per 510 [Std-802.1AR-2009], the IDevID private key shall be stored 511 confidentially and not available outside the DevID module, hence the 512 diagram shows it is held within secure storage. 514 4.3. Boot Sequence 516 DEVICE DHCP CONFIGURATION NMS 517 | SERVER/RELAY SERVERS | 518 | | | | 519 +-->| | | | 520 | | | | | 521 | |--[if running config != factory default, boot normally]--+ | 522 | | | | | | 523 <---------------------------------------------------------------+ | 524 | | | | | 525 | | | | | 526 | | | | | 527 | |--(discovery)-->| [if no dhcp server found, boot normally] | 528 | | | | | 529 | | +---(offer)---| | | 530 | | | | | | 531 | | +--[add any listed config servers to built-in list]--+ | 532 | | | | | | 533 | |<------------------------------------------------------+ | 534 | | | | | 535 | | | | | 536 | | | | | 537 | | (iterate until match, else boot normally) | | 538 | |------------------------------------------------>| | 539 | | | | | 540 | |<------------------------------(zerotouch info)--| | 541 | | | | | 542 | | | | | 543 | | | | | 544 | |--[if current image != expected, get image]----->| | 545 | | | | | 546 | | +-------------------------------------(image)--| | 547 | | | | | | 548 | | +--[if image valid, install & reboot]--+ | | 549 | | | | | | 550 +---------------------------------------------+ | | 551 | | | | 552 | | | | 553 | | | | 554 |--[get config]---------------------------------->| | 555 | | | | 556 | +------------------------------------(config)--| | 557 | | | | | 558 | +--[if config valid, merge into running]--+ | | 559 | | | | | 560 | +--------------------------------------+ | | 561 | | | | | 562 | +--[per new configuration, call home]----------------->| 563 | | | | 564 | | | | 566 Whenever a device boots with its factory default settings, it 567 initiates ZeroTouch with the goal of finding a configuration that 568 will enable it to call home to its deployment-specific NMS. 570 The process begins with the device using the DHCP protocol to obtain 571 a dynamic assignment for its networking stack. When broadcasting the 572 DISCOVERY request, the device may provide any DHCP options to 573 identify itself or the type of device it is (e.g. IPV4 options 60 or 574 61). 576 If the DHCP servers reside on a locally administered network (see 577 Section 1.3), then their OFFER responses MAY include the ZeroTouch 578 Information DHCP option defined in Section 9.1, as well as the legacy 579 DHCP options for TFTP server name, bootfile name, and/or vendor 580 specific information (e.g. IPv4 options 43, 66, 67). 582 If a DHCP server provides both the ZeroTouch Information and the 583 vendor specific information DHCP options, then the ZeroTouch 584 Information option MUST be processed first. After exhausting all 585 ZeroTouch options without being able to call home, a device MAY then 586 process the information provided by the legacy DHCP options. 588 The ZeroTouch Information option Section 9.1 provides a set of 589 Configuration Server URIs. If returned by the DHCP server, the 590 device MUST append each URI to the end of one of its two sets of 591 Configuration Server URIs, depending on if the URI's scheme is secure 592 or not. URIs added this way MUST remain distinguishable from those 593 URIs the device was shipped with, for reasons discussed next. 595 The device then iterates over its two sets of Configuration Server 596 URIs. The device MUST first try all the URIs from the set having 597 secure schemes before trying any of the URIs from the set having 598 insecure schemes. For each URI, until a match is found and 599 successfully loaded, the device attempts to initialize itself from 600 the URI. If the URI uses a secure scheme (e.g., https), the device 601 MUST validate the Configuration Server's certificate using one of its 602 Configuration Server trust anchors. If the device is unable to 603 verify the server's certificate, the device MUST skip that URI. If 604 the device reaches the end of all its URIs without finding a usable 605 match, it SHOULD continue its normal boot sequence using its factory 606 default configuration. 608 When the device is accessing a Configuration Server URI that it was 609 shipped with (i.e. not discovered while initializing its networking), 610 it MUST do so by appending its GUID to the URI string and using the 611 Accept-Type "application/zerotouch-config", as described in 612 Section 2. For URIs discovered via the ZeroTouch Information option, 613 the device MAY also try the raw URI after trying the permutation 614 using its GUID. 616 If the Configuration Server returns a configuration, the device MUST 617 first verify it before use. Configuration verification entails both 618 verifying the configuration's signature using the device's list of 619 Configuration Signer trust anchors, and also verifying that the 620 unique identifier within the Configlet matches the device's unique 621 identifier. 623 Once the configuration is authenticated, the device MUST compare its 624 software image version with the expected version specified within the 625 configuration. If there is a mismatch, the device MUST download the 626 correct image version from the Configuration Server, by appending its 627 GUID to the Configuration Server's URI string and using the Accept- 628 Type "application/zerotouch-bootimage", as described in Section 2. 629 For URIs discovered via the ZeroTouch Information option, the device 630 MAY also try both the raw URI after trying the permutation using its 631 GUID. Once the image has been downloaded, the device MUST install it 632 and reboot, still with the factory default settings configured, so 633 that ZeroTouch restarts when the device comes back up. 635 If the device is running the correct software image version, it 636 merges the Configlet's contents into its running configuration. This 637 step effectively modifies the device so that it is no longer having 638 its factory default setting. However, since the Configlet configured 639 the device to "call home," upon entering its normal operating mode, 640 the device immediately begins trying to establish a call home 641 connection, as specified by the Configlet. 643 If configured to establish a SSH connection, the the device MUST use 644 its IDevID and associated intermediate X.509 certificates as its host 645 key per RFC 6187 [RFC6187]. If configured to establish a TLS 646 connection, the device MUST use its IDevID and associated 647 intermediate X.509 certificates as its server-side certificate for 648 the TLS connection. 650 In order to facilitate troubleshooting, the device SHOULD record into 651 a log information relating to its stepping through the ZeroTouch 652 sequence of steps. This draft does not define any specific log 653 messages, for instance, for Syslog or SNMP. 655 5. Network Management System (NMS) 657 5.1. Overview 659 The NMS is the ultimate destination of ZeroTouch for a device. It is 660 the NMS's network address configured in the Configlet. The device 661 will initiate a call home connection to the NMS, using either a SSH 662 or TLS, as configured by the Configlet loaded. 664 5.2. Precondition 666 +------------------------------------------------------------------+ 667 | | 668 | | 669 | +------------------------------------------------------+ | 670 | | | | 671 | | | | 672 | | list of Configuration Signer trust anchor certs | | 673 | | list of expected device unique identifiers | | 674 | +------------------------------------------------------+ | 675 | | 676 | +--------------------------------------------------+ | 677 | | | | 678 | | | | 679 | | map of device identifiers to login credentials | | 680 | +--------------------------------------------------+ | 681 | | 682 +------------------------------------------------------------------+ 684 In order to authenticate the device, the NMS MUST possess the X.509 685 certificate for the trust anchor leading to the device's entity 686 certificate. The NMS uses this certificate to validate the server- 687 certificate the device presents during SSH or TLS transport 688 negotiation. Because an NMS may interoperate with multiple vendors, 689 and a vendor may have more than one trust anchor for signing its 690 devices IDevID certificates, this generalizes into the NMS needing a 691 list of trust anchor certificates. This certificates SHOULD be 692 stored in a way that prevents tampering, which is why they are shown 693 in immutable storage in the diagram. 695 In order for the NMS to validate that the specific device connecting 696 to it is expected, the MUST have a list of unique device identifiers 697 that it can use to validate the device's IDevID certificate with. 698 The list SHOULD be protected from external modification, which is why 699 it is shown in immutable storage in the diagram. In order for the 700 NMS to know the unique identifiers, device manufacturers will need to 701 provide a mechanism to convey this information to its customers. 702 This draft not specify a format for this information exchange. 704 In addition to authenticating the device, the NMS must also 705 authenticate itself to the device. How this is done is deployment 706 specific, but generalizes to the NMS needing to have login 707 credentials for each device. These credentials will entail knowing a 708 secret (e.g., password, private key). For this reason the diagram 709 shows the NMS storing a map of device credentials in secure storage. 711 5.3. Connection Handling 713 When receiving a NETCONF call home connection from a device, the NSM 714 completes the connection as specified in the SSH 715 [NETCONF-REVERSE-SSH] and TLS [RFC5539bis] drafts. 717 6. Vendor 719 6.1. Order Information 721 In order for a Vendor's customers to preconfigure their NMSs with 722 what devices are expected, as well as to know how to set the "unique- 723 identifier" field within a Configlet when requesting a signing, 724 Vendors need to provide a mechanism for customers to obtain the 725 unique identifier value for the devices they have ordered. For 726 instance, customers could receive emails containing shipping 727 information for their devices. 729 Additionally, to facilitate workflows where the devices are initially 730 received by a customer-specific warehouse, or moved after having been 731 unboxed, it is ideal for the unique identifier to be easily tracked 732 through labels affixed to the device as well as the box it is 733 packaged in. A device's serial number is commonly treated this way 734 and would be suitable for this purpose, so long as it is directly 735 related to its IDevID identity. 737 6.2. Ownership Validation 739 In order for Configuration Signers to validate that a requestor is 740 the true owner of a device (i.e. its IDevID identity), Vendors need 741 to provide a mechanism enabling a near real-time lookup. The 742 interface used to implement this lookup is outside the scope of this 743 document. 745 7. Configlet 747 7.1. Overview 749 A Configlet is an XML file, containing specific YANG-defined 750 configuration, that has been signed by a trusted signer known to the 751 device (e.g., the device's manufacturer). 753 The Configlet data-model, defined by the YANG module in this document 754 (see Section 7), is just enough to configure a local user account and 755 either reverse-SSH or reverse-TLS. More specifically, this data- 756 model is a subset of what's defined in ietf-system and ietf-netconf- 757 server YANG models. This focused data-model is consistent with the 758 common use-case of having the NMS push a full configuration to a 759 device when it calls home. 761 The signature on the Configlet is enveloped, meaning that the 762 signature is contained inside the XML file itself. The signature 763 block also contains the X.509 certificate of the Configlet Signer and 764 its chain of trust. 766 Once a device authenticates the signature on a Configlet and matches 767 the unique identifier (e.g., serial number) within the Configlet, it 768 merges the configuration contained in the Configlet into its running 769 datastore. 771 7.2. Data Model 773 module: ietf-netconf-zerotouch 774 +--rw configlet 775 +--rw target-requirements 776 | +--rw unique-identifier string 777 | +--rw software-version string 778 +--rw configuration 780 The Configlet's data model is no more than a wrapper around a header 781 (i.e. ) and a payload (i.e. ). 783 The element contains information that MUST be 784 validated by the device prior to processing the 785 element. Specifically, it contains: 787 o unique-identifier 789 The unique-identifier field is used to ensure that the 790 Configlet is loaded onto the targeted device and no other. 791 This field is also used by the Configuration Signer, when 792 ensuring the requestor is the true owner of the device. The 793 value MUST be the same as the 'subject' field in the device's 794 DevID credential, as specified by section 7.2.8 in IEEE Std 795 802.1AR-2009. 797 o software-version 799 The software-version field is used to ensure the device is 800 running the right software version prior to loading the 801 configuration (e.g., 14.1R2.5). If the device finds that it is 802 not running the correct version of software, it can pull the 803 correct version from the Configuration Server. 805 The element contains the configuration that is to be 806 committed to the device's running datastore. This element uses the 807 "anyxml" type, enabling it to contain either vendor-specific or 808 standards-based data models. When using standard models, in order to 809 complete a call home connection, only the following is needed: 811 o The "authentication" subtree from "ietf-system", defined in draft- 812 ietf-netmod-system. 814 o If TLS is supported, everything from "ietf-system-tls-auth", 815 defined in draft-ietf-netconf-server-model. 817 o The "call-home" subtree from "ietf-netconf-server", defined in 818 draft-ietf-netconf-server-model. 820 7.3. Signature 822 All Configlets MUST be signed by a Configuration Signer in order to 823 be authentic. Devices MUST reject any Configlet that is either 824 unsigned or having an invalid signature. Configlets are signed using 825 the W3C standard "XML Signature Syntax and Processing" [XMLSIG]. The 826 entire contents of the Configlet MUST be signed. The signature block 827 must also include the Configlet Signer's certificate and any 828 intermediate certificates leading to a Configlet Signer trust anchor. 829 A signed Configlet example is in section Appendix A.1. 831 7.4. Encryption (optional) 833 Configlets MAY optionally be encrypted prior to being signed. 834 Encrypting the Configlet provides confidentiality for the Configlet's 835 contents without relying on transport-level security. Configlets are 836 encrypted using the W3C standard "XML Encryption Syntax and 837 Processing" [XMLENC]. The entire contents of the Configlet MUST be 838 encrypted. An encrypted Configlet example is in section 839 Appendix A.2. 841 7.5. YANG Module 843 Following is the YANG module for the Configlet: 845 module ietf-netconf-zerotouch { 847 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-zerotouch"; 848 prefix "zerotouch"; 849 organization 850 "IETF NETCONF (Network Configuration) Working Group"; 852 contact 853 "WG Web: 854 WG List: 856 WG Chair: Mehmet Ersue 857 859 WG Chair: Bert Wijnen 860 862 Editor: Kent Watsen 863 "; 865 description 866 "This module contains a collection of YANG definitions for 867 configuring NETCONF zerotouch. 869 Copyright (c) 2014 IETF Trust and the persons identified as 870 authors of the code. All rights reserved. 872 Redistribution and use in source and binary forms, with or 873 without modification, is permitted pursuant to, and subject 874 to the license terms contained in, the Simplified BSD 875 License set forth in Section 4.c of the IETF Trust's 876 Legal Provisions Relating to IETF Documents 877 (http://trustee.ietf.org/license-info). 879 This version of this YANG module is part of RFC XXXX; see 880 the RFC itself for full legal notices."; 881 // RFC Ed.: replace XXXX with actual RFC number and 882 // remove this note 884 // RFC Ed.: please update the date to the date of publication 886 revision "2014-07-01" { 887 description 888 "Initial version"; 889 reference 890 "RFC XXXX: A YANG Data Model for NETCONF ZeroTouch Configlet"; 891 } 893 container configlet { 894 description 895 "Top-level container for ZeroTouch configuration objects."; 897 container target-requirements { 898 description 899 "Specifies requirements for device this is loaded onto"; 900 leaf unique-identifier { 901 type string; 902 mandatory true; 903 description 904 "The device MUST have this unique identifier. The value 905 MUST be the same as the 'subject' field in the device's 906 DevID credential, as specified by section 7.2.8 in 907 IEEE Std 802.1AR-2009."; 908 } 909 leaf software-version { 910 type string; 911 mandatory true; 912 description 913 "The device MUST must be running this version of software. 914 The value for this field is device-specific, but it MUST 915 be an exact match (e.g., 14.1R2.5)"; 916 } 917 } 918 anyxml configuration { 919 mandatory true; 920 description 921 "The configuration to be committed to the device's running 922 datastore. The configuration MUST be valid for the target 923 device. Device's supporting ZeroTouch SHOULD at least 924 support both the following standard data-models: 926 ietf-system // the authentication container 927 ietf-system-tls-auth // everything, if TLS supported 928 ietf-netconf-server // the call-home container 930 These three data models contain everything needed to 931 support NETCONF call home using either SSH or TLS."; 932 } 933 } 935 } 937 8. Security Considerations 938 8.1. Immutable storage for trust anchors 940 Devices SHOULD ensure that all its trust anchor certificates, 941 including those for the Configuration Signer and Configuration 942 Server, are protected from external modification. It is for this 943 reason that the diagram in Section 4.2 shows them in immutable 944 storage. 946 However, it may be necessary to update these certificates over time 947 (e.g., the vendor wants to delegate trust to a new CA). It is 948 therefore expected that devices MAY update these trust anchors when 949 needed through a verifiable process, such as a software upgrade using 950 signed software images. 952 8.2. Substitutions 954 It is generally not possible to substitute a Configlet created for a 955 different device, since devices assert that the Configlet contains 956 their unique identifier (e.g., serial number). 958 However, it is possible to substitute a Configlet created for a 959 device with a different Configlet created for the same device. 960 Generally, unless imposed by the Configuration Signers, there is no 961 limit to the number of Configlets that may be generated for a given 962 device. This could be resolved, in part, by placing a timestamp into 963 the Configlet and ensuring devices do not load Configlets older than 964 some amount, but this requires the devices have an accurate clock 965 when validating a Configlet and for Configuration Signers to not sign 966 a Configlet when another Configlet is still active. 968 8.3. Confidentiality 970 This draft allows devices to use insecure schemes when doing a 971 Configuration Server lookup. This is deemed acceptable because the 972 Configlet is tamper-proof, since it MUST be signed, only 973 confidentiality is lost. 975 Confidentiality of a Configlet's contents is assured when either the 976 Configlet is encrypted or when the a secure scheme is used when 977 accessing the Configuration Server. 979 Some confidentiality is lost when an insecure scheme is used to 980 access a Configuration Server, as then the device's unique identifier 981 is in the clear. 983 Given the fairly regular format for unique identifiers, it is 984 possible that an adversary to guess unique identifiers and access a 985 device's Configlet. Configlets that have been encrypted do not 986 disclose any confidential information. 988 8.4. Entropy loss over time 990 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 991 IDevID certificate should never expire (i.e. having a notAfter 992 99991231235959Z). Given the long-lived nature of these certificates, 993 it is paramount to use a strong key length (e.g., 512-bit ECC). 994 Vendors SHOULD deploy Online Certificate State Protocol (OCSP) 995 responders or CRL Distribution Points (CDP) to revoke certificates in 996 case necessary. 998 8.5. Serial Numbers 1000 This draft mentions using the device's serial number as its unique 1001 identifier in its IDevID certificate. This is because serial numbers 1002 are ubiquitous and prominently contained in invoices and on labels 1003 affixed to devices and their packaging. That said, serial numbers 1004 many times encode revealing information, such as the device's model 1005 number, manufacture date, and/or sequence number. Knowledge of this 1006 information may provide an adversary with details needed to launch an 1007 attack. To address this concern, the certificate could contain the 1008 hash of the serial number instead, which the NMS could also compute, 1009 but doing so is much less intuitive and raises questions if it is 1010 just security through obscurity. 1012 9. IANA Considerations 1014 9.1. ZeroTouch Information DHCP Option 1016 TBD, but it essentially returns a list of URIs. 1018 9.2. Media Types for Images and Configurations 1020 TBD, but in accordance with RFC 6838, the draft registers: 1021 application/zerotouch-configlet and application/zerotouch-bootimage 1023 10. Acknowledgements 1025 The authors would like to thank for following for lively discussions 1026 on list and in the halls (ordered by last name): David Harrington, 1027 Dean Bogdanovic, Martin Bjorklund, Wes Hardaker, Russ Mundy, Reinaldo 1028 Penno, Randy Presuhn, Juergen Schoenwaelder. 1030 Special thanks goes to Russ Mundy and Wes Hardaker for brainstorming 1031 the original I-D's solution during the IETF 87 meeting in Berlin. 1033 11. References 1035 11.1. Normative References 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels ", BCP 14, RFC 2119, March 1997. 1040 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1041 Engineering Task Force Standard Protocols ", RFC 3365, 1042 August 2002. 1044 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1045 Authentication Protocol ", RFC 4252, January 2006. 1047 [RFC5539bis] 1048 Badra, M. and A. Luchuk, "Using the NETCONF Protocol over 1049 Transport Layer Security (TLS) ", RFC 5539, March 2011. 1051 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 1052 Shell Authentication ", RFC 6187, March 2011. 1054 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1055 and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC 1056 6241, June 2011. 1058 [NETCONF-REVERSE-SSH] 1059 Watsen, K., "NETCONF over SSH Call Home", April 2014. 1061 [Std-802.1AR-2009] 1062 IEEE SA-Standards Board, "IEEE Standard for Local and 1063 metropolitan area networks - Secure Device Identity", 1064 December 2009. 1066 [XMLSIG] , "XML Signature Syntax and Processing", April 2013. 1068 [XMLENC] , "XML Encryption Syntax and Processing", April 2013. 1070 11.2. Informative References 1072 [TR069] The Broadband Forum, ., "TR-069 Amendment 3, CPE WAN 1073 Management Protocol ", November 2010. 1075 Appendix A. Examples 1076 A.1. Signed Configlet 1078 This example illustrates a Configlet configuring both a local user 1079 account and call home using SSH. This Configlet includes both the 1080 Configuration Signer's certificate as well as an Intermediate 1081 certificate. Note that '\' characters have been added for formatting 1082 reasons. 1084 1085 1087 1088 0123456789 1089 14.1R3.5 1090 1092 1094 1095 1096 1097 1098 admin 1099 1100 admin's rsa ssh host-key 1101 ssh-rsa 1102 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1103 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1104 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1105 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1106 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1107 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1108 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1109 1110 1111 1112 1113 1115 1116 1117 1118 1119 1120 1121 config-mgr 1122 1123 This entry requests the device to periodically 1124 connect to the Configuration Manager application 1125 1126 1127 1128
config-mgr1.example.com
1129 1130 1131
config-mgr2.example.com
1132 1133 1134 1135 1136 5 1137 10 1138 1139 1140 1141 last-connected 1142 10 1143 3 1144 1145 1146 1147 ssh_host_key_cert 1148 1149 1150 ssh_host_key_cert2 1151 1152 1153 1154 1155 1156 1157 1159 1160 1161 1162 1164 1166 1167 1168 1171 1172 1174 2xlFdlVifb1snGBLJuEZYrLjSUQ= 1175 1176 1177 \ 1178 HUx3S7TZXGJGUhazWGRSB9CBMZ0T+tTrB1fOnTcKi9wU4UOnSw5KMWDvOVwc6ldM 1179 UIOJIuJigWhSkn+VvWSWz6qy7LTYIywNcxDyghMvmMXfoRXETpL+qCDxribMi4VW 1180 mVhEw1oe83kJt7W/0DJUE7FFKRUhPjy9EgxpQX/7WdKSK+4f2uYkSpq2UumW3DIU 1181 LeK9vNRVQBbhmcF3zZWANmwKH5V4WeQimwWE497AeSYWgSImSetADI0NvvXfBZjx 1182 JqzFEaYLNz8IB0ZVY+w14s1RZbN7YmxhN1R3q52wWvHjR2SylR/Z5BpIhYoDeKoD 1183 HMQMf3HZL06Hm5S8r8rgGg== 1184 1185 1186 \ 1187 MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f 1188 VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTEzMTAyMDE2MjIx 1189 MFoXDTE0MTAyMDE2MjIxMFowKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE 1190 AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDf 1191 4hyWqFsf801sZYJQBJ0PB4cHmlnPNOs9pv3QCCB1PzlYhfcDOygVmqhzZjPY+t7q 1192 ZTjPs/E8n5X4dd0DkR80uc4MWmzc40Pz2HAW6GQ2mo+eUYzXUqQFbi3EkqrzddZk 1193 gRi6vuadMkAcJH8ugYR+cbw/LlpXhIy2A5fUh4JP7Y9l1wABTbK8eGhF9cvGxBYR 1194 +KqZJycoV6aaIvD/0NO1CNSaGeAJXXxXWoRF5E6HVKsolTHPPdi+40BmYrCuuWy6 1195 1ybCIP5uZZ7Oza4j0n/fPb6SEqEa0I1zUEWlFQMZYsBClNY5TzWHNgQ5dPJO2qgx 1196 PONwnLIsx46DlAzlpFpXAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV 1197 HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6 1198 Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF 1199 BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50 1200 MIHXBgNVHSMEgc8wgcyAFCHd7bYICEQX3QxR30ixhppG7bjmoYGwpIGtMIGqMQsw 1201 CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2 1202 YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp 1203 Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG 1204 SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0 1205 cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw 1206 EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG 1207 A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p 1208 emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG 1209 SIb3DQEBCwUAA4IBAQCsVFVA90O8E4p/8ohBYQRezVaWidTHCTM1sdAoeljlrsFX 1210 xqwcQEGVT3BpzwN8w2r+iKOKLQkWv64os0KKL0RIIjmCmJ2RukqH/R0M8Air4+Im 1211 iWI3xV+HzVRsJIrCRT2tzxbchU/i/LQiwhteUEZ9sZbHKyLQe9x9HgByM05ifOGh 1212 z2dcb7AWNlo7nJtRBmx0v9iim2kktqGMuXgBzlnMMabqHMb4L+vjww2Wn5nNYbr/ 1213 oXq4fa01MGQyvRPAEOwL3ZxcaqKHvmTn9coBLhpP3nQIEV+V+PngQjtBmwdkjIj5 1214 feDp86jGN6348H+z9CzXUSbyOn6utIxN0SvVESxx 1215 \ 1216 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1217 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1218 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1219 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1220 QGp1bmlwZXIuY29tMB4XDTEzMTAyMDE2MjIwOVoXDTE0MTAyMDE2MjIwOVowMDET 1221 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1222 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK+D34JQ/tsWv5SZ5L2TF7u7 1223 xo7eZEpz/BmnXhxa6keBx5gmjkBXgfSMov7ZJaZfzXkCL01YDDCDQyXBLkh/n2bL 1224 3K0AkEUJPTJgSTTQbPtLkVJgWWAwYASu3/L88c9JH33tvPNQusL0qW683Pd3iVV5 1225 VFOe7c2ZZ0aUtw/FBexjOwPmkQdivb78mfNwyJYkgy0dq0z5GaIIZNna2de1N/Jk 1226 mStZEB6+QJfn0qRsaJbA3TS5JQ13ZBSOqcvtjOIDingjHCXGWEULTeF1UVExNXEG 1227 fsHY2CtQaP/r8hT/8TjPB4mJpbuG1P/BpIAXtBC+hqggwAnNpVfcAxReozzoFCcC 1228 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFCHd7bYI 1229 CEQX3QxR30ixhppG7bjmMIHfBgNVHSMEgdcwgdSAFH+nvIT5PZV62rnjGbqzwT2R 1230 K1FOoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1231 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1232 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1233 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQCVivZlfsyT 1234 TzAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1235 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1236 AQsFAAOCAQEAXw4/3c9yC4TiYTxHmEXoqYgw2+xyEtJIEs3Kv7MSbF/cJwXz4lci 1237 8Fy3ZiKgq9gj9vloWLT5V9ri1HCgalD8D56iKtQCOvY7TJ64qChAA8q7/WNC3dbJ 1238 s9Op6+nSpolfG8YNHfBroCSfNOVCteJ+pU26p3cC1150Pr+/yZZHnsMhNLYuLCvq 1239 29uvnPDBC4MMVfcMbasPpsxL7Ue4PJsjnLquGLZ33MgNGP1TdefvYCFLF2ZEIbvi 1240 KEGLOTXMrXsbUbQLZAdlq6kLCm7A3u6gwTMg+NydCziVsARq+ZKJS0n3vDoAIJxl 1241 BfXhJE4VOjAEQ8w+Sftu1lu6rJZr3ctSLg== 1242 1243 1244 1245 1247 A.2. Signed Encypted Configlet 1249 This example is the same as to previous example (section 1250 Appendix A.1) except that the Configlet was encrypted using the 1251 device's public key prior to being signed using the Configuration 1252 Server's private key. Note that '\' characters have been added for 1253 formatting reasons. 1255 // This example is currently missing 1257 Appendix B. Change Log 1259 B.1. ID to 00 1261 Complete re-write. Switched from using signed DNS records using 1262 DNSSEC to using signed YANG-defined XML files using XML Signature. 1263 This update took into a lot a feedback from both operators and 1264 vendors. 1266 B.2. 00 to 01 1267 Major structural update; the essence is the same. Most every 1268 section was rewritten to some degree. 1270 Added a Use Cases section 1272 Added diagrams for "Actors and Roles" and "NMS Precondition" 1273 sections, and greatly improved the "Device Boot Sequence" diagram 1275 Removed support for physical presence or any ability for 1276 Configlets to not be signed. 1278 Defined the ZeroTouch Information DHCP option 1280 Added an ability for devices to also download images from 1281 Configuration Servers 1283 Added an ability for Configlets to be encrypted 1285 Now Configuration Servers only have to support HTTP/S - no other 1286 schemes possible 1288 Authors' Addresses 1290 Kent Watsen 1291 Juniper Networks 1293 EMail: kwatsen@juniper.net 1295 Stephen Hanna 1296 Juniper Networks 1298 EMail: shanna@juniper.net 1300 Joe Marcus Clarke 1301 Cisco Systems 1303 EMail: jclarke@cisco.com 1305 Mikael Abrahamsson 1306 T-Systems 1308 EMail: "mikael.abrahamsson@t-systems.se