idnits 2.17.1 draft-ietf-netconf-zerotouch-01.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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 792 has weird spacing: '...ntifier str...' -- The document date (October 27, 2014) is 3462 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NETCONF-CALL-HOME' == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSIG' Summary: 1 error (**), 0 flaws (~~), 3 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: April 30, 2015 J. Clarke 6 Cisco Systems 7 M. Abrahamsson 8 T-Systems 9 October 27, 2014 11 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) 12 draft-ietf-netconf-zerotouch-01 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 April 30, 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 . . . . . . . . . . . . . . . . . . . 7 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. XSD Schema . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 8.1. Immutable storage for trust anchors . . . . . . . . . . . 21 91 8.2. Substitutions . . . . . . . . . . . . . . . . . . . . . . 21 92 8.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 22 93 8.4. Entropy loss over time . . . . . . . . . . . . . . . . . 22 94 8.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 22 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 9.1. ZeroTouch Information DHCP Option . . . . . . . . . . . . 23 97 9.1.1. DHCP v4 Option . . . . . . . . . . . . . . . . . . . 23 98 9.1.2. DHCP v6 Option . . . . . . . . . . . . . . . . . . . 23 99 9.2. Media Types for Boot Images and Configurations . . . . . 23 100 9.2.1. application/zerotouch-configlet . . . . . . . . . . . 24 101 9.2.2. application/zerotouch-bootimage . . . . . . . . . . . 25 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 105 11.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 107 A.1. Unsigned Configlet . . . . . . . . . . . . . . . . . . . 28 108 A.2. Signed Configlet . . . . . . . . . . . . . . . . . . . . 29 109 A.3. Encrypted Configlet . . . . . . . . . . . . . . . . . . . 32 110 A.4. Signed Encrypted Configlet . . . . . . . . . . . . . . . 33 111 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 112 B.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 36 113 B.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 37 115 1. Introduction 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 1.2. Objectives 125 A fundamental business requirement is to reduce operational costs 126 where possible. Deploying new IP-based devices is many times one of 127 the largest costs in running a network, as sending trained 128 specialists to each site to do an installation is both cost 129 prohibitive and does not scale. 131 Both networking vendors and standard bodies have tried to address 132 this issue, with varying levels of success. For instance, the 133 Broadband Forum TR-069 specification [TR069] relies solely on DHCP 134 for NMS discovery, but this can only work in environments where the 135 DHCP server is locally administered, which is not the case when the 136 device is connected to an ISP's network. In another example, some 137 network vendors have enabled their devices to load an initial 138 configuration from removable storage media (e.g., a USB flash drive), 139 but not all devices have such ports. 141 The solution presented herein, ZeroTouch, enables a device to 142 securely obtain an initial configuration from the network without any 143 operator intervention. The discovered configuration initiates the 144 device to "call home" using either SSH or TLS, as described in 145 [NETCONF-CALL-HOME]. 147 1.3. Use Cases 149 o Connecting to a remotely administered network 151 This use-case involves scenarios, such as a remote branch 152 office or convenience store, whereby the device connects to an 153 ISP's network. In this case, the device receives only generic 154 networking settings (address, netmask, gateway, DNS servers, 155 etc.) provided by the ISP, with no site-specific 156 customizations, such that the device has no recourse but to 157 reach out to the presumably insecure network for its initial 158 configuration. 160 o Connecting to a locally administered network 162 This use-case covers all other scenarios and differs only in 163 that the device may additionally receive some site-specific 164 information to guide its call home process, which could then 165 direct it to a local server for its initial configuration. If 166 no site-specific information is provided, or the device is 167 unable to use the information provided, it can then reach out 168 to network just as it would for a remotely administered 169 network. 171 1.4. Actors and Roles 173 fetches Configlet and 174 +----------+ boot-image, if needed 175 +------------| Device |---------------------+ 176 | +----------+ | 177 | ^ | 178 | | V 179 | call home | manufactures +----------+ 180 | | with necessary | Config | 181 | | default state | Server |<----+ 182 | | for ZeroTouch +----------+ | 183 | | | 184 | | | 185 | +----------+ delegates trust | 186 | | Vendor |-------------------+ | 187 | +----------+ | | 188 | ^ ^ | | 189 | | | V | 190 | | | +----------+ | 191 | imports | | validate owner | Config | | 192 | trust | +-----------------| Signer | | 193 | anchor | +----------+ | 194 | | ^ | 195 | | | | 196 | +---------+ requests signing | | 197 +----------->| NMS |--------------------+ | 198 +---------+ | 199 | | 200 +----------------------------------------+ 201 signed Configlet and boot-image file 203 Though not represented as a box in the diagram, the Configlet is also 204 a first-class object in the solution. 206 o Configlet 208 A Configlet is an XML document that, when loaded onto a device, 209 configures the device to initiate a call home connection to a 210 deployment specific NMS, as well as set a local administrator 211 account for the NMS to log into. The Configlet is signed and 212 optionally encrypted. More information about Configlets is in 213 Section 7. 215 o Configuration Server 217 A Configuration Server hosts Configlets and boot-images to be 218 downloaded over a network via HTTP/S. Configuration Servers 219 can be deployed either on the locally administered network or 220 on some external network (e.g., the Internet). Configuration 221 Servers are known to devices in the form of a URI, which can be 222 either preconfigured or dynamically discovered. More 223 information about Configuration Servers is in Section 2. 225 o Configuration Signer 227 A Configuration Signer is an entity that the device's vendor 228 has delegated the Configlet-signing function to. A 229 Configuration Signer only needs to ensure that the requestor is 230 the rightful owner of the device to which a configuration is 231 destined. A Configuration Signer may be site-specific or an 232 external entity. More information about Configuration Signers 233 is in Section 3. 235 o Device 237 The device is the networking entity that initiates ZeroTouch, 238 whenever booting with its factory default settings. The device 239 is preconfigured with a secure device identity, Configuration 240 Servers URIs, and certificates for both Configuration Signers 241 and Configuration Servers it trusts by default. A device may 242 dynamically discover additional URIs and certificates from a 243 locally-administered network. More information about Devices 244 is in Section 4. 246 o Network Management System 248 The NMS is the deployment-specific system that devices initiate 249 their call home connections to. The NMS must be configured 250 with vendor-specific trust anchors and unique device 251 identifiers. The administrators of the NMS system interact 252 with Configuration Signer and Configuration Server systems to 253 stage the the device configurations. More information about 254 Network Management Systems is in Section 5. 256 o Vendor 258 Vendors manufacture the devices with secure device identities 259 and preconfigured Configuration URIs, and Configuration Signer 260 certificates. Vendors are the de facto Configuration Signer 261 for the devices it manufactures, but may delegate that role to 262 external Configuration Signers. More information about Vendors 263 is in Section 6. 265 2. Configuration Server 267 A Configuration Server is the entity hosting configurations that can 268 be downloaded over a network. This section describes the service 269 interface a Configuration Server MUST implement as well as what's 270 needed for transport security. 272 2.1. Service Interface 274 Configuration Servers are known to devices in the form of a URI. 275 Configuration Servers MUST support the URI schemes "https" and 276 "http". Other URI schemes are not supported. 278 When accessing a Configuration Server, the device appends its unique 279 device identifier (UID) to the URI. The unique identifier MUST be 280 the same as the identifier stored within the device's IDevID 281 certificate, which is described in Section 4.2. 283 For instance, if the URI were: 285 http://example.com/zerotouch/devices/ 286 https://example.com/zerotouch?id= 288 then the device would try to access: 290 http://example.com/zerotouch/devices/ 291 https://example.com/zerotouch?id= 293 When accessing the Configuration Server, the HTTP Accept-Type MUST be 294 set to either "application/zerotouch-configlet" or "application/ 295 zerotouch-bootimage". Please see Section 9.2. A wildcard Accept- 296 Type (e.g., */*) SHOULD default to "application/zerotouch-configlet". 298 2.2. Interactive Interface 300 The Configuration server SHOULD provide a user-facing interface to 301 enable the end-user to provide a Configlet and, optionally, a 302 bootimage file. How the Configlet and bootimage file are provided to 303 the Configuration Server is outside the scope of this document. 305 2.3. Transport Security 307 As described in Section 3, configurations MUST be signed and MAY be 308 encrypted. As such, transport-level security is not needed to assure 309 authenticity or confidentiality of the configuration itself. 311 However, transport-level security enables devices to authenticate the 312 Configuration Server and also extends confidentiality to the 313 application-level protocol. Therefore, it is RECOMMENDED that only 314 secure URL schemes are used (see Section 2.1). 316 If a Configuration Server uses X.509-based encryption, then its X.509 317 certificate MUST have a chain of trust to a trust anchor known to 318 devices (see Section 4.2. More specifically, the Configuration 319 Server MUST possess all the intermediate certificates leading to the 320 trust anchor. 322 When a Configuration Server negotiates encryption with the device, it 323 provides the chain of certificates, from its server specific 324 certificate to, but not including, its trust anchor. Including the 325 trust anchor's certificate is unnecessary since the device MUST be 326 pre-provisioned with it. Devices need the chain of certificates to 327 be passed so they can validate the server using only a simple list of 328 Configuration Server trust anchors. 330 2.4. Expiration Policy 332 An expiration policy is needed to limit how long a Configuration 333 Server needs to retain a configuration and, in turn, how many 334 configurations it might need to retain at a given time. 336 It is expected that Configuration Servers will enable retention 337 information to be given at the same time as when the configuration is 338 provided to it. Options should be temporal in nature, not based on 339 access counts, so as to thwart a DoS attack whereby the configuration 340 is accessed by an entity other than the device. Configuration 341 Servers SHOULD put a limit on the maximum amount of time it will hold 342 onto a configuration before purging it, even if the configuration had 343 never been accessed. 345 2.5. Troubleshooting and Auditing 347 In order to facilitate troubleshooting and auditing, the 348 Configuration Server SHOULD record into a log a record of the various 349 Configlet download requests. This draft does not define what 350 information should be kept or for how long. 352 3. Configuration Signer 354 3.1. Overview 356 A Configuration Signer MUST be able to sign configurations. This 357 function requires the Configuration Signer be able to authenticate 358 that the requestor is the true owner of the device, as identified 359 within the contents of the configuration being signed. 361 The user interface a Configuration Signer provides to perform its 362 role is outside the scope of this document. However, in order to 363 meet operational expectations, the time it takes to respond to a 364 request should be as expeditious as possible. 366 A Configuration Signer does not need to retain a configuration after 367 signing it. The Configuration Signer SHOULD retain an audit log for 368 indemnification purposes. 370 3.2. Signing Configurations 372 A Configuration Signer MUST have an X.509 certificate with Key Usage 373 capable of signing data (digitalSignature) and be signed by a 374 certificate authority having a chain of trust leading to a trust 375 anchor known to the devices loading its Configlets. The 376 Configuration Signer MUST possess all intermediate certificates 377 leading to its trust anchor. 379 When a Configuration Signer signs a Configlet, it attaches both the 380 signature and the chain of X.509 certificates, including its own, but 381 not necessarily including the trust anchor's certificate. This chain 382 of certificates is needed so a device can validate a Configlet using 383 only the Configuration Signer trust anchors known to it. 385 3.3. Optional Encryption 387 A Configuration Signer MAY optionally encrypt configurations prior to 388 signing them. This function requires the Configuration Signer know 389 the device's unique public key, as encoded within its secure device 390 identity certificate. 392 3.4. Delegation of Trust 394 A device's vendor is the root of trust for all of its devices. That 395 is, the vendor's devices implicitly trust the vendor for such things 396 as software images, subscription updates, and licenses. As such, the 397 vendor is the ultimate Configuration Signer for its devices. 399 However, both vendors and its customers may prefer that this role be 400 performed by another entity. For instance, a vendor may not want 401 this role due to it being outside its primary business function, and 402 customers may not want the vendor to have this role for privacy 403 reasons. 405 It is therefore provided that a vendor MAY delegate the Configuration 406 Signer role to other entities. Using X.509 certificates, the Vendor 407 need only sign the delegate's certificate signing request (CSR), 408 providing back to the delegate a signed X.509 certificate 409 authenticating its ability to perform the signing function. 411 In order enable a delegate to fulfill its operational role, as 412 described in Section 3.1, the vendor MUST provide a mechanism that 413 can be used to authenticate if a given requestor is the true owner of 414 a specific device. Additionally, to support Configuration Signers 415 that want to encrypt configurations, the vendor MUST also provide a 416 means for the Configuration Signer to know the public key for a given 417 device. How the vendor provides this information to Configuration 418 Signers is outside the scope of this document. 420 3.5. Delegation to a Specific Customer 422 The general expectation is that the Configuration Signer is an 423 impartial 3rd-party. However, certain deployments may want to be 424 able to perform the function for themselves. Yet without 425 constraints, that deployment could sign configurations for devices 426 that do not belong to it. 428 Resolving this concern is possible when 1) the deployment specific 429 Configuration Signer's certificate is annotated with a customer 430 identifier and 2) the devices sold to that customer have that same 431 identifier encoded into their secure device identifier. 433 This entails the vendor augmenting its manufacturing process for 434 these special devices, which would likely be sold directly to the 435 customer, as opposed to through a sales channel. This takes 436 extraordinary effort and likely only implemented for the most 437 important customers, if at all. 439 4. Device 441 4.1. Overview 443 While the wholistic solution, ZeroTouch, involves a number of 444 entities, a device being powered-on is the essential event that sets 445 things in motion. 447 Whenever a device boots with its factory default settings, it 448 initiates ZeroTouch with the goal of finding a configuration to 449 initialize itself with. Once a configuration is found, the device 450 initializes its running datastore with it and then enters normal 451 operation. Since the configuration initializes the device to call 452 home upon entering its normal operating mode, the device immediately 453 begins trying to establish a secure connection with the deployment 454 specific NMS. 456 4.2. Factory Default State 458 +------------------------------------------------------------------+ 459 | | 460 | | 461 | +------------------------------------------------------+ | 462 | | | | 463 | | | | 464 | | list of Configuration Signer trust anchor certs | | 465 | | list of Configuration Server trust anchor certs | | 466 | +------------------------------------------------------+ | 467 | | 468 | +----------------------------------------------------------+ | 469 | | | | 470 | | | | 471 | | two sets of Configuration Server URIs | | 472 | | IDevID entity & associated intermediate certificate(s) | | 473 | +----------------------------------------------------------+ | 474 | | 475 | +----------------------+ | 476 | | | | 477 | | | | 478 | | IDevID private key | | 479 | +----------------------+ | 480 | | 481 +------------------------------------------------------------------+ 483 Devices supporting ZeroTouch MUST have a manufacturer-provisioned 484 secure device identifier, as defined in [Std-802.1AR-2009]. This 485 identifier is known by the IEEE standard as the Initial Device 486 Identifier (IDevID). The IDevID includes both an X.509 certificate, 487 encoding a globally unique per-device identifier, and a chain of 488 X.509 certificates leading to the manufacturer's well-known trust 489 anchor. The IDevID is needed in order for the NMS to positively 490 authenticate a device. The IDevID certificate MUST be used by the 491 NETCONF server as its SSH host-key (see [RFC6187]) or its TLS server 492 certificate, depending on which protocol is used. 494 Devices supporting ZeroTouch MUST be pre-provisioned with one or more 495 URIs for Internet-based Configuration Servers. These URIs SHOULD be 496 partitioned into one set that contains secure schemes (e.g. https://) 497 and another set that contains insecure schemes (e.g., http://). The 498 reason for partitioning the URIs is so all the secure schemes can 499 attempted before any of the insecure schemes (see Section 4.3). When 500 using a secure scheme, the Configuration Server MUST be authenticated 501 using a trust anchor the device possesses. As each Configuration 502 Server may use a different trust anchor, this generalizes to a list 503 of Configuration Server trust anchor certificates. 505 In order to verify the signature on retrieved configurations, devices 506 supporting ZeroTouch MUST also possess the trust anchor for the 507 Configuration Signer that signed the configuration. Generally, only 508 the manufacturer's trust anchor is needed, as it can then delegate 509 trust for 3rd-party Configuration Signers (see Section 3.4). 510 However, for various reasons, there may be a need for more than one 511 root anchor and therefore this generalizes to a list of Configuration 512 Signer trust anchor certificates. 514 Devices SHOULD ensure that the certificates for its trust anchors are 515 protected from external modification. It is for this reason that the 516 diagram shows the Configuration Signer and Configuration Server 517 certificates in immutable storage. Similarly, per 518 [Std-802.1AR-2009], the IDevID private key shall be stored 519 confidentially and not available outside the IDevID module, hence the 520 diagram shows it is held within secure storage. 522 4.3. Boot Sequence 524 DEVICE DHCP CONFIGURATION NMS 525 | SERVER/RELAY SERVERS | 526 | | | | 527 +-->| | | | 528 | | | | | 529 | |--[if running config != factory default, boot normally]--+ | 530 | | | | | | 531 <---------------------------------------------------------------+ | 532 | | | | | 533 | | | | | 534 | | | | | 535 | |--(discovery)-->| [if no dhcp server found, boot normally] | 536 | | | | | 537 | | +---(offer)---| | | 538 | | | | | | 539 | | +--[add any listed config servers to built-in list]--+ | 540 | | | | | | 541 | |<------------------------------------------------------+ | 542 | | | | | 543 | | | | | 544 | | | | | 545 | | (iterate until match, else boot normally) | | 546 | |------------------------------------------------>| | 547 | | | | | 548 | |<------------------------------(zerotouch info)--| | 549 | | | | | 550 | | | | | 551 | | | | | 552 | |--[if current image != expected, get image]----->| | 553 | | | | | 554 | | +-------------------------------------(image)--| | 555 | | | | | | 556 | | +--[if image valid, install & reboot]--+ | | 557 | | | | | | 558 +---------------------------------------------+ | | 559 | | | | 560 | | | | 561 | | | | 562 |--[get config]---------------------------------->| | 563 | | | | 564 | +------------------------------------(config)--| | 565 | | | | | 566 | +--[if config valid, merge into running]--+ | | 567 | | | | | 568 | +--------------------------------------+ | | 569 | | | | | 570 | +--[per new configuration, call home]----------------->| 571 | | | | 572 | | | | 574 Whenever a device boots with its factory default settings, it 575 initiates ZeroTouch with the goal of finding a configuration that 576 will enable it to call home to its deployment-specific NMS. 578 The process begins with the device using the DHCP protocol to obtain 579 a dynamic assignment for its networking stack. When broadcasting the 580 DISCOVERY request, the device may provide any DHCP options to 581 identify itself or the type of device it is (e.g. IPV4 options 60 or 582 61). 584 If the DHCP servers reside on a locally administered network (see 585 Section 1.3), then their OFFER responses MAY include the ZeroTouch 586 Information DHCP option defined in Section 9.1, as well as the legacy 587 DHCP options for TFTP server name, bootfile name, and/or vendor 588 specific information (e.g. IPv4 options 43, 66, 67). 590 If a DHCP server provides both the ZeroTouch Information and the 591 vendor specific information DHCP options, then the ZeroTouch 592 Information option MUST be processed first. After exhausting all 593 ZeroTouch options without being able to call home, a device MAY then 594 process the information provided by the legacy DHCP options. 596 The ZeroTouch Information option Section 9.1 provides a set of 597 Configuration Server URIs. If returned by the DHCP server, the 598 device MUST append each URI to the end of one of its two sets of 599 Configuration Server URIs, depending on if the URI's scheme is secure 600 or not. URIs added this way MUST remain distinguishable from those 601 URIs the device was shipped with, for reasons discussed next. 603 The device then iterates over its two sets of Configuration Server 604 URIs. The device MUST first try all the URIs from the set having 605 secure schemes before trying any of the URIs from the set having 606 insecure schemes. For each URI, until a match is found and 607 successfully loaded, the device attempts to initialize itself from 608 the URI. If the URI uses a secure scheme (e.g., https), the device 609 MUST validate the Configuration Server's certificate using one of its 610 Configuration Server trust anchors. If the device is unable to 611 verify the server's certificate, the device MUST skip that URI. If 612 the device reaches the end of all its URIs without finding a usable 613 match, it SHOULD continue its normal boot sequence using its factory 614 default configuration. 616 When the device is accessing a Configuration Server URI that it was 617 shipped with (i.e. not discovered while initializing its networking), 618 it MUST do so by appending its UID to the URI string and using the 619 Accept-Type "application/zerotouch-configlet", as described in 620 Section 2. For URIs discovered via the ZeroTouch Information option, 621 the device MAY also try the raw URI after trying the permutation 622 using its UID. 624 If the Configuration Server returns a configuration, the device MUST 625 first verify it before use. Configuration verification entails both 626 verifying the configuration's signature using the device's list of 627 Configuration Signer trust anchors, and also verifying that the 628 unique identifier within the Configlet matches the device's unique 629 identifier. 631 Once the configuration is authenticated, the device MUST compare its 632 software image version with the expected version specified within the 633 configuration. If there is a mismatch, the device MUST download the 634 correct image version from the Configuration Server, by appending its 635 UID to the Configuration Server's URI string and using the Accept- 636 Type "application/zerotouch-bootimage", as described in Section 2. 637 For URIs discovered via the ZeroTouch Information option, the device 638 MAY also try the raw URI after first trying the permutation using its 639 UID. Once the image has been downloaded, the device MUST install it 640 and reboot, still with the factory default settings configured, so 641 that ZeroTouch restarts when the device comes back up. 643 If the device is running the correct software image version, it 644 merges the Configlet's contents into its running configuration. This 645 step effectively modifies the device so that it is no longer having 646 its factory default setting. Thus, at this point, a reboot is no 647 longer expected to start the ZeroTouch process. 649 Though not technically required, the Configlet is presumed to have 650 configured the device to "call home". As soon as this configuration 651 is merged into the running configuration, the device SHOULD 652 immediately begin trying to establish the call home connection, as 653 specified by the Configlet. 655 If configured to establish a SSH connection, the the device MUST use 656 its IDevID and associated intermediate X.509 certificates as its host 657 key per RFC 6187 [RFC6187]. If configured to establish a TLS 658 connection, the device MUST use its IDevID and associated 659 intermediate X.509 certificates as its server-side certificate for 660 the TLS connection. 662 In order to facilitate troubleshooting, the device SHOULD record into 663 a log information relating to its stepping through the ZeroTouch 664 sequence of steps. This draft does not define any specific log 665 messages, for instance, for Syslog or SNMP. 667 5. Network Management System (NMS) 669 5.1. Overview 671 The NMS is the ultimate destination of ZeroTouch for a device. It is 672 the NMS's network address configured in the Configlet. The device 673 will initiate a call home connection to the NMS, using either SSH or 674 TLS, as configured by the Configlet loaded. 676 5.2. Precondition 678 +------------------------------------------------------------------+ 679 | | 680 | | 681 | +------------------------------------------------------+ | 682 | | | | 683 | | | | 684 | | list of IDevID trust anchor certificates | | 685 | | list of expected device unique identifiers | | 686 | +------------------------------------------------------+ | 687 | | 688 | +--------------------------------------------------+ | 689 | | | | 690 | | | | 691 | | map of device identifiers to login credentials | | 692 | +--------------------------------------------------+ | 693 | | 694 +------------------------------------------------------------------+ 696 In order to authenticate the device, the NMS MUST possess the X.509 697 certificate for the trust anchor leading to the device's entity 698 certificate. The NMS uses this certificate to validate the server- 699 certificate the device presents during SSH or TLS transport 700 negotiation. Because an NMS may interoperate with multiple vendors, 701 and a vendor may have more than one trust anchor for signing its 702 devices IDevID certificates, this generalizes into the NMS needing a 703 list of trust anchor certificates. This certificates SHOULD be 704 stored in a way that prevents tampering, which is why they are shown 705 in immutable storage in the diagram. 707 In order for the NMS to validate that the specific device connecting 708 to it is expected, it MUST have a list of unique device identifiers 709 that it can use to validate the device's IDevID certificate with. 710 The list SHOULD be protected from external modification, which is why 711 it is shown in immutable storage in the diagram. In order for the 712 NMS to know the unique identifiers, device manufacturers will need to 713 provide a mechanism to convey this information to its customers. 714 This draft not specify a format for this information exchange. 716 In addition to authenticating the device, the NMS must also 717 authenticate itself to the device. How this is done is deployment 718 specific, but generalizes to the NMS needing to have login 719 credentials for each device. These credentials will entail knowing a 720 secret (e.g., password, private key). For this reason the diagram 721 shows the NMS storing a map of device credentials in secure storage. 723 5.3. Connection Handling 725 When receiving a NETCONF call home connection from a device, the NSM 726 completes the connection as specified NETCONF Call Home 727 [NETCONF-CALL-HOME]. 729 6. Vendor 731 6.1. Order Information 733 In order for a Vendor's customers to configure their NMSs with what 734 devices are expected, as well as to know how to set the "unique- 735 identifier" field within a Configlet when requesting a signing, 736 Vendors need to provide a mechanism for customers to obtain the 737 unique identifier value for the devices they have ordered. For 738 instance, customers could receive emails containing shipping 739 information for their devices. 741 Additionally, to facilitate workflows where the devices are initially 742 received by a customer-specific warehouse, or moved after having been 743 unboxed, it is ideal for the unique identifier to be easily tracked 744 through labels affixed to the device as well as the box it is 745 packaged in. A device's serial number is commonly treated this way 746 and would be suitable for this purpose, so long as it is directly 747 related to its IDevID identity. 749 6.2. Ownership Validation 751 In order for Configuration Signers to validate that a requestor is 752 the true owner of a device (i.e. its IDevID identity), Vendors need 753 to provide a mechanism enabling a near real-time lookup. The 754 interface used to implement this lookup is outside the scope of this 755 document. 757 7. Configlet 759 7.1. Overview 761 A Configlet is an XML file, containing specific YANG-defined 762 configuration, that has been signed by a trusted signer known to the 763 device (e.g., the device's manufacturer). 765 The Configlet data-model, defined by the XSD schema in Section 7.5, 766 contains information for the device to ensure that it's safe for it 767 to load the configlet (i.e. target-requirements) along with a 768 payload, the configuration the device is to merge into its running 769 datastore. 771 In order for the device to call home, the configuration contained 772 within the Configlet MUST at least configure a local user account and 773 configure the connection information for the NMS the device is to 774 call home to. This configuration MAY use IETF-defined modules "ietf- 775 system" [RFC7317] and "ietf-netconf-server" [NETCONF-SERVER-MODEL]. 777 The signature on the Configlet is enveloped, meaning that the 778 signature is contained inside the XML file itself. The signature 779 block also contains the X.509 certificate of the Configuration Signer 780 and its chain of trust. 782 Once a device authenticates the signature on a Configlet and matches 783 the unique identifier (e.g., serial number) within the Configlet, it 784 merges the configuration contained in the Configlet into its running 785 datastore. 787 7.2. Data Model 789 module: ietf-netconf-zerotouch 790 +--rw configlet 791 +--rw target-requirements 792 | +--rw unique-identifier string 793 | +--rw software-version string 794 +--rw configuration 796 The Configlet's data model is no more than a wrapper around a header 797 (i.e. ) and a payload (i.e. ). 799 The element contains information that MUST be 800 validated by the device prior to processing the 801 element. Specifically, it contains: 803 o unique-identifier 805 The unique-identifier field is used to ensure that the 806 Configlet is loaded onto the targeted device and no other. 807 This field is also used by the Configuration Signer, when 808 ensuring the requestor is the true owner of the device. The 809 value MUST be the same as the 'subject' field in the device's 810 IDevID credential, as specified by section 7.2.8 in IEEE Std 811 802.1AR-2009. 813 o software-version 815 The software-version field is used to ensure the device is 816 running the right software version prior to loading the 817 configuration (e.g., 14.1R2.5). If the device finds that it is 818 not running the correct version of software, it MUST pull the 819 correct version from the Configuration Server. 821 The element contains the configuration that is to be 822 committed to the device's running datastore. This element uses the 823 "anyxml" type, enabling it to contain either vendor-specific or 824 standards-based data models. When using standard models, in order to 825 complete a call home connection, only the following is needed: 827 o The "authentication" subtree from "ietf-system", defined in 828 [RFC7317]. 830 o The "call-home" subtree from "ietf-netconf-server", defined in 831 [NETCONF-SERVER-MODEL]. 833 7.3. Signature 835 All Configlets MUST be signed by a Configuration Signer in order to 836 be authentic. Devices MUST reject any Configlet that is either 837 unsigned or having an invalid signature. Configlets are signed using 838 the W3C standard "XML Signature Syntax and Processing" [XMLSIG]. The 839 entire contents of the Configlet MUST be signed. The signature block 840 must also include the Configuration Signer's certificate and any 841 intermediate certificates leading to a Configuration Signer trust 842 anchor. A signed Configlet example is in section Appendix A.2. 844 7.4. Encryption (optional) 846 Configlets MAY optionally be encrypted prior to being signed. 847 Encrypting the Configlet provides confidentiality for the Configlet's 848 contents without relying on transport-level security. Configlets are 849 encrypted using the W3C standard "XML Encryption Syntax and 850 Processing" [XMLENC]. The entire contents of the Configlet MUST be 851 encrypted. An encrypted Configlet example is in section 852 Appendix A.4. 854 7.5. XSD Schema 856 Following is the XSD for the Configlet: 858 859 863 864 865 866 867 868 869 870 871 872 Specifies the unique identifier of the device that 873 is to process this Configlet. The value MUST be 874 the same as the 'subject' field in the device's 875 DevID credential, as specified by section 7.2.8 876 in IEEE Std 802.1AR-2009. 877 878 879 880 881 882 883 In order to process this Configlet, the device 884 MUST must be running this version of software. 885 The value is device-specific, but it MUST be 886 an exact match (e.g., 14.1R2.5) 887 888 889 890 891 892 893 894 895 896 The configuration to be committed to the device's 897 running datastore. The configuration MUST be valid 898 for the target device. 900 Devices supporting ZeroTouch SHOULD support the 901 following standard data-models: 903 ietf-system // RFC 7317 904 ietf-netconf-server // RFC YYYY 906 These two data models contain everything needed to 907 support NETCONF call home using either SSH or TLS. 909 References: 911 RFC 7317: A YANG Data Model for System Management 912 RFC YYYY: NETCONF Server Configuration Model 913 915 916 917 918 919 920 921 922 923 924 925 927 8. Security Considerations 929 8.1. Immutable storage for trust anchors 931 Devices SHOULD ensure that all its trust anchor certificates, 932 including those for the Configuration Signer and Configuration 933 Server, are protected from external modification. It is for this 934 reason that the diagram in Section 4.2 shows them in immutable 935 storage. 937 However, it may be necessary to update these certificates over time 938 (e.g., the vendor wants to delegate trust to a new CA). It is 939 therefore expected that devices MAY update these trust anchors when 940 needed through a verifiable process, such as a software upgrade using 941 signed software images. 943 8.2. Substitutions 945 It is generally not possible to substitute a Configlet created for a 946 different device, since devices assert that the Configlet contains 947 their unique identifier (e.g., serial number). 949 However, it is possible to substitute a Configlet created for a 950 device with a different Configlet created for the same device. 951 Generally, unless imposed by the Configuration Signers, there is no 952 limit to the number of Configlets that may be generated for a given 953 device. This could be resolved, in part, by placing a timestamp into 954 the Configlet and ensuring devices do not load Configlets older than 955 some amount, but this requires the devices have an accurate clock 956 when validating a Configlet and for Configuration Signers to not sign 957 a Configlet when another Configlet is still active. 959 8.3. Confidentiality 961 This draft allows devices to use insecure schemes when doing a 962 Configuration Server lookup. This is deemed acceptable because the 963 Configlet is tamper-proof, since it MUST be signed, only 964 confidentiality is lost. 966 Confidentiality of a Configlet's contents is assured when either the 967 Configlet is encrypted or when the a secure scheme is used when 968 accessing the Configuration Server. 970 Some confidentiality is lost when an insecure scheme is used to 971 access a Configuration Server, as then the device's unique identifier 972 is in the clear. 974 Given the fairly regular format for unique identifiers, it is 975 possible that an adversary to guess unique identifiers and access a 976 device's Configlet. Configlets that have been encrypted do not 977 disclose any confidential information. 979 8.4. Entropy loss over time 981 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 982 IDevID certificate should never expire (i.e. having a notAfter 983 99991231235959Z). Given the long-lived nature of these certificates, 984 it is paramount to use a strong key length (e.g., 512-bit ECC). 985 Vendors SHOULD deploy Online Certificate State Protocol (OCSP) 986 responders or CRL Distribution Points (CDP) to revoke certificates in 987 case necessary. 989 8.5. Serial Numbers 991 This draft mentions using the device's serial number as its unique 992 identifier in its IDevID certificate. This is because serial numbers 993 are ubiquitous and prominently contained in invoices and on labels 994 affixed to devices and their packaging. That said, serial numbers 995 many times encode revealing information, such as the device's model 996 number, manufacture date, and/or sequence number. Knowledge of this 997 information may provide an adversary with details needed to launch an 998 attack. To address this concern, the certificate could contain the 999 hash of the serial number instead, which the NMS could also compute, 1000 but doing so is much less intuitive and raises questions if it is 1001 just security through obscurity. 1003 9. IANA Considerations 1005 9.1. ZeroTouch Information DHCP Option 1007 The following registration is in accordance to RFC 2939 for "BOOTP 1008 Vendor Extensions and DHCP Options" registry maintained at 1009 http://www.iana.org/assignments/bootp-dhcp-parameters. 1011 9.1.1. DHCP v4 Option 1013 Tag: XXX 1015 Name: Zero Touch Information 1017 Description: Returns a list of null-terminated Configuration 1018 Server URIs 1020 Code Len 1021 +-----+-----+------+------+---- 1022 | XXX | n | url1 | url2 | ... 1023 +-----+-----+------+------+---- 1025 Reference: RFC XXXX 1027 9.1.2. DHCP v6 Option 1029 Tag: YYY 1031 Name: Zero Touch Information 1033 Description: Returns a list of null-terminated Configuration 1034 Server URIs 1036 Code Len 1037 +-----+-----+------+------+---- 1038 | YYY | n | url1 | url2 | ... 1039 +-----+-----+------+------+---- 1041 Reference: RFC XXXX 1043 9.2. Media Types for Boot Images and Configurations 1045 The following registrations are in accordance to RFC 6838. 1047 9.2.1. application/zerotouch-configlet 1049 Type name: application 1051 Subtype name: zerotouch-configlet 1053 Required parameters: None 1055 Optional parameters: None 1057 Encoding considerations: 8-bit 1059 Security considerations: See Security Considerations in RFC XXXX 1061 Interoperability considerations: None 1063 Published specification: RFC XXXX 1065 Applications that use this media type: 1067 Configuration servers and NETCONF servers. 1069 Fragment identifier considerations: None 1071 Additional information: 1073 Deprecated alias names for this type: N/A 1074 Magic number(s): None 1075 File extension(s): xml 1076 Macintosh file type code(s): 'TEXT' 1078 Person & email address to contact for further information: 1079 Kent Watsen 1081 Intended usage: COMMON 1083 Restrictions on usage: None 1085 Author: 1086 This specification is a work item of the IETF NETCONF working 1087 group, with mailing list address . 1089 Change controller: The IESG 1091 Provisional registration? (standards tree only): No 1093 9.2.2. application/zerotouch-bootimage 1095 Type name: application 1097 Subtype name: zerotouch-bootimage 1099 Required parameters: None 1101 Optional parameters: None 1103 Encoding considerations: binary 1105 Security considerations: See Security Considerations in RFC XXXX 1107 Interoperability considerations: None 1109 Published specification: RFC XXXX 1111 Applications that use this media type: 1113 Configuration servers and NETCONF servers. 1115 Fragment identifier considerations: None 1117 Additional information: 1119 Deprecated alias names for this type: N/A 1120 Magic number(s): None 1121 File extension(s): None 1122 Macintosh file type code(s): N/A 1124 Person & email address to contact for further information: 1125 Kent Watsen 1127 Intended usage: COMMON 1129 Restrictions on usage: None 1131 Author: 1132 This specification is a work item of the IETF NETCONF working 1133 group, with mailing list address . 1135 Change controller: The IESG 1137 Provisional registration? (standards tree only): No 1139 10. Acknowledgements 1141 The authors would like to thank for following for lively discussions 1142 on list and in the halls (ordered by last name): David Harrington, 1143 Dean Bogdanovic, Martin Bjorklund, Wes Hardaker, Russ Mundy, Reinaldo 1144 Penno, Randy Presuhn, Juergen Schoenwaelder. 1146 Special thanks goes to Russ Mundy and Wes Hardaker for brainstorming 1147 the original I-D's solution during the IETF 87 meeting in Berlin. 1149 11. References 1151 11.1. Normative References 1153 [NETCONF-CALL-HOME] 1154 Watsen, K., "NETCONF Call Home (work in progress)", 1155 October 2014, . 1158 [NETCONF-SERVER-MODEL] 1159 Watsen, K., "NETCONF Server Model (work in progress)", 1160 September 2014, . 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, March 1997. 1166 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 1167 Shell Authentication", RFC 6187, March 2011. 1169 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1170 System Management", RFC 7317, August 2014. 1172 [Std-802.1AR-2009] 1173 IEEE SA-Standards Board, "IEEE Standard for Local and 1174 metropolitan area networks - Secure Device Identity", 1175 December 2009, . 1178 [XMLENC] "XML Encryption Syntax and Processing", April 2013, 1179 . 1181 [XMLSIG] "XML Signature Syntax and Processing", April 2013, 1182 . 1184 11.2. Informative References 1186 [TR069] The Broadband Forum, , "TR-069 Amendment 3, CPE WAN 1187 Management Protocol", November 2010, 1188 . 1191 Appendix A. Examples 1193 A.1. Unsigned Configlet 1195 This example illustrates a Configlet configuring both a local user 1196 account and call home using SSH. Note, this is not a valid Configlet 1197 because it isn't signed. 1199 1200 1201 1202 0123456789 1203 14.1R3.5 1204 1205 1207 1208 1209 1210 1211 admin 1212 1213 admin's rsa ssh host-key 1214 ssh-rsa 1215 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1216 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1217 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1218 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1219 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1220 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1221 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1222 1223 1224 1225 1227 1228 1229 1230 1231 config-mgr 1232 1233 1234 1235 east-data-center 1236
11.22.33.44
1237 1238 1239 west-data-center 1240
55.66.77.88
1241 1242 1243 1244 my-call-home-x509-key 1245 1246 1247 1248 1249 1251 1252 1254 A.2. Signed Configlet 1256 This example illustrates the above unsigned Configlet signed as if by 1257 a Configuration Signer. Note that in addition to the signature 1258 itself, the signed Configlet embeds two certificates, the chain of 1259 certificates from the signer's certificate up to but not including 1260 the trust anchor certificate. 1262 1263 1264 1265 0123456789 1266 14.1R3.5 1267 1268 1270 1271 1272 1273 1274 admin 1275 1276 admin's rsa ssh host-key 1277 ssh-rsa 1278 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC 1279 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj 1280 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC 1281 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5 1282 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq 1283 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6 1284 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1285 1286 1288 1289 1291 1292 1293 1294 1295 config-mgr 1296 1297 1298 1299 east-data-center 1300
11.22.33.44
1301 1302 1303 west-data-center 1304
55.66.77.88
1305 1306 1307 1308 my-call-home-x509-key 1309 1310 1311 1312 1313 1315 1316 1317 1318 1320 1322 1323 1324 1326 1327 1329 t9OdNsxPsjyzrKu7kO0ydcFK6xU= 1330 1331 1332 1333 AS/dlRNk/DDy2baDfQXspstvQzOxZo/goZ+Z9iiW5dbOZ+wiZwxMlJuMYlxuNrfL 1334 o38JzJ+KnY1XexfRkFmSaaShyMJ0N9kianxaYWJgvF7+/lx5U6isFxpfIwvo9YkQ 1335 27w/i9xb5e/tl+PzVr+FMKyUuyitdy5yjVGpa3y8Gqlk7YSo4df4LWzmR4hAYWTN 1336 P7cuV516tHakKpyTi9FweBrqEUNT7W7BNb6Js0Q1twrEIR4lFwpQn/iWUM5KqxAu 1337 QzP7YG/d58oWzdILeCXZ2CX3RHhhtm/Brwa9UFN9TFS3D9WLIx1pO+L0HNt5gIiu 1338 eOMq1vN6sazkMtm6Z1NMqg== 1339 1340 1341 1342 1343 MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f 1344 VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1 1345 M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE 1346 AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1 1347 x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF 1348 wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH 1349 /gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW 1350 PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d 1351 x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX 1352 glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV 1353 HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6 1354 Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF 1355 BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50 1356 MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw 1357 CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2 1358 YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp 1359 Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG 1360 SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0 1361 cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw 1362 EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG 1363 A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p 1364 emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG 1365 SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h 1366 8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz 1367 rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d 1368 rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ 1369 HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI 1370 AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5 1371 1372 1373 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1374 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1375 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1376 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1377 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1378 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1379 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1380 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1381 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X 1382 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1383 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1384 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C 1385 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1386 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1387 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1388 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1389 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1390 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1391 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1392 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1393 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 1394 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K 1395 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y 1396 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo 1397 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 1398 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1399 1400 1401 1402 1403 1405 A.3. Encrypted Configlet 1407 This example illustrates the above unsigned Configlet that has been 1408 encrypted using the device's public key. Note, this is not a valid 1409 Configlet because it isn't signed. 1411 1412 1413 1415 1417 1418 1419 +H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs 1420 W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO 1421 yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU 1422 5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2 1423 WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u 1424 fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG 1425 a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf 1426 vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp 1427 xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k 1428 484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr 1429 6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6 1430 tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY 1431 C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc 1432 cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj 1433 UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE 1434 2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc 1435 OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu 1436 Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5 1437 urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf 1438 GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP 1439 KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF 1440 QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387 1441 HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3 1442 BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d 1443 M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B 1444 lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+ 1445 i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo 1446 MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE 1447 02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD 1448 G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG 1449 Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R 1450 Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK 1451 om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7 1452 lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk 1453 UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp 1454 ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf 1455 v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL 1456 5gk2DiSiffIpB/IJuTBQZQ== 1457 1458 1459 1460 1462 A.4. Signed Encrypted Configlet 1464 This example illstrates the above encrypted Configlet that has been 1465 signed by a Configuration Signer's private key. 1467 1468 1469 1471 1473 1474 1475 +H4vvrsgkv/qy22JudCE0quMORGamQmnQCaEhLJ7zY1UgP+zS5MbBdrREpocgHPs 1476 W/d9eyDOwdDsREvz2j7V0Vg6NkKuzPJTz2cJVvSoGskWAV0ZwoiwBJqabzxcYErO 1477 yV0DQmyxFruwmR5oalFBxkQzoL7zALfa2pBCpvdGuaoSRKTInQ/24iPOc/u+FNAU 1478 5l0CPKrTNMqPeRx8cGq44nVgcprNi0Fvbg72gAVl8aiYLNA9Vo62Tn5kvvmp/qK2 1479 WieLmBrJHQrvG6n3fg1RSM3cpR0KfsH3uaMEIaVUyzH0aYriwrhpaUPqdWCkel/u 1480 fTpKUZ3VtVzMtiFaDhgYOtbxeLXD8kj4TCG37G1Sro9iY46yxHkqPHiVUB9lvACG 1481 a5275yu0Z+zNfuCOUlvJtkI1CuSwOde+EOE+fzwyG9uPlacrhY3Xd7cIF9oDKFOf 1482 vKhYp/grnnpzR4MLU1tMz0HHyBm6xI2IU7sKDWztAF0JmYH//kPs3H4boFLXmzmp 1483 xr1eu5npsYpkhNpdflDLetMQZnqydzsmLSX8nfpkWZdkkXkmkKmuk6j1vkRiyw2k 1484 484K71J7096UfMP0t8VhH1ObM8gZLDKXboohnCQEzUAKLKXTm3OWw+QllfJj3cvr 1485 6GSWuKH+80CIUA10WAPNFMKO8VYFcSE68DMr+oXLk8zkXymWJR4ukWuMYa1Y14w6 1486 tx84NuueAYHQUcqzlN0dJaTmbPiFbBRmwRFI5dcLT6t8FK2LybmXvpziFv7StHvY 1487 C1Pr2S0W8lLwLoneaMRZsTNTd8bLzN2MlSuFdO8U6NMRvESH0WmNhF7JhGCzAegc 1488 cYwXNgs9Ae3CK+uihxqImY2evRpk1U915n+JMfaf/TRnpK0fIR3MNFbU0WZemMvj 1489 UYstRVCpAebJHq8L7IMbGjJesyT7vhd6CJIJCQL/4ZeWVp1W8ZPX6iKCpEhG+BhE 1490 2CIvkNu9F8ubpvpdOdvhSs2KABGGK3DF58wJR7CsS516UuqVz+Rl0WlvVjHL9yqc 1491 OvS1AP+NyQGfSLsGQ49tjxPSyE9uRV+dFbY7oCQlzPPdLRQ5H3htS/2CA6gCz0Cu 1492 Ez5uweFPIe8b1k7U0ai3IWTQzxe+LQlcL+MHSgXAKz6yKk3idfpK3JViDtqz8xa5 1493 urIYQDzOGntdjDfTdwG1+o4w/ysFI8zaCVUehL+L0T1pS0FuGwJpoyopg+6dA7rf 1494 GVhcy3OOroAfkAXvZfqZAKTuLCFrN5+vU09iGt7kp1GqeneiaAS75JgG8oAt4SAP 1495 KEIUquo5vxGe8WOXVpV8eByXWSpym/6wfYjwGIgzkIKz44LiqEUvL+Twz5qm3VaF 1496 QHsJVHid/GvcUnk1mfhGtDqHWSv6KhTL2tk1mJ4cJxDzy7ijy75FXoKsDlP7H387 1497 HnEQ/oFR9Xi52NYjylBvq/yuwhY16oGNFqqbq6uv90rdvSv5AJs7a0DxluqH/yd3 1498 BLan1HoRCD8/iuWB2bE74TzhbO30PxuQHWCQPa7zTxJ92/Yn402z1ODUjvhKta4d 1499 M2RTNOgIQwqcTi5qyUqhw+tKuXfQloQ1tIFI2VFwpLz9cEEImxDw+WGdb2bKfz5B 1500 lPJIEbswHr341JqLtejMKm8dvAqkzrmuhJb+tYx5BPHDp1EUjJmzydKs9Up9QcK+ 1501 i6pkmK/42jLws5jDAvBiJp6zyaeaSABrRdY06ON7wJ0RLlaAuqecMmW4ZX/rE4oo 1502 MIARa6SQ5JhV8Y7Z7/XWlids/GHfn9cYDIXIIadhz63a2s18qk3Ql8NAJ+CgkyiE 1503 02h4cCjlJ/e+tpyW83XdeqvGy9tdhRir/iZh6i7iRsAQTltq/yGiR7lWQqwzMtUD 1504 G994qckZ5PAZiKWHrB7/aWXTCDoHW1J546A5TsMcYGkIJR2UPOhFYWyOL1zCg6fG 1505 Ehv8pO+r3CfO4vldMY4Z6Uw7mCs9c/5nrgOz7wLPPILjRoUIJ7SzknJHzqPFjG+R 1506 Wqou6kQY6fy96Kax/iPGarfVbPJPhTJWWnxLD8NZWm8b12LViKJK6dAAl5REn3rK 1507 om+EQVfxo/uuiLP/YAwcLwq/apURH89dDtHMiA4fh4cEY0POqwTiLm3xD0+AIaj7 1508 lU7zbEIsKpz6HK5ex5dWsUADecIGBOyuQf//OO4E8vMO73NrSNiKA0mDPizzXCwk 1509 UhNK2DjEZalduWlv273wFSebHM1wIiisatQIxzhwsWFuTgQJRb7/JPZGsXEg6npp 1510 ePRShAqzrUAVOc7/flAvlNRLmOrdssqTZvmh2nFvyMeTHFoJ3BXbahxC+cNlvaWf 1511 v0ebL2Hk7m3cntAOjuIE0ejGkqbb/6APHgYqRGRVdTmPnYq/lwohnSHcrhGmYvkL 1512 5gk2DiSiffIpB/IJuTBQZQ== 1513 1514 1515 1516 1517 1518 1520 1522 1523 1524 1526 1527 1530 c7b+PFEoC9cVoQKKuLUQMhuHZik= 1531 1532 1533 1534 G0vUKL9FZYu7YIk88+wvHRRAFoKjdU7Mqp8CZvTSrKHTErjPGuJCMOUpvE9uCdpq 1535 5U8Y6LmpZxz7gUIFhWdSk0rpGpEsG7sRrrl64ZuSb4y0Z3lVVg/4CuaYpoLDGrNn 1536 JpupwKI4DlfexXt/a9TyIWvb3gjBuN+4wPc87nQRqkX6uwOP8Qh7sKpB8lGDrbTT 1537 AORhuzitJA9I3DI89he8IrLn6AF7YXYrE97RuP51eZ0/lIVn1M2fDQJtNqOs1poW 1538 mPf9+TDjgELOMKhW2GF/UNXvM+QP5lInFU8mHxV62qx4NVvmoABzj11P7WM/BEqm 1539 Lwlk1Qow470JH1xOyDeAuQ== 1540 1541 1542 1543 1544 MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f 1545 VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTE0MDIyNzE0MTM1 1546 M1oXDTE1MDIyNzE0MTM1M1owKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE 1547 AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1 1548 x0WiRICc5g+w0ILzTueLxlV+TIZhqeOe1hLHcBpJQd/OmX31rl8l+rgL1juu5BDF 1549 wkwl4EA4dZhjfuiiVChNkD4lks+464PreyjuWh+V+vgytdM84TRrXB1I+yTLrXuH 1550 /gZSKje67/5kWICAYAdRCkD8FnSdfXFtHE7blG6gYmAOHt1/g3N/UsjxOGPiUBFW 1551 PUvH4WYWVCgSup16ehb2SOBJGjE3FBjAOQLMlL4FiFSDB4nzNnsaRxZsHgftW87d 1552 x2d6lprLNIlmGDFRgELM/ItGsZFOpKyv3ftqdyC3rYaOz40I5i4NzP04vwfjcWxX 1553 glRvCjwY+T9MjOwGYpirAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV 1554 HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6 1555 Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF 1556 BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50 1557 MIHXBgNVHSMEgc8wgcyAFHppoyXFyh/JaftWYf7m3KBzOdg2oYGwpIGtMIGqMQsw 1558 CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2 1559 YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp 1560 Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG 1561 SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0 1562 cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw 1563 EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG 1564 A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p 1565 emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG 1566 SIb3DQEBCwUAA4IBAQCCKQLSng8OkgniJ4EpLnzUUGmFc8BDerVuaWv+kj1Zkk0h 1567 8leTPuNepWMiqAzdTjYVZYw4pzzSF/wYAKCVi1ng9ULlZS6wZAOL9exCF4bllvjz 1568 rBwDUX6gxKTq0o6jKf3qEUZLCJzwaX1LD4MW8yrWf6KR56gfUerQY2M6xmklA70d 1569 rY4u5+2F2sE6Vuh8N2aAo7HSaFMEVd5b399kC7nLMA8UJQ6S8OO+uPe9gYkqNgUJ 1570 HwsblCuekEeL1Gs/sZ25zGzD6Ofo097MsSYBGdPVbZbKUj9XUfIsUggY+1iAFyQI 1571 AuSxmTIAOISUbuxupPQPAU4nHOzEZediAoiNIGd5 1572 1573 1574 MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx 1575 EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE 1576 ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu 1577 Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh 1578 QGp1bmlwZXIuY29tMB4XDTE0MDIyNzE0MTM1MloXDTE1MDIyNzE0MTM1MlowMDET 1579 MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC 1580 ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANL5Mk5qFsVuqo+JmXWLmFxI 1581 RDEuRiZNRNLeJpgN9YWkXLAZX2rASwy041EMmZ6KAkWUd3ZmXucfoLpdRemfuPii 1582 ap1DgmS3IaYl/s4OOF8yzcYJprm8O7NyZp+Y9H1U/7Qfp97/KbqwCgkHSzOlnt0X 1583 KQTpIM/rNrbrkuTmalezFoFS7mrxLXJAsfP1guVcD7sLCyjvegL8pRCCrU9xyKLF 1584 8u/Qz4s0x0uzcGYh0sd3iWj21+AtigSLdMD76/j/VzftQL8B1yp3vc1EZiowOwq4 1585 KmORbiKU2GTGZkaCgCjmrWpvrYWLoXv/sf2nPLyK6YjiWsslOJtRO+KzRbs2B18C 1586 AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHppoyXF 1587 yh/JaftWYf7m3KBzOdg2MIHfBgNVHSMEgdcwgdSAFDSljCNmTN5b+CDujJLlyDal 1588 WFPaoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES 1589 MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w 1590 GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0 1591 X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQDUbsEdTn5v 1592 MjAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q 1593 dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B 1594 AQsFAAOCAQEAOuD7EBilqQcT3t2C4AXta1gGNNwdldLLw0jtk4BMiA9l//DZfskB 1595 2AaJtiseLTXsMF6MQwDs1YKkiXKLu7gBZDlJ6NiDwy1UnXhi2BDG+MYXQrc6p76K 1596 z3bsVwZlaJQCdF5sbggc1MyrsOu9QirnRZkIv3R8ndJH5K792ztLquulAcMfnK1Y 1597 NTOufhQsD2t4TYpEkzLEiZqSswdBOaPxPcJLQNW8Bw2xN+A9GX7WJzEbT/G7MUfo 1598 Sb+U2PVsQTDWEzUjVnG7vNWYxirnAOZ0OXEWWYxHUJntx6DsbXYuX7D1PkkNr7ir 1599 96DpOPtX7h8pxxGSDPBXIyvg02aFMphstQ== 1600 1601 1602 1603 1604 1606 Appendix B. Change Log 1608 B.1. ID to 00 1610 o Major structural update; the essence is the same. Most every 1611 section was rewritten to some degree. 1613 o Added a Use Cases section 1615 o Added diagrams for "Actors and Roles" and "NMS Precondition" 1616 sections, and greatly improved the "Device Boot Sequence" diagram 1618 o Removed support for physical presence or any ability for 1619 Configlets to not be signed. 1621 o Defined the ZeroTouch Information DHCP option 1623 o Added an ability for devices to also download images from 1624 Configuration Servers 1626 o Added an ability for Configlets to be encrypted 1628 o Now Configuration Servers only have to support HTTP/S - no other 1629 schemes possible 1631 B.2. 00 to 01 1633 o Added boot-image and validate-owner annotations to the "Actors and 1634 Roles" diagram. 1636 o Fixed 2nd paragrph in section 7.1 to reflect current use of 1637 anyxml. 1639 o Added encrypted and signed-encrypted examples 1641 o Replaced YANG module with XSD schema 1643 o Added IANA request for the ZeroTouch Information DHCP Option 1645 o Added IANA request for media types for boot-image and 1646 configuration 1648 Authors' Addresses 1650 Kent Watsen 1651 Juniper Networks 1653 EMail: kwatsen@juniper.net 1655 Stephen Hanna 1656 Juniper Networks 1658 EMail: shanna@juniper.net 1660 Joe Marcus Clarke 1661 Cisco Systems 1663 EMail: jclarke@cisco.com 1665 Mikael Abrahamsson 1666 T-Systems 1668 EMail: "mikael.abrahamsson@t-systems.se