idnits 2.17.1 draft-ietf-netconf-zerotouch-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 18 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 1856 has weird spacing: '...rmation pkc...' == Line 1861 has weird spacing: '...on-type enu...' == Line 1866 has weird spacing: '...ey-data str...' == Line 1870 has weird spacing: '...ificate pkc...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2591 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: 'RFC7468' is defined on line 2592, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-00 ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6234 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-01 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Abrahamsson 5 Expires: September 14, 2017 T-Systems 6 March 13, 2017 8 Zero Touch Provisioning for NETCONF or RESTCONF based Management 9 draft-ietf-netconf-zerotouch-13 11 Abstract 13 This draft presents a secure technique for establishing a NETCONF or 14 RESTCONF connection between a newly deployed device, configured with 15 just its factory default settings, and its deployment specific 16 network management system (NMS). 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. Please note 23 that no other RFC Editor instructions are specified anywhere else in 24 this document. 26 This document contains references to other drafts in progress, both 27 in the Normative References section, as well as in body text 28 throughout. Please update the following references to reflect their 29 final RFC assignments: 31 o I-D.ieft-netconf-netconf-client-server 33 o I-D.ietf-anima-bootstrapping-keyinfra 35 Artwork in this document contains shorthand references to drafts in 36 progress. Please apply the following replacements: 38 o "XXXX" --> the assigned RFC value for this draft 40 Artwork in this document contains placeholder values for the date of 41 publication of this draft. Please apply the following replacement: 43 o "2017-03-13" --> the publication date of this draft 45 The following one Appendix section is to be removed prior to 46 publication: 48 o Appendix A. Change Log 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on September 14, 2017. 67 Copyright Notice 69 Copyright (c) 2017 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 87 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 88 1.4. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 6 89 2. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 7 90 2.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 7 91 2.2. Conveying Trust . . . . . . . . . . . . . . . . . . . . . 7 92 2.3. Conveying Ownership . . . . . . . . . . . . . . . . . . . 8 93 3. Types of Zero Touch Information . . . . . . . . . . . . . . . 8 94 3.1. Redirect Information . . . . . . . . . . . . . . . . . . 8 95 3.2. Bootstrap Information . . . . . . . . . . . . . . . . . . 9 96 4. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10 97 4.1. Zero Touch Information . . . . . . . . . . . . . . . . . 10 98 4.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 11 99 4.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 12 100 5. Artifact Groupings . . . . . . . . . . . . . . . . . . . . . 12 101 5.1. Unsigned Information . . . . . . . . . . . . . . . . . . 12 102 5.2. Signed Information (without Revocations) . . . . . . . . 13 103 5.3. Signed Information (with Revocations) . . . . . . . . . . 13 104 6. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 14 105 6.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 14 106 6.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 15 107 6.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 16 108 6.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 17 109 7. Workflow Overview . . . . . . . . . . . . . . . . . . . . . . 18 110 7.1. Onboarding and Ordering Devices . . . . . . . . . . . . . 19 111 7.2. Owner Stages the Network for Bootstrap . . . . . . . . . 21 112 7.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 23 113 8. Device Details . . . . . . . . . . . . . . . . . . . . . . . 25 114 8.1. Factory Default State . . . . . . . . . . . . . . . . . . 25 115 8.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 26 116 8.3. Processing a Source of Bootstrapping Data . . . . . . . . 27 117 8.4. Validating Signed Data . . . . . . . . . . . . . . . . . 28 118 8.5. Processing Redirect Information . . . . . . . . . . . . . 29 119 8.6. Processing Bootstrap Information . . . . . . . . . . . . 30 120 9. The Zero Touch Information Artifact . . . . . . . . . . . . . 31 121 9.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 31 122 9.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 31 123 9.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 34 124 10. The Zero Touch Bootstrap Server API . . . . . . . . . . . . . 39 125 10.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 39 126 10.2. Example Usage . . . . . . . . . . . . . . . . . . . . . 40 127 10.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . 43 128 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 129 11.1. Immutable storage for trust anchors . . . . . . . . . . 51 130 11.2. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 51 131 11.3. Blindly authenticating a bootstrap server . . . . . . . 51 132 11.4. Entropy loss over time . . . . . . . . . . . . . . . . . 52 133 11.5. Serial Numbers . . . . . . . . . . . . . . . . . . . . . 52 134 11.6. Sequencing Sources of Bootstrapping Data . . . . . . . . 52 135 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 136 12.1. The BOOTP Manufacturer Extensions and DHCP Options 137 Registry . . . . . . . . . . . . . . . . . . . . . . . . 52 138 12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 53 139 12.3. The YANG Module Names Registry . . . . . . . . . . . . . 54 140 13. Other Considerations . . . . . . . . . . . . . . . . . . . . 54 141 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 143 15.1. Normative References . . . . . . . . . . . . . . . . . . 54 144 15.2. Informative References . . . . . . . . . . . . . . . . . 56 145 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 58 146 A.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 58 147 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 58 148 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 58 149 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 59 150 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 59 151 A.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 59 152 A.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 60 153 A.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 60 154 A.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 60 155 A.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 60 156 A.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 60 157 A.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 61 158 A.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 61 159 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 61 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 162 1. Introduction 164 A fundamental business requirement for any network operator is to 165 reduce costs where possible. For network operators, deploying 166 devices to many locations can be a significant cost, as sending 167 trained specialists to each site to do installations is both cost 168 prohibitive and does not scale. 170 This document defines a bootstrapping strategy enabling devices to 171 securely obtain bootstrapping data with no installer input, beyond 172 physical placement and connecting network and power cables. The 173 ultimate goal of this document is to enable a secure NETCONF 174 [RFC6241] or RESTCONF [RFC8040] connection to the deployment specific 175 network management system (NMS). 177 1.1. Use Cases 179 o Device connecting to a remotely administered network 181 This use-case involves scenarios, such as a remote branch 182 office or convenience store, whereby a device connects as an 183 access gateway to an ISP's network. Assuming it is not 184 possible to customize the ISP's network to provide any 185 bootstrapping support, and with no other nearby device to 186 leverage, the device has no recourse but to reach out to an 187 Internet-based bootstrap server to bootstrap off of. 189 o Device connecting to a locally administered network 191 This use-case covers all other scenarios and differs only in 192 that the device may additionally leverage nearby devices, which 193 may direct it to use a local service to bootstrap off of. If 194 no such information is available, or the device is unable to 195 use the information provided, it can then reach out to network 196 just as it would for the remotely administered network use- 197 case. 199 1.2. Terminology 201 This document uses the following terms: 203 Artifact: The term "artifact" is used throughout to represent the 204 any of the three artifacts defined in Section 4. These artifacts 205 collectively provide all the bootstrapping data a device needs. 207 Bootstrapping Data: The term "bootstrapping data" is used throughout 208 this document to refer to the collection of data that a device 209 may obtain from any source of bootstrapping data. Specifically, 210 it refers to the artifacts defined in Section 4. 212 Bootstrap Information: The term "bootstrap information" is used 213 herein to refer to one of the bootstrapping artifacts defined in 214 Section 4. Specifically, bootstrap information is the 215 bootstrapping data that guides a device to, for instance, install 216 a specific boot-image and commit a specific configuration. 218 Bootstrap Server: The term "bootstrap server" is used within this 219 document to mean any RESTCONF server implementing the YANG module 220 defined in Section 10.3. 222 Device: The term "device" is used throughout this document to refer 223 to the network element that needs to be bootstrapped. See 224 Section 8 for more information about devices. 226 Initial Secure Device Identifier (IDevID): The term "IDevID" is 227 defined in [Std-802.1AR-2009] as the secure device identifier 228 (DevID) installed on the device by the manufacturer. This 229 identifier is used in this document to enable a Bootstrap Server 230 to securely identify and authenticate a device. 232 Manufacturer: The term "manufacturer is used herein to refer to the 233 manufacturer of a device or a delegate of the manufacturer. 235 Network Management System (NMS): The acronym "NMS" is used 236 throughout this document to refer to the deployment specific 237 management system that the bootstrapping process is responsible 238 for introducing devices to. From a device's perspective, when 239 the bootstrapping process has completed, the NMS is a NETCONF or 240 RESTCONF client. 242 Owner: See Rightful Owner. 244 Redirect Information: The term "bootstrap information" is used 245 herein to refer to one of the bootstrapping artifacts defined in 246 Section 4. Specifically, redirect information is the 247 bootstrapping data that directs a device to connect to a 248 bootstrap server. 250 Redirect Server: The term "redirect server" is used to refer to a 251 subset of bootstrap servers that only returns redirect 252 information. A redirect server is particularly useful when 253 hosted by a manufacturer, to redirect devices to deployment- 254 specific bootstrap servers. 256 Rightful Owner: The term "rightful owner" is used herein to refer to 257 the person or organization that purchased or otherwise owns a 258 device. Ownership is further described in Section 2.3. 260 Signed Data: The term "signed data" is used throughout to mean 261 either redirect information or bootstrap information that has 262 been signed by a device's rightful owner's private key. 264 Unsigned Data: The term "unsigned data" is used throughout to mean 265 either redirect information or bootstrap information that has not 266 been signed by a device's rightful owner's private key. 268 1.3. Requirements Language 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 272 sections below are to be interpreted as described in RFC 2119 273 [RFC2119]. 275 1.4. Tree Diagram Notation 277 A simplified graphical representation of the data models is used in 278 this document. The meaning of the symbols in these diagrams is as 279 follows: 281 o Brackets "[" and "]" enclose list keys. 283 o Braces "{" and "}" enclose feature names, and indicate that the 284 named feature must be present for the subtree to be present. 286 o Abbreviations before data node names: "rw" (read-write) represents 287 configuration data and "ro" (read-only) represents state data. 289 o Symbols after data node names: "?" means an optional node, "!" 290 means a presence container, and "*" denotes a list and leaf-list. 292 o Parentheses enclose choice and case nodes, and case nodes are also 293 marked with a colon (":"). 295 o Ellipsis ("...") stands for contents of subtrees that are not 296 shown. 298 2. Guiding Principles 300 This section provides overarching principles guiding the solution 301 presented in this document. 303 2.1. Trust Anchors 305 A trust anchor is used in cryptography to represent an entity in 306 which trust is implicit and not derived. In public key 307 infrastructure using X.509 certificates, a root certificate is the 308 trust anchor, from which a chain of trust is derived. The solution 309 presented in this document requires that all the entities involved 310 (e.g., devices, bootstrap servers, NMSs) possess specific trust 311 anchors in order to ensure mutual authentication throughout the zero 312 touch bootstrapping process. 314 2.2. Conveying Trust 316 A device in its factory default state possesses a limited set of 317 manufacturer specified trust anchors. In this document, there are 318 two types of trust anchors of interest. The first type of trust 319 anchor is used to authenticate a secure (e.g., HTTPS) connection to, 320 for instance, a manufacturer-hosted Internet-based bootstrap server. 321 The second type of trust anchor is used to authenticate manufacturer- 322 signed data, such as the ownership voucher artifact described in 323 Section 4.3. 325 Using the first type of trust anchor, trust is conveyed by the device 326 first authenticating the server (e.g., a bootstrap server), and then 327 by the device trusting that the server would only provide data that 328 its rightful owner staged for it to find. Thereby the device can 329 trust any information returned from the server. 331 Using the second type of trust anchor, trust is conveyed by the 332 device first authenticating that an artifact has been signed by its 333 rightful owner, and thereby can trust any information held within the 334 artifact. 336 Notably, redirect information, as described in Section 3.1, may 337 include more trust anchors, which illustrates another way in which 338 trust can be conveyed. 340 2.3. Conveying Ownership 342 The ultimate goal of this document is to enable a device to establish 343 a secure connection with its rightful owner's NMS. This entails the 344 manufacturer being able to track who is the rightful owner of a 345 device (not defined in this document), as well as an ability to 346 convey that information to devices (defined in this document). 348 Matching the two ways to convey trust (Section 2.2), this document 349 provides two ways to convey ownership, by using a trusted bootstrap 350 server (Section 6.4) or by using an ownership voucher (Section 4.3). 352 When a device connects to a trusted bootstrap server, one that was 353 preconfigured into its factory default configuration, it implicitly 354 trusts that the bootstrap server would only provide data that its 355 rightful owner staged for it to find. That is, ownership is conveyed 356 by the administrator of the bootstrap server (e.g., a manufacturer) 357 taking the onus of ensuring that only data configured by a device's 358 rightful owner is made available to the device. With this approach, 359 the assignment of a device to an owner is ephemeral, as the 360 administrator can reassign a device to another owner at any time. 362 When a device is presented signed bootstrapping data, it can 363 authenticate that its rightful owner provided the data by verifying 364 the signature over the data using an additional artifact defined 365 within this document, the ownership voucher. With this approach, 366 ownership is conveyed by the manufacturer (or delegate) taking the 367 onus of ensuring that the ownership vouchers it issues are accurate. 369 3. Types of Zero Touch Information 371 This document defines two types of information that devices access 372 during the bootstrapping process. These information types are 373 described in this section. 375 3.1. Redirect Information 377 Redirect information provides information to redirect a device to a 378 bootstrap server. Redirect information encodes a list of bootstrap 379 servers, each defined by its hostname or IP address, an optional 380 port, and an optional trust anchor certificate. 382 Redirect information is YANG modeled data formally defined by the 383 "redirect-information" grouping in the YANG module presented in 384 Section 9.3. This grouping has the tree diagram shown below. Please 385 see Section 1.4 for tree diagram notation. 387 +--:(redirect-information) 388 +--ro redirect-information 389 +--ro bootstrap-server* [address] 390 +--ro address inet:host 391 +--ro port? inet:port-number 392 +--ro trust-anchor? binary 394 Redirect information MAY be trusted or untrusted. The redirect 395 information is trusted whenever it is obtained via a secure 396 connection to a trusted bootstrap server, or whenever it is signed by 397 the device's rightful owner. In all other cases, the redirect 398 information is untrusted. 400 Trusted redirect information is useful for enabling a device to 401 establish a secure connection to a bootstrap server, which is 402 possible when the redirect information includes the bootstrap 403 server's trust anchor certificate. When a device is able to 404 establish a secure connection to a bootstrap server, the 405 bootstrapping data does not have to be signed in order to be trusted, 406 as described in Section 2.2. 408 Untrusted redirect information is useful for directing a device to a 409 bootstrap server where signed data has been staged for it to obtain. 410 When the redirect information is untrusted, the device MUST discard 411 any potentially included trust anchor certificates. When the 412 redirect information is untrusted, a device MAY establish a 413 provisional connection to any of the specified bootstrap servers. A 414 provisional connection is accomplished by the device blindly 415 accepting the bootstrap server's TLS certificate. In this case, the 416 device MUST NOT trust the bootstrap server, and data provided by the 417 bootstrap server MUST be signed for it to be of any use to the 418 device. 420 How devices process redirect information is described more formally 421 in Section 8.5. 423 3.2. Bootstrap Information 425 Bootstrap information provides all the data necessary for a device to 426 bootstrap itself, in order to be considered ready to be managed 427 (e.g., by an NMS). As defined in this document, this data includes 428 information about a boot image the device MUST be running, an initial 429 configuration the device MUST commit, and optional scripts that, if 430 specified, the device MUST successfully execute. 432 Bootstrap information is YANG modeled data formally defined by the 433 "bootstrap-information" grouping in the YANG module presented in 434 Section 9.3. This grouping has the tree diagram shown below. Please 435 see Section 1.4 for tree diagram notation. 437 +--:(bootstrap-information) 438 +--ro bootstrap-information 439 +--ro boot-image 440 | +--ro name string 441 | +--ro (hash-algorithm) 442 | | +--:(sha256) 443 | | +--ro sha256? string 444 | +--ro uri* inet:uri 445 +--ro configuration-handling enumeration 446 +--ro pre-configuration-script? script 447 +--ro configuration? 448 +--ro post-configuration-script? script 450 Bootstrap information MUST be trusted for it to be of any use to a 451 device. There is no option for a device to process untrusted 452 bootstrap information. 454 Bootstrap information is trusted whenever it is obtained via a secure 455 connection to a trusted bootstrap server, or whenever it is signed by 456 the device's rightful owner. In all other cases, the bootstrap 457 information is untrusted. 459 How devices process bootstrap information is described more formally 460 in Section 8.6. 462 4. Artifacts 464 This document defines three artifacts that can be made available to 465 devices while they are bootstrapping. As will be seen in Section 6, 466 each source of bootstrapping information specifies a means for 467 providing each of the artifacts defined in this section. 469 4.1. Zero Touch Information 471 The information artifact encodes the essential bootstrapping data for 472 the device. This artifact is used to encode the redirect information 473 and bootstrap information types discussed in Section 3. 475 The information artifact is a PKCS#7 SignedData structure, as 476 specified by Section 9.1 of [RFC2315], encoded using ASN.1 477 distinguished encoding rules (DER), as specified in ITU-T X.690. 479 Regardless how the information artifact is conveyed, the PKCS#7 480 structure MUST contain JSON-encoded content conforming to the YANG 481 module specified in Section 9.3. 483 When the information artifact is conveyed over an untrusted transport 484 (Section 2.2), the PKCS#7 structure structure MUST also contain a 485 'signerInfo' structure, as described in Section 9.1 of [RFC2315], 486 containing a signature generated over the content using the private 487 key associated with the owner certificate (Section 4.2). 489 4.2. Owner Certificate 491 The owner certificate artifact is a certificate that is used to 492 identify an 'owner' (e.g., an organization), as known to a trusted 493 certificate authority. The owner certificate is signed by a trusted 494 certificate authority (CA), whose certificate is placed into the 495 ownership voucher (Section 4.3). 497 The owner certificate is used by a device to verify the signature 498 attached to the information artifact (Section 4.1) that the device 499 SHOULD have also received, as described in Section 5. In particular, 500 the device verifies signature using the public key in the owner 501 certificate over the content contained within the information 502 artifact. 504 In order to validate the owner certificate, a device MUST verify that 505 the owner certificate's certificate chain includes the certificate 506 specified by the ownership voucher (Section 4.3) that the device 507 SHOULD have also received, as described in Section 5, and the device 508 MUST verify that owner certificate contains an identifier matching 509 the one specified in the voucher and, for devices that insist on 510 verifying certificate revocation status, the device MUST verify that 511 the certificate has neither expired nor been revoked. 513 The owner certificate artifact is formally an unsigned PKCS #7 514 SignedData structure as specified by Section 9.1 in [RFC2315], 515 encoded using ASN.1 distinguished encoding rules (DER), as specified 516 in ITU-T X.690. 518 The owner certificate artifact MUST contain the owner certificate 519 itself and all intermediate certificates leading up to the trust 520 anchor certificate specified in the ownership voucher. The owner 521 certificate artifact MAY optionally include the trust anchor 522 certificate. 524 Additionally, if needed by the device, the owner certificate artifact 525 MAY also contain suitably fresh CRLs [RFC5280] and/or OCSP Responses 526 [RFC6960]. 528 4.3. Ownership Voucher 530 The ownership voucher artifact is used to securely identify a 531 device's owner, as it is known to the manufacturer. The ownership 532 voucher is signed by the device's manufacturer or delegate. 534 The ownership voucher is used by a device to verify the owner 535 certificate (Section 4.2) that the device SHOULD have also received, 536 as described in Section 5. In particular, the device verifies that 537 the owner certificate's chain of trust includes the trusted 538 certificate included in the voucher, and the device also verifies 539 that the owner certificate contains an identifier matching the one 540 specified in the voucher. 542 In order to validate the voucher, a device MUST verify that the 543 voucher was signed by the private key associated with a trusted 544 certificate known to the device in its factory default state, as 545 described in Section 8.1, and the device MUST verify that the voucher 546 includes the device's unique identifier (e.g., serial number) and, if 547 the voucher contains an expiration date, the device MUST also verify 548 that the voucher has not expired. 550 The ownership voucher artifact, including its encoding, is formally 551 defined in [I-D.ietf-anima-voucher]. 553 5. Artifact Groupings 555 Section 4 lists all the possible bootstrapping artifacts, but only 556 certain groupings of these artifacts make sense to return in the 557 various bootstrapping situations described in this document. The 558 remainder of this section identifies these groupings to further 559 clarify how the artifacts are used. 561 5.1. Unsigned Information 563 The first grouping of artifacts is for unsigned information. That 564 is, when the information artifact (Section 4.1) has not been signed. 566 Unsigned information is useful for cases when transport level 567 security can be used to convey trust (e.g., HTTPS), or when the 568 information can be processed in a provisional manner (i.e. unsigned 569 redirect information). 571 Conveying unsigned information entails communicating just one of the 572 three artifacts listed in Section 4 as follows: 574 List of artifacts included in this grouping: 575 - zero touch information (with no embedded signature) 577 5.2. Signed Information (without Revocations) 579 The second grouping of artifacts is for when the information artifact 580 (Section 4.1) has been signed, without any revocation information. 582 Signed information is needed when the information is obtained from an 583 untrusted source of bootstrapping data (Section 6) and yet it is 584 desired that the device be able to trust the information (i.e. no 585 provisional processing). 587 Revocation information may not need to be provided because, for 588 instance, the device only uses revocation information obtained 589 dynamically from Internet based resources. Another possible reason 590 may be because the device does not have a reliable clock, and 591 therefore the manufacturer decides to never revoke information (e.g., 592 ownership assignments are forever). 594 Conveying signed information without revocation information entails 595 communicating all three of the artifacts listed in Section 4 as 596 follows: 598 List of artifacts included in this grouping: 599 - zero touch information (with an embedded signature) 600 - owner certificate (with no revocation structures) 601 - ownership voucher 603 5.3. Signed Information (with Revocations) 605 The third grouping of artifacts is for when the information artifact 606 (Section 4.1) has been signed and also includes revocation 607 information. 609 Signed information, as described above, is needed when the 610 information is obtained from an untrusted source of bootstrapping 611 data (Section 6) and yet it is desired that the device be able to 612 trust the information (i.e. no provisional processing). 614 Revocation information may need to be provided because, for instance, 615 the device insists on being able to verify revocations and the device 616 is deployed on a private network and therefore unable to obtain the 617 revocation information from Internet based resources. 619 Conveying signed information with revocation information entails 620 communicating all three of the artifacts listed in Section 4 as 621 follows: 623 List of artifacts included in this grouping: 624 - zero touch information (with an embedded signature) 625 - owner certificate (with revocation structures) 626 - ownership voucher 628 6. Sources of Bootstrapping Data 630 This section defines some sources for zero touch bootstrapping data 631 that a device can access. The list of sources defined here is not 632 meant to be exhaustive. It is left to future documents to define 633 additional sources for obtaining zero touch bootstrapping data. 635 For each source defined in this section, details are given for how 636 each of the three artifacts listed in Section 4 is provided. 638 6.1. Removable Storage 640 A directly attached removable storage device (e.g., a USB flash 641 drive) MAY be used as a source of zero touch bootstrapping data. 643 To use a removable storage device as a source of bootstrapping data, 644 a device need only detect if the removable storage device is plugged 645 in and mount its filesystem. 647 Use of a removable storage device is compelling, as it doesn't 648 require any external infrastructure to work. It is also compelling 649 that the raw boot image file can be located on the removable storage 650 device, enabling a removable storage device to be a fully self- 651 standing bootstrapping solution. 653 A removable storage device is an untrusted source of bootstrapping 654 data. This means that the information stored on the removable 655 storage device either MUST be signed, or it MUST be information that 656 can be processed provisionally (e.g., unsigned redirect information). 658 From an artifact perspective, since a removable storage device 659 presents itself as a filesystem, the bootstrapping artifacts need to 660 be presented as files. The three artifacts defined in Section 4 are 661 mapped to files below. 663 Artifact to File Mapping: 665 Information: Mapped to a file containing the binary artifact 666 described in Section 4.1. 668 Owner Certificate: Mapped to a file containing the binary 669 artifact described in Section 4.2. 671 Ownership Voucher: Mapped to a file containing the binary 672 artifact described in Section 4.3. 674 The format of the removable storage device's filesystem and the 675 naming of the files are outside the scope of this document. However, 676 in order to facilitate interoperability, it is RECOMMENDED devices 677 support open and/or standards based filesystems. It is also 678 RECOMMENDED that devices assume a file naming convention that enables 679 more than one instance of bootstrapping data to exist on a removable 680 storage device. The file naming convention SHOULD be unique to the 681 manufacturer, in order to enable bootstrapping data from multiple 682 manufacturers to exist on a removable storage device. 684 6.2. DNS Server 686 A DNS server MAY be used as a source of zero touch bootstrapping 687 data. 689 Using a DNS server may be a compelling option for deployments having 690 existing DNS infrastructure, as it enables a touchless bootstrapping 691 option that does not entail utilizing an Internet based resource 692 hosted by a 3rd-party. 694 To use a DNS server as a source of bootstrapping data, a device MAY 695 perform a multicast DNS [RFC6762] query searching for the service 696 "_zerotouch._tcp.local.". Alternatively the device MAY perform DNS- 697 SD [RFC6763] via normal DNS operation, using the domain returned to 698 it from the DHCP server; for example, searching for the service 699 "_zerotouch._tcp.example.com". 701 Unsigned DNS records (not using DNSSEC as described in [RFC6698]) are 702 an untrusted source of bootstrapping data. This means that the 703 information stored in the DNS records either MUST be signed, or it 704 MUST be information that can be processed provisionally (e.g., 705 unsigned redirect information). 707 From an artifact perspective, since a DNS server presents resource 708 records (Section 3.2.1 of [RFC1035]), the bootstrapping artifacts 709 need to be presented as resource records. The three artifacts 710 defined in Section 4 are mapped to resource records below. 712 Artifact to Resource Record Mapping: 714 Information: Mapped to a TXT record called "zt-info" containing 715 the base64-encoding of the binary artifact described in 716 Section 4.1. 718 Owner Certificate: Mapped to a TXT record called "zt-cert" 719 containing the base64-encoding of the binary artifact described 720 in Section 4.2. 722 Ownership Voucher: Mapped to a TXT record called "zt-voucher" 723 containing the base64-encoding of the binary artifact described 724 in Section 4.3. 726 TXT records have an upper size limit of 65535 bytes (Section 3.2.1 in 727 RFC1035), since 'RDLENGTH' is a 16-bit field. Please see 728 Section 3.1.3 in RFC4408 for how a TXT record can achieve this size. 729 Due to this size limitation, some information artifacts may not fit. 730 In particular, the bootstrap information artifact could hit this 731 upper bound, depending on the size of the included configuration and 732 scripts. 734 When bootstrap information is provided, it is notable that the URL 735 for the boot-image the device can download would have to point to 736 another server (e.g., http://, ftp://, etc.), as DNS servers do not 737 themselves distribute files. 739 6.3. DHCP Server 741 A DHCP server MAY be used as a source of zero touch bootstrapping 742 data. 744 To use a DHCP server as a source of bootstrapping data, a device need 745 only send a DHCP lease request to a DHCP server. However, the device 746 SHOULD pass the Vendor Class Identifier (option 60) field in its DHCP 747 lease request, so the DHCP server can return bootstrap information 748 shared by devices from the same vendor. However, if it is desired to 749 return device-specific bootstrap information, then the device SHOULD 750 also send the Client Identifier (option 61) field in its DHCP lease 751 request, so the DHCP server can select the specific bootstrap 752 information that has been staged for that one device. 754 Using a DHCP server may be a compelling option for deployments having 755 existing DHCP infrastructure, as it enables a touchless bootstrapping 756 option that does not entail utilizing an Internet based resource 757 hosted by a 3rd-party. 759 A DHCP server is an untrusted source of bootstrapping data. This 760 means that the information returned by the DHCP server either MUST be 761 signed, or it MUST be information that can be processed provisionally 762 (e.g., unsigned redirect information). 764 From an artifact perspective, since a DHCP server presents data as 765 DHCP options , the bootstrapping artifacts need to be presented as 766 DHCP options, specifically the ones specified in Section 12.1. The 767 three artifacts defined in Section 4 are mapped to the DHCP options 768 specified in Section 12.1 below. 770 Artifact to DHCP Option Field Mapping: 772 Information: Mapped to the DHCP option field "zerotouch- 773 information" containing the binary artifact described in 774 Section 4.1. 776 Owner Certificate: Mapped to the DHCP option field "owner- 777 certificate" containing the binary artifact described in 778 Section 4.2. 780 Ownership Voucher: Mapped to the DHCP option field "ownership- 781 voucher" containing the binary artifact described in 782 Section 4.3. 784 When bootstrap information is provided, it is notable that the URL 785 for the boot-image the device can download would have to point to 786 another server (e.g., http://, ftp://, etc.), as DHCP servers do not 787 themselves distribute files. 789 6.4. Bootstrap Server 791 A bootstrap server MAY be used as a source of zero touch 792 bootstrapping data. A bootstrap server is defined as a RESTCONF 793 [RFC8040] server implementing the YANG module provided in Section 10. 795 Unlike any other source of bootstrap data described in this document, 796 a bootstrap server is not only a source of data, but it can also 797 receive data from devices using the YANG-defined "notification" 798 action statement defined in the YANG module (Section 10.3). The data 799 sent from devices both enables visibility into the bootstrapping 800 process (e.g., warnings and errors) as well as provides potentially 801 useful completion status information (e.g., the device's SSH host- 802 keys). 804 To use a bootstrap server as a source of bootstrapping data, a device 805 MUST use the RESTCONF protocol to access the YANG container node 806 /device/, passing its own serial number in the URL as the key to the 807 'device' list. 809 Using a bootstrap server as a source of bootstrapping data is a 810 compelling option as it uses transport-level security in lieu of 811 signed data, which may be easier to deploy in some situations. 812 Additionally, the bootstrap server is able to receive notifications 813 from devices, which may be critical to some deployments (e.g., the 814 passing of the device's SSH host keys). 816 A bootstrap server may be trusted or an untrusted source of 817 bootstrapping data, depending on how the device learned about the 818 bootstrap server's trust anchor from a trusted source. When a 819 bootstrap server is trusted, the information returned from it MAY be 820 signed. However, when the server is untrusted, in order for its 821 information to be of any use to the device, the information MUST 822 either be signed or be information that can be processed 823 provisionally (e.g., unsigned redirect information). 825 When a device is able to trust a bootstrap server, it MUST send its 826 IDevID certificate in the form of a TLS client certificate, and it 827 MUST send notifications to the bootstrap server. When a device is 828 not able to trust a bootstrap server, it MUST NOT send its IDevID 829 certificate in the form of a TLS client certificate, and it MUST NOT 830 send any notifications to the bootstrap server. 832 From an artifact perspective, since a bootstrap server presents data 833 as a YANG-modeled data, the bootstrapping artifacts need to be mapped 834 to nodes in the YANG module. The three artifacts defined in 835 Section 4 are mapped to bootstrap server nodes defined in 836 Section 10.3 below. 838 Artifact to Bootstrap Server Node Mapping: 840 Information: Mapped to the node /device/zerotouch-information. 842 Owner Certificate: Mapped to the leaf node /device/owner- 843 certificate. 845 Ownership Voucher: Mapped to the leaf node /device/ownership- 846 voucher. 848 While RESTCONF servers typically support a nested hierarchy of 849 resources, zero touch bootstrap servers only need to support the 850 paths /device and /device/notification. The device processing 851 instructions provided in Section 8.3 only uses these two URLs. 853 7. Workflow Overview 855 The zero touch solution presented in this document is conceptualized 856 to be composed of the workflows described in this section. 857 Implementations MAY vary in details. Each diagram is followed by a 858 detailed description of the steps presented in the diagram, with 859 further explanation on how implementations may vary. 861 7.1. Onboarding and Ordering Devices 863 The following diagram illustrates key interactions that may occur 864 from when a prospective owner enrolls in a manufacturer's zero touch 865 program to when the manufacturer ships devices for an order placed by 866 the prospective owner. 868 +-----------+ 869 +------------+ |Prospective| +---+ 870 |Manufacturer| | Owner | |NMS| 871 +------------+ +-----------+ +---+ 872 | | | 873 | | | 874 | 1. initiate enrollment | | 875 #<-----------------------------| | 876 # | | 877 # | | 878 # IDevID trust anchor | | 879 #-----------------------------># set IDevID trust anchor | 880 # #--------------------------->| 881 # | | 882 # bootstrap server | | 883 # account credentials | | 884 #-----------------------------># set credentials | 885 # #--------------------------->| 886 # | | 887 # | | 888 # owner certificate | | 889 #-----------------------------># set certificate | 890 | #--------------------------->| 891 | | | 892 | | | 893 | 2. place device order | | 894 |<-----------------------------# model devices | 895 | #--------------------------->| 896 | | | 897 | 3. ship devices and send | | 898 | device identifiers and | | 899 | ownership vouchers | | 900 |-----------------------------># set device identifiers | 901 | # and ownership vouchers | 902 | #--------------------------->| 903 | | | 905 Each numbered item below corresponds to a numbered item in the 906 diagram above. 908 1. A prospective owner of a manufacturer's devices, or an existing 909 owner that wishes to start using zero touch for future device 910 orders, initiates an enrollment process with the manufacturer or 911 delegate. This process includes the following: 913 * Regardless how the prospective owner intends to bootstrap 914 their devices, they will always obtain from the manufacturer 915 or delegate the trust anchor certificate for its device's 916 IDevID certificates. This certificate will need to be 917 installed on the prospective owner's NMS so that the NMS can 918 subsequently authenticate the device's IDevID certificates. 920 * If the manufacturer hosts an Internet based bootstrap server 921 (e.g., a redirect server) such as described in Section 6.4, 922 then credentials necessary to configure the bootstrap server 923 would be provided to the prospective owner. If the bootstrap 924 server is configurable through an API (outside the scope of 925 this document), then the credentials might be installed on the 926 prospective owner's NMS so that the NMS can subsequently 927 configure the manufacturer-hosted bootstrap server directly. 929 * If the manufacturer's devices are able to validate signed data 930 (Section 8.4), then the manufacturer, acting as a certificate 931 authority, may additionally sign an owner certificate for the 932 prospective owner. Alternatively, and not depicted, the owner 933 may obtain an owner certificate from a manufacturer-trusted 934 3rd-party certificate authority, and report that certificate 935 to the manufacturer. How the owner certificate is used to 936 enable devices to validate signed bootstrapping data is 937 described in Section 8.4. Assuming the prospective owner's 938 NMS is able to prepare and sign the bootstrapping data, the 939 owner certificate would be installed on the NMS at this time. 941 2. Some time later, the prospective owner places an order with the 942 manufacturer (or delegate), perhaps with a special flag checked 943 for zero touch handling. At this time, or perhaps before placing 944 the order, the owner may model the devices in their NMS, creating 945 virtual objects for the devices with no real-world device 946 associations. For instance the model can be used to simulate the 947 device's location in the network and the configuration it should 948 have when fully operational. 950 3. When the manufacturer or delegate fulfills the order, shipping 951 the devices to their intended locations, they may notify the 952 owner of the devices's unique identifiers (e.g., serial numbers) 953 and shipping destinations, which the owner may use to stage the 954 network for when the devices power on. Additionally, the 955 manufacturer may send one or more ownership vouchers, 956 cryptographically assigning ownership of those devices to the 957 rightful owner. The owner may set this information on their NMS, 958 perhaps binding specific modeled devices to the unique 959 identifiers and ownership vouchers. 961 7.2. Owner Stages the Network for Bootstrap 963 The following diagram illustrates how an owner might stage the 964 network for bootstrapping devices. 966 +----------+ +------------+ 967 |Deployment| |Manufacturer| +------+ +------+ 968 | Specific | | Hosted | | Local| | Local| +---------+ 969 +---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| 970 |NMS| | Server | | Server | |Server| |Server| | Storage | 971 +---+ +----------+ +------------+ +------+ +------+ +---------+ 972 | | | | | | 973 activate | | | | | | 974 modeled | | | | | | 975 1. device | | | | | | 976 ----------->| | | | | | 977 | 2. (optional) | | | | 978 | configure | | | | 979 | bootstrap | | | | 980 | server | | | | 981 |------->| | | | | 982 | | | | | | 983 | 3. (optional) configure | | | 984 | bootstrap server | | | | 985 |--------------------->| | | | 986 | | | | | | 987 | | | | | | 988 | 4. (optional) configure DNS server| | | 989 |---------------------------------->| | | 990 | | | | | | 991 | | | | | | 992 | 5. (optional) configure DHCP server | | 993 |------------------------------------------->| | 994 | | | | | | 995 | | | | | | 996 | 6. (optional) store bootstrapping artifacts on media | 997 |----------------------------------------------------->| 998 | | | | | | 999 | | | | | | 1001 Each numbered item below corresponds to a numbered item in the 1002 diagram above. 1004 1. Having previously modeled the devices, including setting their 1005 fully operational configurations and associating both device 1006 identifiers (e.g., serial numbers) and ownership vouchers, the 1007 owner "activates" one or more modeled devices. That is, the 1008 owner tells the NMS to perform the steps necessary to prepare for 1009 when the real-world devices power up and initiate the 1010 bootstrapping process. Note that, in some deployments, this step 1011 might be combined with the last step from the previous workflow. 1012 Here it is depicted that an NMS performs the steps, but they may 1013 be performed manually or through some other mechanism. 1015 2. If it is desired to use a deployment specific bootstrap server, 1016 it MUST be configured to provide the bootstrapping information 1017 for the specific devices. Configuring the bootstrap server MAY 1018 occur via a programmatic API not defined by this document. 1019 Illustrated here as an external component, the bootstrap server 1020 MAY be implemented as an internal component of the NMS itself. 1022 3. If it is desired to use a manufacturer (or delegate) hosted 1023 bootstrap server, it MUST be configured to provide the 1024 bootstrapping information for the specific devices. The 1025 configuration MUST be either redirect or bootstrap information. 1026 That is, either the manufacturer hosted bootstrap server will 1027 redirect the device to another bootstrap server, or provide the 1028 device with its bootstrapping information itself. The types of 1029 bootstrapping information the manufacturer hosted bootstrap 1030 server supports MAY vary by implementation; some implementations 1031 may only support redirect information, or only support bootstrap 1032 information, or support both redirect and bootstrap information. 1033 Configuring the bootstrap server MAY occur via a programmatic API 1034 not defined by this document. 1036 4. If it is desired to use a DNS server to supply bootstrapping 1037 information, a DNS server needs to be configured. If multicast 1038 DNS-SD is desired, then the server MUST reside on the local 1039 network, otherwise the DNS server MAY reside on a remote network. 1040 Please see Section 6.2 for more information about how to 1041 configure DNS servers. Configuring the DNS server MAY occur via 1042 a programmatic API not defined by this document. 1044 5. If it is desired to use a DHCP server to supply bootstrapping 1045 data, a DHCP server needs to be configured. The DHCP server may 1046 be accessed directly or via a DHCP relay. Please see Section 6.3 1047 for more information about how to configure DHCP servers. 1048 Configuring the DHCP server MAY occur via a programmatic API not 1049 defined by this document. 1051 6. If it is desired to use a removable storage device (e.g., USB 1052 flash drive) to supply bootstrapping information, the information 1053 would need to be placed onto it. Please see Section 6.1 for more 1054 information about how to configure a removable storage device. 1056 7.3. Device Powers On 1058 The following diagram illustrates the sequence of activities that 1059 occur when a device powers on. 1061 +----------+ 1062 +-----------+ |Deployment| 1063 | Source of | | Specific | 1064 +------+ | Bootstrap | |Bootstrap | +---+ 1065 |Device| | Data | | Server | |NMS| 1066 +------+ +-----------+ +----------+ +---+ 1067 | | | | 1068 | | | | 1069 | 1. if running a modified (not | | | 1070 | factory default) configuration, | | | 1071 | then exit. | | | 1072 | | | | 1073 | 2. for each source supported, check | | | 1074 |------------------------------------->| | | 1075 | | | | 1076 | 3. if bootstrap-information found, | | | 1077 | initialize self and, only if | | | 1078 | source is a bootstrap server, | | | 1079 | send notifications | | | 1080 |-------------------------------------># | | 1081 | # webhook | | 1082 | #----------------------->| 1083 | | | 1084 | 4. else if redirect-information found, for | | 1085 | each bootstrap server specified, check | | 1086 |-+-------------------------------------------------->| | 1087 | | | | 1088 | | if more redirect-information is found, recurse | | 1089 | | (not depicted), else if bootstrap-information | | 1090 | | found, initialize self and post notifications | | 1091 | +--------------------------------------------------># | 1092 | # webhook | 1093 | #-------->| 1094 | 1095 | 5. retry sources and/or wait for manual provisioning. 1096 | 1098 The interactions in the above diagram are described below. 1100 1. Upon power being applied, the device's bootstrapping logic first 1101 checks to see if it is running in its factory default state. If 1102 it is in a modified state, then the bootstrapping logic exits and 1103 none of the following interactions occur. 1105 2. For each source of bootstrapping data the device supports, 1106 preferably in order of closeness to the device (e.g., removable 1107 storage before Internet based servers), the device checks to see 1108 if there is any bootstrapping data for it there. 1110 3. If bootstrap-information is found, the device initializes itself 1111 accordingly (e.g., installing a boot-image and committing an 1112 initial configuration). If the source is a bootstrap server, and 1113 the bootstrap server can be trusted (i.e., TLS-level 1114 authentication), the device also sends progress notifications to 1115 the bootstrap server. 1117 * The contents of the initial configuration SHOULD configure an 1118 administrator account on the device (e.g., username, ssh-rsa 1119 key, etc.) and SHOULD configure the device either to listen 1120 for NETCONF or RESTCONF connections or to initiate call home 1121 connections [RFC8071]. 1123 * If the bootstrap server supports forwarding device 1124 notifications to external systems (e.g., via a webhook), the 1125 "bootstrap-complete" notification (Section 10.3) informs the 1126 external system to know when it can, for instance, initiate a 1127 connection to the device (assuming it knows the device's 1128 address and the device was configured to listen for 1129 connections). To support this further, the bootstrap-complete 1130 notification also relays the device's SSH host keys and/or TLS 1131 certificates, with which the external system can use to 1132 authenticate subsequent connections to the device. 1134 If the device is ever able to complete the bootstrapping process 1135 successfully (i.e., no longer running its factory default 1136 configuration), it exits the bootstrapping logic without 1137 considering any additional sources of bootstrapping data. 1139 4. Otherwise, if redirect-information is found, the device iterates 1140 through the list of specified bootstrap servers, checking to see 1141 if there is any bootstrapping data for it on them. If the 1142 bootstrap server returns more redirect-information, then the 1143 device processes it recursively. Otherwise, if the bootstrap 1144 server returns bootstrap-information, the device processes it 1145 following the description provided in (3) above. 1147 5. After having tried all supported sources of bootstrapping data, 1148 the device MAY retry again all the sources and/or provide 1149 manageability interfaces for manual configuration (e.g., CLI, 1150 HTTP, NETCONF, etc.). If manual configuration is allowed, and 1151 such configuration is provided, the device MUST immediately cease 1152 trying to obtain bootstrapping data, as it would then no longer 1153 be in running its factory default configuration. 1155 8. Device Details 1157 Devices supporting the bootstrapping strategy described in this 1158 document MUST have the preconfigured factory default state and 1159 bootstrapping logic described in the following sections. 1161 8.1. Factory Default State 1163 +------------------------------------------------------------------+ 1164 | | 1165 | | 1166 | +----------------------------------------------------------+ | 1167 | | | | 1168 | | | | 1169 | | 1. IDevID cert & associated intermediate certificate(s) | | 1170 | | 2. list of trusted Internet based bootstrap servers | | 1171 | | 3. list of trust anchor certs for bootstrap servers | | 1172 | | 4. trust anchor cert for ownership vouchers | | 1173 | +----------------------------------------------------------+ | 1174 | | 1175 | +----------------------+ | 1176 | | | | 1177 | | | | 1178 | | 5. private key | | 1179 | +----------------------+ | 1180 | | 1181 +------------------------------------------------------------------+ 1183 Each numbered item below corresponds to a numbered item in the 1184 diagram above. 1186 1. Devices MUST be manufactured with an initial device identifier 1187 (IDevID), as defined in [Std-802.1AR-2009]. The IDevID is an 1188 X.509 certificate, encoding the device's unique device identifier 1189 (e.g., serial number). The device MUST also possess any 1190 intermediate certificates between the IDevID certificate and the 1191 manufacturer's IDevID trust anchor certificate, which is provided 1192 to prospective owners separately (e.g., Section 7.1). 1194 2. Devices that support loading bootstrapping data from an Internet- 1195 based bootstrap server (see Section 6.4) MUST be manufactured 1196 with a configured list of trusted bootstrap servers. Consistent 1197 with redirect information (Section 3.1, each bootstrap server MAY 1198 be identified by its hostname or IP address, and an optional 1199 port. 1201 3. Devices that support loading bootstrapping data from an Internet- 1202 based bootstrap server (see Section 6.4) MUST also be 1203 manufactured with a list of trust anchor certificates that can be 1204 used for X.509 certificate path validation ([RFC6125], Section 6) 1205 on the bootstrap server's TLS server certificate. 1207 4. Devices that support loading owner signed data (see Section 1.2) 1208 MUST also be manufactured with the trust anchor certificate for 1209 the ownership vouchers. 1211 5. Device MUST be manufactured with a private key that corresponds 1212 to the public key encoded in the device's IDevID certificate. 1213 This private key SHOULD be securely stored, ideally by a 1214 cryptographic processor (e.g., a TPM). 1216 8.2. Boot Sequence 1218 A device claiming to support the bootstrapping strategy defined in 1219 this document MUST support the boot sequence described in this 1220 section. 1222 Power On 1223 | 1224 v No 1225 1. Running default config? --------> Boot normally 1226 | 1227 | Yes 1228 v 1229 2. For each supported source of bootstrapping data, 1230 try to load bootstrapping data from the source 1231 | 1232 | 1233 v Yes 1234 3. Able to bootstrap off any source? -----> Run with new configuration 1235 | 1236 | No 1237 v 1238 4. Loop and/or wait for manual provisioning. 1240 Each numbered item below corresponds to a numbered item in the 1241 diagram above. 1243 1. When the device powers on, it first checks to see if it is 1244 running the factory default configuration. If it is running a 1245 modified configuration, then it boots normally. 1247 2. The device iterates over its list of sources for bootstrapping 1248 data (Section 6). Details for how to processes a source of 1249 bootstrapping data are provided in Section 8.3. 1251 3. If the device is able to bootstrap itself off any of the sources 1252 of bootstrapping data, it runs with the new bootstrapped 1253 configuration. 1255 4. Otherwise the device MAY loop back through the list of 1256 bootstrapping sources again and/or wait for manual provisioning. 1258 8.3. Processing a Source of Bootstrapping Data 1260 This section describes a recursive algorithm that a device claiming 1261 to support the bootstrapping strategy defined in this document MUST 1262 use to authenticate bootstrapping data. A device enters this 1263 algorithm for each new source of bootstrapping data. The first time 1264 the device enters this algorithm, it MUST initialize a conceptual 1265 trust state variable, herein referred to as "trust-state", to FALSE. 1266 The ultimate goal of this algorithm is for the device to process 1267 bootstrap information (Section 3.2) while the trust-state variable is 1268 TRUE. 1270 If the data source is a bootstrap server, and the device is able to 1271 authenticate the server using X.509 certificate path validation 1272 ([RFC6125], Section 6) to one of the device's preconfigured trust 1273 anchors, or to a trust anchor that it learned from a previous step, 1274 then the device MUST set trust-state to TRUE. 1276 If trust-state is TRUE, when connecting to the bootstrap server, the 1277 device MUST use its IDevID certificate for client certificate based 1278 authentication and MUST POST progress notifications using the 1279 bootstrap server's "notification" action. Otherwise, if trust-state 1280 is FALSE, when connecting to the bootstrap server, the device MUST 1281 NOT use its IDevID certificate for a client certificate based 1282 authentication and MUST NOT POST progress notifications using the 1283 bootstrap server's "notification" action. 1285 When accessing a bootstrap server, the device MUST only access its 1286 top-level resource, to obtain all the data staged for it in one GET 1287 request, so that it can determine if the data is signed or not, and 1288 thus act accordingly. If trust-state is TRUE, then the device MAY 1289 also accesses the bootstrap servers 'notification' resource for the 1290 device. 1292 For any source of bootstrapping data (e.g., Section 6), if the data 1293 is signed and the device is able to validate the signed data using 1294 the algorithm described in Section 8.4, then the device MUST set 1295 trust-state to TRUE, else the device MUST set trust-state to FALSE. 1296 Note, this is worded to cover the special case when signed data is 1297 returned even from a trusted bootstrap server. 1299 If the data is bootstrap information (not redirect information), and 1300 trust-state is FALSE, the device MUST exit the recursive algorithm, 1301 returning to the state machine described in Section 8.2. Otherwise, 1302 the device MUST attempt to process the bootstrap information as 1303 described in Section 8.6. In either case, success or failure, the 1304 device MUST exit the recursive algorithm, returning to the state 1305 machine described in Section 8.2, the only difference being in how it 1306 responds to the "Able to bootstrap off any source?" conditional 1307 described in that state machine. 1309 If the data is redirect information, the device MUST process the 1310 redirect information as described in Section 8.5. This is the 1311 recursion step, it will cause to device to reenter this algorithm, 1312 but this time the data source will most definitely be a bootstrap 1313 server, as that is all redirect information is able to do. 1315 8.4. Validating Signed Data 1317 Whenever a device is presented signed data from an untrusted source, 1318 it MUST validate the signed data as described in this section. If 1319 the signed data is provided by a trusted source, a redundant trust 1320 case, the device MAY skip verifying the signature. 1322 Whenever there is signed data, the device MUST also be provided an 1323 ownership voucher and an owner certificate. Depending on 1324 circumstances, the device MAY also be provided certificate 1325 revocations. How all the needed artifacts are provided for each 1326 source of bootstrapping data is defined in Section 6. 1328 The device MUST first authenticate the ownership voucher by 1329 validating the signature on it to one of its preconfigured trust 1330 anchors (see Section 8.1) and verify that the voucher contains the 1331 device's unique identifier (e.g., serial number). If the voucher 1332 contains an expiration timestamp, the device MUST also verify that 1333 the voucher has not expired. If the authentication of the voucher is 1334 successful, the device extracts from it information that can be used 1335 to verify the owner certificate in the next step. 1337 Next the device MUST authenticate the owner certificate by performing 1338 X.509 certificate path verification to the trusted certificate 1339 provided in the voucher. If the device insists on verifying 1340 revocation status, it MUST also verify that none of the certificates 1341 in the chain of certificates have been revoked or expired. If the 1342 authentication of the certificate is successful, the device extracts 1343 the owner's public key from the certificate for use in the next step. 1345 Finally the device MUST verify the signature over information 1346 artifact was generated by the private key matching the public key 1347 extracted from the owner certificate in the previous step. 1349 If any of these steps fail, then the device MUST mark the data as 1350 invalid and not perform any of the subsequent steps. 1352 8.5. Processing Redirect Information 1354 In order to process redirect information (Section 3.1), the device 1355 MUST follow the steps presented in this section. 1357 Processing redirect information is straightforward. The device 1358 sequentially steps through the list of provided bootstrap servers 1359 until it can find one it can bootstrap off of. 1361 If a hostname is provided, and the hostname's DNS resolution is to 1362 more than one IP address, the device MUST attempt to connect to all 1363 of the DNS resolved addresses at least once, before moving on to the 1364 next bootstrap server. If the device is able to obtain bootstrapping 1365 data from any of the DNS resolved addresses, it MUST immediately 1366 process that data, without attempting to connect to any of the other 1367 DNS resolved addresses. 1369 If the redirect information is trusted (e.g., trust-state is TRUE), 1370 and the bootstrap server entry contains a trust anchor certificate, 1371 then the device MUST authenticate the bootstrap server using X.509 1372 certificate path validation ([RFC6125], Section 6) to the specified 1373 trust anchor. If the device is unable to authenticate the bootstrap 1374 server to the specified trust anchor, the device MUST NOT attempt a 1375 provisional connection to the bootstrap server (i.e., by blindly 1376 accepting its server certificate). 1378 If the redirect information is untrusted (e.g., trust-state is 1379 FALSE), the device MUST discard any trust anchors provided by the 1380 redirect information and establish a provisional connection to the 1381 bootstrap server (i.e., by blindly accepting its TLS server 1382 certificate). 1384 8.6. Processing Bootstrap Information 1386 In order to process bootstrap information (Section 3.2), the device 1387 MUST follow the steps presented in this section. 1389 When processing bootstrap information, the device MUST first process 1390 the boot image information, then execute the pre-configuration script 1391 (if any), then commit the initial configuration, and then execute the 1392 script (if any), in that order. If the device encounters an error at 1393 any step, it MUST NOT proceed to the next step. 1395 First the device MUST determine if the image it is running satisfies 1396 the specified boot image criteria (e.g., name or fingerprint match). 1397 If it does not, the device MUST download, verify, and install the 1398 specified boot image, and then reboot. To verify the boot image, the 1399 device MUST check that the boot image file matches the fingerprint 1400 (e.g., sha256) supplied by the bootstrapping information. Upon 1401 rebooting, the device MUST still be in its factory default state, 1402 causing the bootstrapping process to run again, which will eventually 1403 come to this very point, but this time the device's running image 1404 will satisfy the specified criteria, and thus the device will move to 1405 processing the next step. 1407 Next, for devices that support executing scripts, if a pre- 1408 configuration script has been specified, the device MUST execute the 1409 script and check its exit status code to determine if had any 1410 warnings or errors. In the case of errors, the device MUST reset 1411 itself in such a way that force the reinstallation of its boot image, 1412 thereby wiping out any bad state the script might have left behind. 1414 Next the device commits the provided initial configuration. Assuming 1415 no errors, the device moves to processing the next step. 1417 Again, for devices that support executing scripts, if a post- 1418 configuration script has been specified, the device MUST execute the 1419 script and check its exit status code to determine if it had any 1420 warnings or errors. In the case of errors, the device MUST reset 1421 itself in such a way that force the reinstallation of its boot image, 1422 thereby wiping out any bad state the script might have left behind. 1424 At this point, the device has completely processed the bootstrapping 1425 data and is ready to be managed. If the device obtained the 1426 bootstrap information from a trusted bootstrap server, the device 1427 MUST send the 'bootstrap-complete' notification now. 1429 At this point the device is configured and no longer running its 1430 factory default configuration. Notably, if the bootstrap information 1431 configured the device it initiate a call home connection, the device 1432 would proceed to do so now. 1434 9. The Zero Touch Information Artifact 1436 This section defines a YANG [RFC6020] module that is used to define 1437 the data model for the Zero Touch Information artifact described in 1438 Section 4.1. Examples illustrating this artifact in use are provided 1439 in Section 9.2. 1441 9.1. Tree Diagram 1443 The following tree diagram provides an overview of the data model for 1444 the Zero Touch Information artifact. The syntax used for this tree 1445 diagram is described in Section 1.4. 1447 module: ietf-zerotouch-information 1448 +---- (information-type) 1449 +--:(redirect-information) 1450 | +---- redirect-information 1451 | +---- bootstrap-server* [address] 1452 | +---- address inet:host 1453 | +---- port? inet:port-number 1454 | +---- trust-anchor? binary 1455 +--:(bootstrap-information) 1456 +---- bootstrap-information 1457 +---- boot-image 1458 | +---- name string 1459 | +---- (hash-algorithm) 1460 | | +--:(sha256) 1461 | | +---- sha256? string 1462 | +---- uri* inet:uri 1463 +---- configuration-handling? enumeration 1464 +---- pre-configuration-script? script 1465 +---- configuration? 1466 +---- post-configuration-script? script 1468 9.2. Example Usage 1470 This section presents examples for how the information artifact 1471 (Section 4.1) can be encoded into a document that can be distributed 1472 outside the bootstrap server's RESTCONF API. 1474 The following example illustrates how redirect information can be 1475 encoded into an artifact. 1477 1479 1480
phs1.example.com
1481 8443 1482 Base64-encoded X.50 1483 1484 1485
phs2.example.com
1486 8443 1487 Base64-encoded X.50 1488 1489 1490
phs3.example.com
1491 8443 1492 Base64-encoded X.50 1493 1494 1496 The following example illustrates how bootstrap information can be 1497 encoded into an artifact. This example uses datamodels from 1498 [RFC7317] and [I-D.ietf-netconf-netconf-client-server]. 1500 <-- '\' line wrapping added for formatting purposes only --> 1502 1504 1505 boot-image-v3.2R1.6.img 1506 Hex-encoded SHA256 hash 1507 file:///some/path/to/raw/file 1508 1509 merge 1510 1511 1512 1513 1514 1515 admin 1516 1517 admin's rsa ssh host-key 1518 ssh-rsa 1519 AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC\ 1520 jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj\ 1521 E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC\ 1522 WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5\ 1523 vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq\ 1524 EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6\ 1525 gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1 1526 1527 1528 1529 1530 1531 1533 1534 1535 config-mgr 1536 1537 1538 1539 east-data-center 1540
11.22.33.44
1541 1542 1543 west-data-center 1544
55.66.77.88
1545 1546 1547 1548 1549 certificate 1550 builtin-idevid-cert 1551 1552 1553 1554 deployment-specific-ca-certs 1555 explicitly-trusted-client-certs 1556 1557 1558 1559 1560 300 1561 60 1562 1563 1564 1565 last-connected 1566 3 1567 1568 1569 1570 1571 1573 1575 9.3. YANG Module 1577 The Zero Touch Information artifact is normatively defined by the 1578 YANG module defined in this section. 1580 Note: the module defined herein uses data types defined in [RFC5280], 1581 [RFC6234], and [RFC6991]. 1583 file "ietf-zerotouch-information@2017-03-13.yang" 1585 module ietf-zerotouch-information { 1586 yang-version "1.1"; 1588 namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-information"; 1589 prefix "zti"; 1591 import ietf-inet-types { 1592 prefix inet; 1593 reference "RFC 6991: Common YANG Data Types"; 1594 } 1596 import ietf-restconf { 1597 prefix rc; 1598 description 1599 "This import statement is only present to access 1600 the yang-data extension defined in RFC 8040."; 1601 reference "RFC 8040: RESTCONF Protocol"; 1602 } 1604 organization 1605 "IETF NETCONF (Network Configuration) Working Group"; 1607 contact 1608 "WG Web: http://tools.ietf.org/wg/netconf 1609 WG List: 1610 Author: Kent Watsen "; 1612 description 1613 "This module defines the data model for the Zero Touch Information 1614 artifact defined by RFC XXXX: Zero Touch Provisioning for NETCONF 1615 or RESTCONF based Management. 1617 Copyright (c) 2014 IETF Trust and the persons identified as 1618 authors of the code. All rights reserved. 1620 Redistribution and use in source and binary forms, with or without 1621 modification, is permitted pursuant to, and subject to the license 1622 terms contained in, the Simplified BSD License set forth in Section 1623 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1624 (http://trustee.ietf.org/license-info). 1626 This version of this YANG module is part of RFC XXXX; see the RFC 1627 itself for full legal notices."; 1629 revision "2017-03-13" { 1630 description 1631 "Initial version"; 1632 reference 1633 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based 1634 Management"; 1635 } 1637 rc:yang-data zerotouch-information { 1638 uses zerotouch-information-grouping; 1639 } 1641 grouping zerotouch-information-grouping { 1642 description 1643 "Defines the zerotouch information data model. Grouping 1644 exists only to enable pyang tree output."; 1646 choice information-type { 1647 mandatory true; 1648 description 1649 "This choice statement ensures the response only contains 1650 redirect-information or bootstrap-information. Note that 1651 this is the only mandatory true node, as the other nodes 1652 are not needed when the device trusts the bootstrap server, 1653 in which case the data does not need to be signed."; 1655 container redirect-information { 1656 description 1657 "This is redirect information, as described in Section 3.1 1658 in RFC XXXX. Its purpose is to redirect a device to another 1659 bootstrap server."; 1660 reference 1661 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF 1662 based Management"; 1664 list bootstrap-server { 1665 key address; 1666 description 1667 "A bootstrap server entry."; 1669 leaf address { 1670 type inet:host; 1671 mandatory true; 1672 description 1673 "The IP address or hostname of the bootstrap server the 1674 device should redirect to."; 1675 } 1676 leaf port { 1677 type inet:port-number; 1678 default 443; 1679 description 1680 "The port number the bootstrap server listens on."; 1681 } 1682 leaf trust-anchor { //should there be two fields like voucher? 1683 type binary; 1684 description 1685 "An X.509 v3 certificate structure as specified by RFC 1686 5280, Section 4, encoded using ASN.1 distinguished 1687 encoding rules (DER), as specified in ITU-T X.690. A 1688 certificate that a device can use as a trust anchor 1689 to authenticate the bootstrap server it is being 1690 redirected to."; 1691 reference 1692 "RFC 5280: 1693 Internet X.509 Public Key Infrastructure Certificate 1694 and Certificate Revocation List (CRL) Profile. 1695 ITU-T X.690: 1696 Information technology - ASN.1 encoding rules: 1697 Specification of Basic Encoding Rules (BER), 1698 Canonical Encoding Rules (CER) and Distinguished 1699 Encoding Rules (DER)."; 1700 } 1701 } 1702 } 1704 container bootstrap-information { 1706 description 1707 "This is bootstrap information, as described in Section 3.2 in 1708 RFC XXXX. Its purpose is to provide the device everything it 1709 needs to bootstrap itself."; 1710 reference 1711 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF 1712 based Management"; 1714 container boot-image { 1715 description 1716 "Specifies criteria for the boot image the device MUST 1717 be running."; 1719 leaf name { // maybe this should be a regex? 1720 type string; 1721 mandatory true; 1722 description 1723 "The name of a software image that the device MUST 1724 be running in order to process the remaining nodes."; 1725 } 1726 choice hash-algorithm { 1727 mandatory true; 1728 description 1729 "Identifies the hash algorithm used."; 1730 leaf sha256 { 1731 type string; 1732 description 1733 "The hex-encoded SHA-256 hash over the boot 1734 image file. This is used by the device to 1735 verify a downloaded boot image file."; 1736 reference 1737 "RFC 6234: US Secure Hash Algorithms."; 1738 } 1739 } 1740 leaf-list uri { 1741 type inet:uri; 1742 min-elements 1; 1743 description 1744 "An ordered list of URIs to where the boot-image file MAY 1745 be obtained. Deployments MUST know in which URI schemes 1746 (http, ftp, etc.) a device supports. If a secure scheme 1747 (e.g., https) is provided, a device MAY establish a 1748 provisional connection to the server, by blindly 1749 accepting the server's credentials (e.g., its TLS 1750 certificate)"; 1751 } 1752 } 1754 leaf configuration-handling { 1755 type enumeration { 1756 enum merge { 1757 description 1758 "Merge configuration into existing running configuration."; 1759 } 1760 enum replace { 1761 description 1762 "Replace existing running configuration with the passed 1763 configuration."; 1764 } 1766 } 1767 description 1768 "This enumeration indicates how the server should process 1769 the provided configuration. When not specified, the device 1770 MAY determine how to process the configuration using other 1771 means (e.g., vendor-specific metadata)."; 1772 } 1774 leaf pre-configuration-script { 1775 type script; 1776 description 1777 "A script that, when present, is executed before the 1778 configuration has been processed."; 1779 } 1781 anydata configuration { 1782 must "../configuration-handling"; 1783 description 1784 "Any configuration data model known to the device. It may 1785 contain manufacturer-specific and/or standards-based data 1786 models."; 1787 } 1789 leaf post-configuration-script { 1790 type script; 1791 description 1792 "A script that, when present, is executed after the 1793 configuration has been processed."; 1794 } 1795 } 1796 } 1797 } 1799 typedef script { 1800 type binary; 1801 description 1802 "A device specific script that enables the execution of commands 1803 to perform actions not possible thru configuration alone. 1805 No attempt is made to standardize the contents, running context, 1806 or programming language of the script. The contents of the 1807 script are considered specific to the vendor, product line, 1808 and/or model of the device. 1810 If a script is erroneously provided to a device that does not 1811 support the execution of scripts, the device SHOULD send a 1812 'script-warning' notification message, but otherwise continue 1813 processing the bootstrapping data as if the script had not 1814 been present. 1816 The script returns exit status code '0' on success and non-zero 1817 on error, with accompanying stderr/stdout for logging purposes. 1818 In the case of an error, the exit status code will specify what 1819 the device should do. 1821 If the exit status code is greater than zero, then the device 1822 should assume that the script had a soft error, which the 1823 script believes does not affect manageability. If the device 1824 obtained the bootstrap information from a bootstrap server, 1825 it SHOULD send a 'script-warning' notification message. 1827 If the exit status code is less than zero, the device should 1828 assume the script had a hard error, which the script believes 1829 will affect manageability. In this case, the device SHOULD 1830 send a 'script-error' notification message followed by a 1831 reset that will force a new boot-image install (wiping out 1832 anything the script may have done) and restart the entire 1833 bootstrapping process again."; 1834 } 1836 } 1838 1840 10. The Zero Touch Bootstrap Server API 1842 This section defines a YANG [RFC6020] module that is used to define 1843 the RESTCONF [RFC8040] API used by the bootstrap server defined in 1844 Section 6.4. Examples illustrating this API in use are provided in 1845 Section 10.2. 1847 10.1. Tree Diagram 1849 The following tree diagram provides an overview for the bootstrap 1850 server RESTCONF API. The syntax used for this tree diagram is 1851 described in Section 1.4. 1853 module: ietf-zerotouch-bootstrap-server 1854 +--ro device* [unique-id] 1855 +--ro unique-id string 1856 +--ro zerotouch-information pkcs7 1857 +--ro owner-certificate? pkcs7 1858 +--ro ownership-voucher? pkcs7 1859 +---x notification 1860 +---w input 1861 +---w notification-type enumeration 1862 +---w message? string 1863 +---w ssh-host-keys 1864 | +---w ssh-host-key* 1865 | +---w format enumeration 1866 | +---w key-data string 1867 +---w trust-anchors 1868 +---w trust-anchor* 1869 +---w protocol* enumeration 1870 +---w certificate pkcs7 1872 In the above diagram, notice that all of the protocol accessible 1873 nodes are read-only, to assert that devices can only pull data from 1874 the bootstrap server. 1876 Also notice that the module defines an action statement, which 1877 devices use to provide progress notifications to the bootstrap 1878 server. 1880 10.2. Example Usage 1882 This section presents some examples illustrating the bootstrap 1883 server's API. Two examples are provided, one illustrating a device 1884 fetching bootstrapping data from the server, and the other 1885 illustrating a data posting a progress notification to the server. 1887 The following example illustrates a device using the API to fetch its 1888 bootstrapping data from the bootstrap server. In this example, the 1889 device receives a signed response; an unsigned response would look 1890 similar except the last two fields (owner-certificate and ownership- 1891 voucher) would be absent in the response. 1893 REQUEST 1894 ------- 1895 ['\' line wrapping added for formatting only] 1897 GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ 1898 device=123456 HTTP/1.1 1899 HOST: example.com 1900 Accept: application/yang.data+xml 1902 RESPONSE 1903 -------- 1905 HTTP/1.1 200 OK 1906 Date: Sat, 31 Oct 2015 17:02:40 GMT 1907 Server: example-server 1908 Content-Type: application/yang.data+xml 1910 1912 1914 123456789 1915 \ 1916 Base64-encoded Zero Touch Information artifact\ 1917 1918 Base64-encoded PKCS#7 1919 Base64-encoded Voucher 1920 1922 The following example illustrates a device using the API to post a 1923 notification to a bootstrap server. Illustrated below is the 1924 'bootstrap-complete' message, but the device may send other 1925 notifications to the server while bootstrapping (e.g., to provide 1926 status updates). In this message, the device is sending both its SSH 1927 host keys and TLS server certificate, which the bootstrap server may, 1928 for example, pass to an NMS, as discussed in Section 7.3. 1930 Note that devices that are able to present an IDevID certificate 1931 [Std-802.1AR-2009] when establishing SSH or TLS connections do not 1932 need to include its DevID certificate in the bootstrap-complete 1933 message. It is unnecessary to send the DevID certificate in this 1934 case because the IDevID certificate does not need to be pinned by an 1935 NMS in order to be trusted. 1937 Note that the bootstrap server MUST NOT process a notification from a 1938 device without first authenticating the device. This is in contrast 1939 to when a device is fetching data from the server, a read-only 1940 operation, in which case device authentication is not strictly 1941 required (e.g., when sending signed information). 1943 REQUEST 1944 ------- 1945 ['\' line wrapping added for formatting only] 1947 POST https://example.com/restconf/data/ietf-zerotouch:\ 1948 device=123456/notification HTTP/1.1 1949 HOST: example.com 1950 Content-Type: application/yang.data+xml 1952 1954 1956 bootstrap-complete 1957 example message 1958 1959 1960 ssh-rsa 1961 Base64-encoded SSH RSA Public Key 1962 1963 1964 ssh-dsa 1965 Base64-encoded SSH DSA Public Key 1966 1967 1968 1969 1970 netconf-ssh 1971 netconf-tls 1972 restconf-tls 1973 netconf-ch-ssh 1974 netconf-ch-tls 1975 restconf-ch-tls 1976 Base64-encoded X.509 1977 1978 1979 1981 RESPONSE 1982 -------- 1984 HTTP/1.1 204 No Content 1985 Date: Sat, 31 Oct 2015 17:02:40 GMT 1986 Server: example-server 1988 10.3. YANG Module 1990 The bootstrap server's device-facing API is normatively defined by 1991 the YANG module defined in this section. 1993 Note: the module defined herein uses data types defined in [RFC2315], 1994 [RFC5280], and [I-D.ietf-anima-voucher]. 1996 file "ietf-zerotouch-bootstrap-server@2017-03-13.yang" 1998 module ietf-zerotouch-bootstrap-server { 1999 yang-version "1.1"; 2001 namespace 2002 "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; 2003 prefix "ztbs"; 2005 organization 2006 "IETF NETCONF (Network Configuration) Working Group"; 2008 contact 2009 "WG Web: 2010 WG List: 2011 Author: Kent Watsen 2012 "; 2014 description 2015 "This module defines an interface for bootstrap servers, as defined 2016 by RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based 2017 Management. 2019 Copyright (c) 2014 IETF Trust and the persons identified as 2020 authors of the code. All rights reserved. 2022 Redistribution and use in source and binary forms, with or without 2023 modification, is permitted pursuant to, and subject to the license 2024 terms contained in, the Simplified BSD License set forth in Section 2025 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2026 (http://trustee.ietf.org/license-info). 2028 This version of this YANG module is part of RFC XXXX; see the RFC 2029 itself for full legal notices."; 2031 revision "2017-03-13" { 2032 description 2033 "Initial version"; 2034 reference 2035 "RFC XXXX: Zero Touch Provisioning for NETCONF or RESTCONF based 2036 Management"; 2037 } 2039 // typedefs 2041 typedef pkcs7 { 2042 type binary; 2043 description 2044 "A PKCS #7 SignedData structure, as specified by Section 9.1 2045 in RFC 2315, encoded using ASN.1 distinguished encoding rules 2046 (DER), as specified in ITU-T X.690."; 2047 reference 2048 "RFC 2315: 2049 PKCS #7: Cryptographic Message Syntax Version 1.5. 2050 ITU-T X.690: 2051 Information technology - ASN.1 encoding rules: 2052 Specification of Basic Encoding Rules (BER), 2053 Canonical Encoding Rules (CER) and Distinguished 2054 Encoding Rules (DER)."; 2055 } 2057 // protocol accessible node 2059 list device { 2060 key unique-id; 2061 config false; 2063 description 2064 "A device's record entry. This is the only RESTCONF resource 2065 that a device will GET, as described in Section 8.2 in RFC XXXX. 2066 Getting just this top-level node provides a device with all the 2067 data it needs in a single request."; 2068 reference 2069 "RFC XXXX: Zero Touch Provisioning for NETCONF or 2070 RESTCONF based Management"; 2072 leaf unique-id { 2073 type string; 2074 description 2075 "A unique identifier for the device (e.g., serial number). 2076 Each device accesses its bootstrapping record by its unique 2077 identifier."; 2078 } 2080 leaf zerotouch-information { 2081 type pkcs7; 2082 mandatory true; 2083 description 2084 "A 'zerotouch-information' artifact, as described in Section 2085 4.1 of RFC XXXX. When conveyed over an untrusted transport, in 2086 order to be processed by a device, this PKCS#7 SignedData 2087 structure MUST contain a 'signerInfo' structure, described 2088 in Section 9.1 of RFC 2315, containing a signature generated 2089 using the owner's private key."; 2090 reference 2091 "RFC XXXX: Zero Touch Provisioning for NETCONF or 2092 RESTCONF based Management. 2093 RFC 2315: 2094 PKCS #7: Cryptographic Message Syntax Version 1.5"; 2095 } 2097 leaf owner-certificate { 2098 type pkcs7; 2099 must "../zerotouch-information" { 2100 description 2101 "An 'zerotouch-information' artifact must be present 2102 whenever an ownership certificate is presented."; 2103 } 2104 description 2105 "An unsigned PKCS #7 SignedData structure, as specified by 2106 Section 9.1 in RFC 2315, encoded using ASN.1 distinguished 2107 encoding rules (DER), as specified in ITU-T X.690. 2109 This structure MUST contain the owner certificate and all 2110 intermediate certificates leading up to at least the trust 2111 anchor certificate specified in the ownership voucher. 2112 Additionally, if needed by the device, this structure MAY 2113 also contain suitably fresh CRL and or OCSP Responses. 2115 X.509 certificates and CRLs are described in RFC 5280. 2116 OCSP Responses are described in RFC 6960."; 2117 reference 2118 "RFC 2315: 2119 PKCS #7: Cryptographic Message Syntax Version 1.5. 2120 RFC 5280: 2121 Internet X.509 Public Key Infrastructure Certificate 2122 and Certificate Revocation List (CRL) Profile. 2123 RFC 6960: 2124 X.509 Internet Public Key Infrastructure Online 2125 Certificate Status Protocol - OCSP. 2126 ITU-T X.690: 2127 Information technology - ASN.1 encoding rules: 2128 Specification of Basic Encoding Rules (BER), 2129 Canonical Encoding Rules (CER) and Distinguished 2130 Encoding Rules (DER)."; 2131 } 2132 leaf ownership-voucher { 2133 type pkcs7; 2134 must "../owner-certificate" { 2135 description 2136 "An owner certificate must be present whenever an ownership 2137 voucher is presented."; 2138 } 2139 description 2140 "A 'voucher' artifact, as described in Section 5 of 2141 I-D.ietf-anima-voucher. The voucher's 'device-identifier' 2142 MUST reference both the device's unique identifier and 2143 the owner's owner certificate."; 2144 reference 2145 "I-D.etf-anima-voucher: 2146 Voucher and Voucher Revocation Profiles for Bootstrapping 2147 Protocols"; 2148 } 2150 action notification { 2151 input { 2152 leaf notification-type { 2153 type enumeration { 2154 enum bootstrap-initiated { 2155 description 2156 "Indicates that the device has just accessed the 2157 bootstrap server. The 'message' field below MAY 2158 contain any additional information that the 2159 manufacturer thinks might be useful."; 2160 } 2161 enum parsing-warning { 2162 description 2163 "Indicates that the device had a non-fatal error when 2164 parsing the response from the bootstrap server. The 2165 'message' field below SHOULD indicate the specific 2166 warning that occurred."; 2167 } 2168 enum parsing-error { 2169 description 2170 "Indicates that the device encountered a fatal error 2171 when parsing the response from the bootstrap server. 2172 For instance, this could be due to malformed encoding, 2173 the device expecting signed data when only unsigned 2174 data is provided, because the ownership voucher didn't 2175 include the device's unique identifier, or because the 2176 signature didn't match. The 'message' field below 2177 SHOULD indicate the specific error. This notification 2178 also indicates that the device has abandoned trying to 2179 bootstrap off this bootstrap server."; 2181 } 2182 enum boot-image-warning { 2183 description 2184 "Indicates that the device encountered a non-fatal 2185 error condition when trying to install a boot-image. 2186 A possible reason might include a need to reformat a 2187 partition causing loss of data. The 'message' field 2188 below SHOULD indicate any warning messages that were 2189 generated."; 2190 } 2191 enum boot-image-error { 2192 description 2193 "Indicates that the device encountered an error when 2194 trying to install a boot-image, which could be for 2195 reasons such as a file server being unreachable, 2196 file not found, signature mismatch, etc. The 2197 'message' field SHOULD indicate the specific error 2198 that occurred. This notification also indicates 2199 that the device has abandoned trying to bootstrap 2200 off this bootstrap server."; 2201 } 2202 enum pre-script-warning { 2203 description 2204 "Indicates that the device obtained a greater than 2205 zero exit status code from the script when it was 2206 executed. The 'message' field below SHOULD indicate 2207 both the resulting exit status code, as well as 2208 capture any stdout/stderr messages the script may 2209 have produced."; 2210 } 2211 enum pre-script-error { 2212 description 2213 "Indicates that the device obtained a less than zero 2214 exit status code from the script when it was executed. 2215 The 'message' field below SHOULD indicate both the 2216 resulting exit status code, as well as capture any 2217 stdout/stderr messages the script may have produced. 2218 This notification also indicates that the device has 2219 abandoned trying to bootstrap off this bootstrap 2220 server."; 2221 } 2222 enum config-warning { 2223 description 2224 "Indicates that the device obtained warning messages 2225 when it committed the initial configuration. The 2226 'message' field below SHOULD indicate any warning 2227 messages that were generated."; 2228 } 2229 enum config-error { 2230 description 2231 "Indicates that the device obtained error messages 2232 when it committed the initial configuration. The 2233 'message' field below SHOULD indicate the error 2234 messages that were generated. This notification 2235 also indicates that the device has abandoned trying 2236 to bootstrap off this bootstrap server."; 2237 } 2238 enum post-script-warning { 2239 description 2240 "Indicates that the device obtained a greater than 2241 zero exit status code from the script when it was 2242 executed. The 'message' field below SHOULD indicate 2243 both the resulting exit status code, as well as 2244 capture any stdout/stderr messages the script may 2245 have produced."; 2246 } 2247 enum post-script-error { 2248 description 2249 "Indicates that the device obtained a less than zero 2250 exit status code from the script when it was executed. 2251 The 'message' field below SHOULD indicate both the 2252 resulting exit status code, as well as capture any 2253 stdout/stderr messages the script may have produced. 2254 This notification also indicates that the device has 2255 abandoned trying to bootstrap off this bootstrap 2256 server."; 2257 } 2258 enum bootstrap-complete { 2259 description 2260 "Indicates that the device successfully processed the 2261 all the bootstrapping data and that it is ready to be 2262 managed. The 'message' field below MAY contain any 2263 additional information that the manufacturer thinks 2264 might be useful. After sending this notification, 2265 the device is not expected to access the bootstrap 2266 server again."; 2267 } 2268 enum informational { 2269 description 2270 "Indicates any additional information not captured by 2271 any of the other notification-type. For instance, a 2272 message indicating that the device is about to reboot 2273 after having installed a boot-image could be provided. 2274 The 'message' field below SHOULD contain information 2275 that the manufacturer thinks might be useful."; 2276 } 2278 } 2279 mandatory true; 2280 description 2281 "The type of notification provided."; 2282 } 2283 leaf message { 2284 type string; 2285 description 2286 "An optional human-readable value."; 2287 } 2288 container ssh-host-keys { 2289 when "../notification-type = 'bootstrap-complete'" { 2290 description 2291 "SSH host keys are only sent when the notification 2292 type is 'bootstrap-complete'."; 2293 } 2294 description 2295 "A list of SSH host keys an NMS may use to authenticate 2296 a NETCONF connection to the device with."; 2297 list ssh-host-key { 2298 description 2299 "An SSH host-key"; 2300 leaf format { 2301 type enumeration { 2302 enum ssh-dss { description "ssh-dss"; } 2303 enum ssh-rsa { description "ssh-rsa"; } 2304 } 2305 mandatory true; 2306 description 2307 "The format of the SSH host key."; 2308 } 2309 leaf key-data { 2310 type string; 2311 mandatory true; 2312 description 2313 "The key data for the SSH host key"; 2314 } 2315 } 2316 } 2317 container trust-anchors { 2318 when "../notification-type = 'bootstrap-complete'" { 2319 description 2320 "Trust anchors are only sent when the notification 2321 type is 'bootstrap-complete'."; 2322 } 2323 description 2324 "A list of trust anchor certificates an NMS may use to 2325 authenticate a NETCONF or RESTCONF connection to the 2326 device with."; 2327 list trust-anchor { 2328 description 2329 "A list of trust anchor certificates an NMS may use to 2330 authenticate a NETCONF or RESTCONF connection to the 2331 device with."; 2332 leaf-list protocol { 2333 type enumeration { 2334 enum netconf-ssh { description "netconf-ssh"; } 2335 enum netconf-tls { description "netconf-tls"; } 2336 enum restconf-tls { description "restconf-tls"; } 2337 enum netconf-ch-ssh { description "netconf-ch-ssh"; } 2338 enum netconf-ch-tls { description "netconf-ch-tls"; } 2339 enum restconf-ch-tls { description "restconf-ch-tls"; } 2340 } 2341 min-elements 1; 2342 description 2343 "The protocols that this trust anchor secures."; 2344 } 2345 leaf certificate { 2346 type pkcs7; 2347 mandatory true; 2348 description 2349 "An X.509 v3 certificate structure, as specified by 2350 Section 4 in RFC5280, encoded using ASN.1 distinguished 2351 encoding rules (DER), as specified in ITU-T X.690."; 2352 reference 2353 "RFC 5280: 2354 Internet X.509 Public Key Infrastructure Certificate 2355 and Certificate Revocation List (CRL) Profile. 2356 ITU-T X.690: 2357 Information technology - ASN.1 encoding rules: 2358 Specification of Basic Encoding Rules (BER), 2359 Canonical Encoding Rules (CER) and Distinguished 2360 Encoding Rules (DER)."; 2361 } 2362 } 2363 } 2364 } 2365 } // end action 2367 } // end device 2369 } 2371 2372 11. Security Considerations 2374 11.1. Immutable storage for trust anchors 2376 Devices MUST ensure that all their trust anchor certificates, 2377 including those for connecting to bootstrap servers and verifying 2378 ownership vouchers, are protected from external modification. 2380 It may be necessary to update these certificates over time (e.g., the 2381 manufacturer wants to delegate trust to a new CA). It is therefore 2382 expected that devices MAY update these trust anchors when needed 2383 through a verifiable process, such as a software upgrade using signed 2384 software images. 2386 11.2. Clock Sensitivity 2388 The solution in this document relies on TLS certificates, owner 2389 certificates, and ownership vouchers, all of which require an 2390 accurate clock in order to be processed correctly (e.g., to test 2391 validity dates and revocation status). Implementations MUST ensure 2392 devices have an accurate clock when shipped from manufacturing 2393 facilities, and take steps to prevent clock tampering. 2395 If it is not possible to ensure clock accuracy, it is RECOMMENDED 2396 that implementations disable the aspects of the solution having clock 2397 sensitivity. In particular, such implementations should assume that 2398 TLS certificates and owner certificates are not revokable. In real- 2399 world terms, this means that manufacturers SHOULD only issue a single 2400 ownership voucher for the lifetime of some devices. 2402 It is important to note that implementations SHOULD NOT rely on NTP 2403 for time, as it is not a secure protocol. 2405 11.3. Blindly authenticating a bootstrap server 2407 This document allows a device to blindly authenticate a bootstrap 2408 server's TLS certificate. It does so to allow for cases where the 2409 redirect information may be obtained in an unsecured manner, which is 2410 desirable to support in some cases. 2412 To compensate for this, this document requires that devices, when 2413 connected to an untrusted bootstrap server, do not send their IDevID 2414 certificate for client authentication, and they do not POST any 2415 progress notifications, and they assert that data downloaded from the 2416 server is signed. 2418 11.4. Entropy loss over time 2420 Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that 2421 IDevID certificate should never expire (i.e. having the notAfter 2422 value 99991231235959Z). Given the long-lived nature of these 2423 certificates, it is paramount to use a strong key length (e.g., 2424 512-bit ECC). 2426 11.5. Serial Numbers 2428 This draft suggests using the device's serial number as the unique 2429 identifier in its IDevID certificate. This is because serial numbers 2430 are ubiquitous and prominently contained in invoices and on labels 2431 affixed to devices and their packaging. That said, serial numbers 2432 many times encode revealing information, such as the device's model 2433 number, manufacture date, and/or sequence number. Knowledge of this 2434 information may provide an adversary with details needed to launch an 2435 attack. 2437 11.6. Sequencing Sources of Bootstrapping Data 2439 For devices supporting more than one source for bootstrapping data, 2440 no particular sequencing order has to be observed for security 2441 reasons, as the solution for each source is considered equally 2442 secure. However, from a privacy perspective, it is RECOMMENDED that 2443 devices access local sources before accessing remote sources. 2445 12. IANA Considerations 2447 12.1. The BOOTP Manufacturer Extensions and DHCP Options Registry 2449 The following registrations are in accordance to RFC 2939 [RFC2939] 2450 for "BOOTP Manufacturer Extensions and DHCP Options" registry 2451 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 2453 Tag: XXX 2455 Name: Zero Touch Information 2457 Returns up to three zero touch bootstrapping artifacts. 2459 Code Len 2460 +-----+-----+-----------------------+ 2461 | XXX | n | zerotouch-information | 2462 +-----+-----+-----------------------+ 2464 +-------------------+-------------------+ 2465 | owner-certificate | ownership-voucher | 2466 +-------------------+-------------------+ 2468 Reference: RFC XXXX 2470 Tag: YYY 2472 Name: Zero Touch Information 2474 Returns up to three zero touch bootstrapping artifacts. 2476 Code Len 2477 +-----+-----+-----------------------+ 2478 | XXX | n | zerotouch-information | 2479 +-----+-----+-----------------------+ 2481 +-------------------+-------------------+ 2482 | owner-certificate | ownership-voucher | 2483 +-------------------+-------------------+ 2485 Reference: RFC XXXX 2487 12.2. The IETF XML Registry 2489 This document registers one URI in the IETF XML registry [RFC3688]. 2490 Following the format in [RFC3688], the following registration is 2491 requested: 2493 URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch 2494 Registrant Contact: The NETCONF WG of the IETF. 2495 XML: N/A, the requested URI is an XML namespace. 2497 12.3. The YANG Module Names Registry 2499 This document registers two YANG modules in the YANG Module Names 2500 registry [RFC6020]. Following the format defined in [RFC6020], the 2501 the following registrations are requested: 2503 name: ietf-zerotouch-information 2504 namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch 2505 prefix: zt 2506 reference: RFC XXXX 2508 name: ietf-zerotouch-bootstrap-server 2509 namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch 2510 prefix: zt 2511 reference: RFC XXXX 2513 13. Other Considerations 2515 Both this document and [I-D.ietf-anima-bootstrapping-keyinfra] define 2516 bootstrapping mechanisms. The authors have collaborated on both 2517 solutions and believe that each solution has merit and, in fact, can 2518 work together. That is, it is possible for a device to support both 2519 solutions simultaneously. 2521 14. Acknowledgements 2523 The authors would like to thank for following for lively discussions 2524 on list and in the halls (ordered by last name): David Harrington, 2525 Michael Behringer, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, 2526 Toerless Eckert, Stephen Farrell, Ian Farrer, Stephen Hanna, Wes 2527 Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, 2528 Michael Richardson, Phil Shafer, Juergen Schoenwaelder. 2530 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 2531 brainstorming the original I-D's solution during the IETF 87 meeting 2532 in Berlin. 2534 15. References 2536 15.1. Normative References 2538 [I-D.ietf-anima-voucher] 2539 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2540 "Voucher and Voucher Revocation Profiles for Bootstrapping 2541 Protocols", draft-ietf-anima-voucher-00 (work in 2542 progress), January 2017. 2544 [RFC1035] Mockapetris, P., "Domain names - implementation and 2545 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2546 November 1987, . 2548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2549 Requirement Levels", BCP 14, RFC 2119, 2550 DOI 10.17487/RFC2119, March 1997, 2551 . 2553 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 2554 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 2555 . 2557 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2558 Housley, R., and W. Polk, "Internet X.509 Public Key 2559 Infrastructure Certificate and Certificate Revocation List 2560 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2561 . 2563 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2564 the Network Configuration Protocol (NETCONF)", RFC 6020, 2565 DOI 10.17487/RFC6020, October 2010, 2566 . 2568 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2569 Verification of Domain-Based Application Service Identity 2570 within Internet Public Key Infrastructure Using X.509 2571 (PKIX) Certificates in the Context of Transport Layer 2572 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2573 2011, . 2575 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2576 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2577 DOI 10.17487/RFC6234, May 2011, 2578 . 2580 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2581 DOI 10.17487/RFC6762, February 2013, 2582 . 2584 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2585 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2586 . 2588 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2589 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2590 . 2592 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 2593 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 2594 April 2015, . 2596 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2597 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2598 . 2600 [Std-802.1AR-2009] 2601 IEEE SA-Standards Board, "IEEE Standard for Local and 2602 metropolitan area networks - Secure Device Identity", 2603 December 2009, . 2606 15.2. Informative References 2608 [I-D.ietf-anima-bootstrapping-keyinfra] 2609 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2610 S., and K. Watsen, "Bootstrapping Remote Secure Key 2611 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2612 keyinfra-04 (work in progress), October 2016. 2614 [I-D.ietf-netconf-netconf-client-server] 2615 Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client 2616 and Server Models", draft-ietf-netconf-netconf-client- 2617 server-01 (work in progress), November 2016. 2619 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 2620 of New DHCP Options and Message Types", BCP 43, RFC 2939, 2621 DOI 10.17487/RFC2939, September 2000, 2622 . 2624 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2625 DOI 10.17487/RFC3688, January 2004, 2626 . 2628 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2629 and A. Bierman, Ed., "Network Configuration Protocol 2630 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2631 . 2633 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 2634 of Named Entities (DANE) Transport Layer Security (TLS) 2635 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2636 2012, . 2638 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 2639 Galperin, S., and C. Adams, "X.509 Internet Public Key 2640 Infrastructure Online Certificate Status Protocol - OCSP", 2641 RFC 6960, DOI 10.17487/RFC6960, June 2013, 2642 . 2644 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 2645 System Management", RFC 7317, DOI 10.17487/RFC7317, August 2646 2014, . 2648 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 2649 RFC 8071, DOI 10.17487/RFC8071, February 2017, 2650 . 2652 Appendix A. Change Log 2654 A.1. ID to 00 2656 o Major structural update; the essence is the same. Most every 2657 section was rewritten to some degree. 2659 o Added a Use Cases section 2661 o Added diagrams for "Actors and Roles" and "NMS Precondition" 2662 sections, and greatly improved the "Device Boot Sequence" diagram 2664 o Removed support for physical presence or any ability for 2665 configlets to not be signed. 2667 o Defined the Zero Touch Information DHCP option 2669 o Added an ability for devices to also download images from 2670 configuration servers 2672 o Added an ability for configlets to be encrypted 2674 o Now configuration servers only have to support HTTP/S - no other 2675 schemes possible 2677 A.2. 00 to 01 2679 o Added boot-image and validate-owner annotations to the "Actors and 2680 Roles" diagram. 2682 o Fixed 2nd paragraph in section 7.1 to reflect current use of 2683 anyxml. 2685 o Added encrypted and signed-encrypted examples 2687 o Replaced YANG module with XSD schema 2689 o Added IANA request for the Zero Touch Information DHCP Option 2691 o Added IANA request for media types for boot-image and 2692 configuration 2694 A.3. 01 to 02 2696 o Replaced the need for a configuration signer with the ability for 2697 each NMS to be able to sign its own configurations, using 2698 manufacturer signed ownership vouchers and owner certificates. 2700 o Renamed configuration server to bootstrap server, a more 2701 representative name given the information devices download from 2702 it. 2704 o Replaced the concept of a configlet by defining a southbound 2705 interface for the bootstrap server using YANG. 2707 o Removed the IANA request for the boot-image and configuration 2708 media types 2710 A.4. 02 to 03 2712 o Minor update, mostly just to add an Editor's Note to show how this 2713 draft might integrate with the draft-pritikin-anima-bootstrapping- 2714 keyinfra. 2716 A.5. 03 to 04 2718 o Major update formally introducing unsigned data and support for 2719 Internet-based redirect servers. 2721 o Added many terms to Terminology section. 2723 o Added all new "Guiding Principles" section. 2725 o Added all new "Sources for Bootstrapping Data" section. 2727 o Rewrote the "Interactions" section and renamed it "Workflow 2728 Overview". 2730 A.6. 04 to 05 2732 o Semi-major update, refactoring the document into more logical 2733 parts 2735 o Created new section for information types 2737 o Added support for DNS servers 2739 o Now allows provisional TLS connections 2741 o Bootstrapping data now supports scripts 2743 o Device Details section overhauled 2745 o Security Considerations expanded 2747 o Filled in enumerations for notification types 2749 A.7. 05 to 06 2751 o Minor update 2753 o Added many Normative and Informative references. 2755 o Added new section Other Considerations. 2757 A.8. 06 to 07 2759 o Minor update 2761 o Added an Editorial Note section for RFC Editor. 2763 o Updated the IANA Considerations section. 2765 A.9. 07 to 08 2767 o Minor update 2769 o Updated to reflect review from Michael Richardson. 2771 A.10. 08 to 09 2773 o Added in missing "Signature" artifact example. 2775 o Added recommendation for manufacturers to use interoperable 2776 formats and file naming conventions for removable storage devices. 2778 o Added configuration-handling leaf to guide if config should be 2779 merged, replaced, or processed like an edit-config/yang-patch 2780 document. 2782 o Added a pre-configuration script, in addition to the post- 2783 configuration script from -05 (issue #15). 2785 A.11. 09 to 10 2787 o Factored ownership vocher and voucher revocation to a separate 2788 document: draft-kwatsen-netconf-voucher. (issue #11) 2790 o Removed options 'edit-config' and yang- 2791 patch'. (issue #12) 2793 o Defined how a signature over signed-data returned from a bootstrap 2794 server is processed. (issue #13) 2796 o Added recommendation for removable storage devices to use open/ 2797 standard file systems when possible. (issue #14) 2799 o Replaced notifications "script-[warning/error]" with "[pre/post]- 2800 script-[warning/error]". (goes with issue #15) 2802 o switched owner-certificate to be encoded using the pkcs#7 format. 2803 (issue #16) 2805 o Replaced md5/sha1 with sha256 inside a choice statement, for 2806 future extensibility. (issue #17) 2808 o A ton of editorial changes, as I went thru the entire draft with a 2809 fine-toothed comb. 2811 A.12. 10 to 11 2813 o fixed yang validation issues found by IETFYANGPageCompilation. 2814 note: these issues were NOT found by pyang --ietf or by the 2815 submission-time validator... 2817 o fixed a typo in the yang module, someone the config false 2818 statement was removed. 2820 A.13. 11 to 12 2822 o fixed typo that prevented Appendix B from loading the examples 2823 correctly. 2825 o fixed more yang validation issues found by 2826 IETFYANGPageCompilation. note: again, these issues were NOT found 2827 by pyang --ietf or by the submission-time validator... 2829 o updated a few of the notification enumerations to be more 2830 consistent with the other enumerations (following the warning/ 2831 error pattern). 2833 o updated the information-type artifact to state how it's encoded, 2834 matching the language that was in Appendix B. 2836 A.14. 12 to 13 2838 o defined a standalone artifact to encode the old information-type 2839 into a PKCS#7 structure. 2841 o standalone information artifact hardcodes JSON encoding (to match 2842 the voucher draft). 2844 o combined the information and signature PKCS#7 structures into a 2845 single PKCS#7 structure. 2847 o moved the certificate-revocations into the owner-certificate's 2848 PKCS#7 structure. 2850 o eliminated support for voucher-revocations, to reflect the 2851 voucher-draft's switch from revocations to renewals. 2853 Authors' Addresses 2855 Kent Watsen 2856 Juniper Networks 2858 EMail: kwatsen@juniper.net 2860 Mikael Abrahamsson 2861 T-Systems 2863 EMail: "mikael.abrahamsson@t-systems.se