idnits 2.17.1 draft-ietf-netconf-zerotouch-29.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 420 has weird spacing: '...gorithm ide...' == Line 1477 has weird spacing: '...gorithm ide...' == Line 1865 has weird spacing: '...rmation cms...' == Line 1874 has weird spacing: '...gorithm str...' == Line 2477 has weird spacing: '... string cer...' == (1 more instance...) -- The document date (January 15, 2019) is 1922 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) == Missing Reference: 'RFCXXXX' is mentioned on line 3164, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-02 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-02 == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-15 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 3 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: July 19, 2019 T-Systems 6 I. Farrer 7 Deutsche Telekom AG 8 January 15, 2019 10 Secure Zero Touch Provisioning (SZTP) 11 draft-ietf-netconf-zerotouch-29 13 Abstract 15 This draft presents a technique to securely provision a networking 16 device when it is booting in a factory-default state. Variations in 17 the solution enables it to be used on both public and private 18 networks. The provisioning steps are able to update the boot image, 19 commit an initial configuration, and execute arbitrary scripts to 20 address auxiliary needs. The updated device is subsequently able to 21 establish secure connections with other systems. For instance, a 22 device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) 23 connections with deployment-specific network management systems. 25 Editorial Note (To be removed by RFC Editor) 27 This draft contains many placeholder values that need to be replaced 28 with finalized values at the time of publication. This note 29 summarizes all of the substitutions that are needed. No other RFC 30 Editor instructions are specified elsewhere in this document. 32 Artwork in the IANA Considerations section contains placeholder 33 values for DHCP options pending IANA assignment. Please apply the 34 following replacements: 36 o "TBD1" --> the assigned value for id-ct-sztpConveyedInfoXML 38 o "TBD2" --> the assigned value for id-ct-sztpConveyedInfoJSON 40 o "TBD_IANA_URL" --> the assigned URL for the IANA registry 42 Artwork in this document contains shorthand references to drafts in 43 progress. Please apply the following replacements: 45 o "XXXX" --> the assigned numerical RFC value for this draft 47 Artwork in this document contains placeholder values for the date of 48 publication of this draft. Please apply the following replacement: 50 o "2019-01-15" --> the publication date of this draft 52 The following one Appendix section is to be removed prior to 53 publication: 55 o Appendix D. Change Log 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at https://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on July 19, 2019. 74 Copyright Notice 76 Copyright (c) 2019 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (https://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 92 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 93 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 8 95 1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8 96 2. Types of Conveyed Information . . . . . . . . . . . . . . . . 8 97 2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8 98 2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9 99 3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10 100 3.1. Conveyed Information . . . . . . . . . . . . . . . . . . 10 101 3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 11 102 3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 12 103 3.4. Artifact Encryption . . . . . . . . . . . . . . . . . . . 13 104 3.5. Artifact Groupings . . . . . . . . . . . . . . . . . . . 13 105 4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 14 106 4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 15 107 4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 16 108 4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 19 109 4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 20 110 5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 21 111 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 21 112 5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 23 113 5.3. Processing a Source of Bootstrapping Data . . . . . . . . 25 114 5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 26 115 5.5. Processing Redirect Information . . . . . . . . . . . . . 27 116 5.6. Processing Onboarding Information . . . . . . . . . . . . 28 117 6. The Conveyed Information Data Model . . . . . . . . . . . . . 31 118 6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 31 119 6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 32 120 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 34 121 7. The SZTP Bootstrap Server API . . . . . . . . . . . . . . . . 40 122 7.1. API Overview . . . . . . . . . . . . . . . . . . . . . . 40 123 7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 41 124 7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 44 125 8. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 56 126 8.1. DHCPv4 SZTP Redirect Option . . . . . . . . . . . . . . . 56 127 8.2. DHCPv6 SZTP Redirect Option . . . . . . . . . . . . . . . 57 128 8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 58 129 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 130 9.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 59 131 9.2. Use of IDevID Certificates . . . . . . . . . . . . . . . 59 132 9.3. Immutable Storage for Trust Anchors . . . . . . . . . . . 59 133 9.4. Secure Storage for Long-lived Private Keys . . . . . . . 59 134 9.5. Blindly Authenticating a Bootstrap Server . . . . . . . . 60 135 9.6. Disclosing Information to Untrusted Servers . . . . . . . 60 136 9.7. Sequencing Sources of Bootstrapping Data . . . . . . . . 61 137 9.8. Safety of Private Keys used for Trust . . . . . . . . . . 61 138 9.9. Increased Reliance on Manufacturers . . . . . . . . . . . 62 139 9.10. Concerns with Trusted Bootstrap Servers . . . . . . . . . 62 140 9.11. Validity Period for Conveyed Information . . . . . . . . 63 141 9.12. Cascading Trust via Redirects . . . . . . . . . . . . . . 64 142 9.13. Possible Reuse of Private Keys . . . . . . . . . . . . . 64 143 9.14. Non-Issue with Encrypting Signed Artifacts . . . . . . . 65 144 9.15. The "ietf-sztp-conveyed-info" YANG Module . . . . . . . . 65 145 9.16. The "ietf-sztp-bootstrap-server" YANG Module . . . . . . 66 147 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 148 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 66 149 10.2. The YANG Module Names Registry . . . . . . . . . . . . . 67 150 10.3. The SMI Security for S/MIME CMS Content Type Registry . 67 151 10.4. The BOOTP Manufacturer Extensions and DHCP Options 152 Registry . . . . . . . . . . . . . . . . . . . . . . . . 67 153 10.5. The Dynamic Host Configuration Protocol for IPv6 154 (DHCPv6) Registry . . . . . . . . . . . . . . . . . . . 68 155 10.6. The Service Name and Transport Protocol Port Number 156 Registry . . . . . . . . . . . . . . . . . . . . . . . . 68 157 10.7. The DNS Underscore Global Scoped Entry Registry . . . . 68 158 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 159 11.1. Normative References . . . . . . . . . . . . . . . . . . 69 160 11.2. Informative References . . . . . . . . . . . . . . . . . 71 161 Appendix A. Example Device Data Model . . . . . . . . . . . . . 74 162 A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 74 163 A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 74 164 A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 75 165 Appendix B. Promoting a Connection from Untrusted to Trusted . . 78 166 Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 80 167 C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 80 168 C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 82 169 C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 84 170 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 87 171 D.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 87 172 D.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 87 173 D.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 87 174 D.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 88 175 D.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 88 176 D.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 88 177 D.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 89 178 D.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 89 179 D.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 89 180 D.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 89 181 D.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 89 182 D.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 90 183 D.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 90 184 D.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 90 185 D.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 91 186 D.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 91 187 D.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 91 188 D.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 92 189 D.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 92 190 D.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 93 191 D.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 93 192 D.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 94 193 D.23. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 94 194 D.24. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 94 195 D.25. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 95 196 D.26. 24 to 25 . . . . . . . . . . . . . . . . . . . . . . . . 95 197 D.27. 25 to 26 . . . . . . . . . . . . . . . . . . . . . . . . 96 198 D.28. 26 to 27 . . . . . . . . . . . . . . . . . . . . . . . . 96 199 D.29. 27 to 28 . . . . . . . . . . . . . . . . . . . . . . . . 97 200 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 97 201 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 203 1. Introduction 205 A fundamental business requirement for any network operator is to 206 reduce costs where possible. For network operators, deploying 207 devices to many locations can be a significant cost, as sending 208 trained specialists to each site for installations is both cost 209 prohibitive and does not scale. 211 This document defines Secure Zero Touch Provisioning (SZTP), a 212 bootstrapping strategy enabling devices to securely obtain 213 bootstrapping data with no installer action beyond physical placement 214 and connecting network and power cables. As such, SZTP enables non- 215 technical personnel to bring up devices in remote locations without 216 the need for any operator input. 218 The SZTP solution includes updating the boot image, committing an 219 initial configuration, and executing arbitrary scripts to address 220 auxiliary needs. The updated device is subsequently able to 221 establish secure connections with other systems. For instance, a 222 devices may establish NETCONF [RFC8040] and/or RESTCONF [RFC6241] 223 connections with deployment-specific network management systems. 225 This document primarily regards physical devices, where the setting 226 of the device's initial state, described in Section 5.1, occurs 227 during the device's manufacturing process. The SZTP solution may be 228 extended to support virtual machines or other such logical 229 constructs, but details for how this can be accomplished is left for 230 future work. 232 1.1. Use Cases 234 o Device connecting to a remotely administered network 236 This use-case involves scenarios, such as a remote branch 237 office or convenience store, whereby a device connects as an 238 access gateway to an ISP's network. Assuming it is not 239 possible to customize the ISP's network to provide any 240 bootstrapping support, and with no other nearby device to 241 leverage, the device has no recourse but to reach out to an 242 Internet-based bootstrap server to bootstrap from. 244 o Device connecting to a locally administered network 246 This use-case covers all other scenarios and differs only in 247 that the device may additionally leverage nearby devices, which 248 may direct it to use a local service to bootstrap from. If no 249 such information is available, or the device is unable to use 250 the information provided, it can then reach out to the network 251 just as it would for the remotely administered network use- 252 case. 254 Conceptual workflows for how SZTP might be deployed are provided in 255 Appendix C. 257 1.2. Terminology 259 This document uses the following terms (sorted by name): 261 Artifact: The term "artifact" is used throughout to represent any of 262 the three artifacts defined in Section 3 (conveyed information, 263 ownership voucher, and owner certificate). These artifacts 264 collectively provide all the bootstrapping data a device may use. 266 Bootstrapping Data: The term "bootstrapping data" is used throughout 267 this document to refer to the collection of data that a device 268 may obtain during the bootstrapping process. Specifically, it 269 refers to the three artifacts conveyed information, owner 270 certificate, and ownership voucher, as described in Section 3. 272 Bootstrap Server: The term "bootstrap server" is used within this 273 document to mean any RESTCONF server implementing the YANG module 274 defined in Section 7.3. 276 Conveyed Information: The term "conveyed information" is used herein 277 to refer either redirect information or onboarding information. 278 Conveyed information is one of the three bootstrapping artifacts 279 described in Section 3. 281 Device: The term "device" is used throughout this document to refer 282 to a network element that needs to be bootstrapped. See 283 Section 5 for more information about devices. 285 Manufacturer: The term "manufacturer" is used herein to refer to the 286 manufacturer of a device or a delegate of the manufacturer. 288 Network Management System (NMS): The acronym "NMS" is used 289 throughout this document to refer to the deployment-specific 290 management system that the bootstrapping process is responsible 291 for introducing devices to. From a device's perspective, when 292 the bootstrapping process has completed, the NMS is a NETCONF or 293 RESTCONF client. 295 Onboarding Information: The term "onboarding information" is used 296 herein to refer to one of the two types of "conveyed information" 297 defined in this document, the other being "redirect information". 298 Onboarding information is formally defined by the "onboarding- 299 information" YANG-data structure in Section 6.3. 301 Onboarding Server: The term "onboarding server" is used herein to 302 refer to a bootstrap server that only returns onboarding 303 information. 305 Owner: The term "owner" is used throughout this document to refer to 306 the person or organization that purchased or otherwise owns a 307 device. 309 Owner Certificate: The term "owner certificate" is used in this 310 document to represent an X.509 certificate that binds an owner 311 identity to a public key, which a device can use to validate a 312 signature over the conveyed information artifact. The owner 313 certificate may be communicated along with its chain of 314 intermediate certificates leading up to a known trust anchor. 315 The owner certificate is one of the three bootstrapping artifacts 316 described in Section 3. 318 Ownership Voucher: The term "ownership voucher" is used in this 319 document to represent the voucher artifact defined in [RFC8366]. 320 The ownership voucher is used to assign a device to an owner. 321 The ownership voucher is one of the three bootstrapping artifacts 322 described in Section 3. 324 Redirect Information: The term "redirect information" is used herein 325 to refer to one of the two types of "conveyed information" 326 defined in this document, the other being "onboarding 327 information". Redirect information is formally defined by the 328 "redirect-information" YANG-data structure in Section 6.3. 330 Redirect Server: The term "redirect server" is used to refer to a 331 bootstrap server that only returns redirect information. A 332 redirect server is particularly useful when hosted by a 333 manufacturer, as a well-known (e.g., Internet-based) resource to 334 redirect devices to deployment-specific bootstrap servers. 336 Signed Data: The term "signed data" is used throughout to mean 337 conveyed information that has been signed, specifically by a 338 private key possessed by a device's owner. 340 Unsigned Data: The term "unsigned data" is used throughout to mean 341 conveyed information that has not been signed. 343 1.3. Requirements Language 345 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 346 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 347 "OPTIONAL" in this document are to be interpreted as described in BCP 348 14 [RFC2119] [RFC8174] when, and only when, they appear in all 349 capitals, as shown here. 351 1.4. Tree Diagrams 353 Tree diagrams used in this document follow the notation defined in 354 [RFC8340]. 356 2. Types of Conveyed Information 358 This document defines two types of conveyed information that devices 359 can access during the bootstrapping process. These conveyed 360 information types are described in this section. Examples are 361 provided in Section 6.2 363 2.1. Redirect Information 365 Redirect information redirects a device to another bootstrap server. 366 Redirect information encodes a list of bootstrap servers, each 367 specifying the bootstrap server's hostname (or IP address), an 368 optional port, and an optional trust anchor certificate that the 369 device can use to authenticate the bootstrap server with. 371 Redirect information is YANG modeled data formally defined by the 372 "redirect-information" container in the YANG module presented in 373 Section 6.3. This container has the tree diagram shown below. 375 +--:(redirect-information) 376 +-- redirect-information 377 +-- bootstrap-server* [address] 378 +-- address inet:host 379 +-- port? inet:port-number 380 +-- trust-anchor? cms 382 Redirect information may be trusted or untrusted. The redirect 383 information is trusted whenever it is obtained via a secure 384 connection to a trusted bootstrap server, or whenever it is signed by 385 the device's owner. In all other cases, the redirect information is 386 untrusted. 388 Trusted redirect information is useful for enabling a device to 389 establish a secure connection to a specified bootstrap server, which 390 is possible when the redirect information includes the bootstrap 391 server's trust anchor certificate. 393 Untrusted redirect information is useful for directing a device to a 394 bootstrap server where signed data has been staged for it to obtain. 395 Note that, when the redirect information is untrusted, devices 396 discard any potentially included trust anchor certificates. 398 How devices process redirect information is described in Section 5.5. 400 2.2. Onboarding Information 402 Onboarding information provides data necessary for a device to 403 bootstrap itself and establish secure connections with other systems. 404 As defined in this document, onboarding information can specify 405 details about the boot image a device must be running, specify an 406 initial configuration the device must commit, and specify scripts 407 that the device must successfully execute. 409 Onboarding information is YANG modeled data formally defined by the 410 "onboarding-information" container in the YANG module presented in 411 Section 6.3. This container has the tree diagram shown below. 413 +--:(onboarding-information) 414 +-- onboarding-information 415 +-- boot-image 416 | +-- os-name? string 417 | +-- os-version? string 418 | +-- download-uri* inet:uri 419 | +-- image-verification* [hash-algorithm] 420 | +-- hash-algorithm identityref 421 | +-- hash-value yang:hex-string 422 +-- configuration-handling? enumeration 423 +-- pre-configuration-script? script 424 +-- configuration? binary 425 +-- post-configuration-script? script 427 Onboarding information must be trusted for it to be of any use to a 428 device. There is no option for a device to process untrusted 429 onboarding information. 431 Onboarding information is trusted whenever it is obtained via a 432 secure connection to a trusted bootstrap server, or whenever it is 433 signed by the device's owner. In all other cases, the onboarding 434 information is untrusted. 436 How devices process onboarding information is described in 437 Section 5.6. 439 3. Artifacts 441 This document defines three artifacts that can be made available to 442 devices while they are bootstrapping. Each source of bootstrapping 443 data specifies how it provides the artifacts defined in this section 444 (see Section 4). 446 3.1. Conveyed Information 448 The conveyed information artifact encodes the essential bootstrapping 449 data for the device. This artifact is used to encode the redirect 450 information and onboarding information types discussed in Section 2. 452 The conveyed information artifact is a CMS structure, as described in 453 [RFC5652], encoded using ASN.1 distinguished encoding rules (DER), as 454 specified in ITU-T X.690 [ITU.X690.2015]. The CMS structure MUST 455 contain content conforming to the YANG module specified in 456 Section 6.3. 458 The conveyed information CMS structure may encode signed or unsigned 459 bootstrapping data. When the bootstrapping data is signed, it may 460 also be encrypted but, from a terminology perspective, it is still 461 "signed data" Section 1.2. 463 When the conveyed information artifact is unsigned, as it might be 464 when communicated over trusted channels, the CMS structure's top-most 465 content type MUST be one of the OIDs described in Section 10.3 (i.e., 466 id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON), or the OID 467 id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the 468 encoding (JSON, XML, etc.) SHOULD be communicated externally. In 469 either case, the associated content is an octet string containing 470 "conveyed-information" data in the expected encoding. 472 When the conveyed information artifact is unsigned and encrypted, as 473 it might be when communicated over trusted channels but, for some 474 reason, the operator wants to ensure that only the device is able to 475 see the contents, the CMS structure's top-most content type MUST be 476 the OID id-envelopedData (1.2.840.113549.1.7.3). Furthermore, the 477 encryptedContentInfo's content type MUST be one of the OIDs described 478 in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct- 479 sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1). 480 When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD 481 be communicated externally. In either case, the associated content 482 is an octet string containing "conveyed-information" data in the 483 expected encoding. 485 When the conveyed information artifact is signed, as it might be when 486 communicated over untrusted channels, the CMS structure's top-most 487 content type MUST be the OID id-signedData (1.2.840.113549.1.7.2). 488 Furthermore, the inner eContentType MUST be one of the OIDs described 489 in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct- 490 sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1). 491 When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD 492 be communicated externally. In either case, the associated content 493 or eContent is an octet string containing "conveyed-information" data 494 in the expected encoding. 496 When the conveyed information artifact is signed and encrypted, as it 497 might be when communicated over untrusted channels and privacy is 498 important, the CMS structure's top-most content type MUST be the OID 499 id-envelopedData (1.2.840.113549.1.7.3). Furthermore, the 500 encryptedContentInfo's content type MUST be the OID id-signedData 501 (1.2.840.113549.1.7.2), whose eContentType MUST be one of the OIDs 502 described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct- 503 sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1). 504 When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD 505 be communicated externally. In either case, the associated content 506 or eContent is an octet string containing "conveyed-information" data 507 in the expected encoding. 509 3.2. Owner Certificate 511 The owner certificate artifact is an X.509 certificate [RFC5280] that 512 is used to identify an "owner" (e.g., an organization). The owner 513 certificate can be signed by any certificate authority (CA). The 514 owner certificate either MUST have no Key Usage specified or the Key 515 Usage MUST at least set the "digitalSignature" bit. The values for 516 the owner certificate's "subject" and/or "subjectAltName" are not 517 constrained by this document. 519 The owner certificate is used by a device to verify the signature 520 over the conveyed information artifact (Section 3.1) that the device 521 should have also received, as described in Section 3.5. In 522 particular, the device verifies the signature using the public key in 523 the owner certificate over the content contained within the conveyed 524 information artifact. 526 The owner certificate artifact is formally a CMS structure, as 527 specified by [RFC5652], encoded using ASN.1 distinguished encoding 528 rules (DER), as specified in ITU-T X.690 [ITU.X690.2015]. 530 The owner certificate CMS structure MUST contain the owner 531 certificate itself, as well as all intermediate certificates leading 532 to the "pinned-domain-cert" certificate specified in the ownership 533 voucher. The owner certificate artifact MAY optionally include the 534 "pinned-domain-cert" as well. 536 In order to support devices deployed on private networks, the owner 537 certificate CMS structure MAY also contain suitably fresh, as 538 determined by local policy, revocation objects (e.g., CRLs). Having 539 these revocation objects stapled to the owner certificate may obviate 540 the need for the device to have to download them dynamically using 541 the CRL distribution point or an OCSP responder specified in the 542 associated certificates. 544 When unencrypted, the owner certificate artifact's CMS structure's 545 top-most content type MUST be the OID id-signedData 546 (1.2.840.113549.1.7.2). The inner SignedData structure is the 547 degenerate form, whereby there are no signers, that is commonly used 548 to disseminate certificates and revocation objects. 550 When encrypted, the owner certificate artifact's CMS structure's top- 551 most content type MUST be the OID id-envelopedData 552 (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type 553 MUST be the OID id-signedData (1.2.840.113549.1.7.2), whereby the 554 inner SignedData structure is the degenerate form that has no signers 555 commonly used to disseminate certificates and revocation objects. 557 3.3. Ownership Voucher 559 The ownership voucher artifact is used to securely identify a 560 device's owner, as it is known to the manufacturer. The ownership 561 voucher is signed by the device's manufacturer. 563 The ownership voucher is used to verify the owner certificate 564 (Section 3.2) that the device should have also received, as described 565 in Section 3.5. In particular, the device verifies that the owner 566 certificate has a chain of trust leading to the trusted certificate 567 included in the ownership voucher ("pinned-domain-cert"). Note that 568 this relationship holds even when the owner certificate is a self- 569 signed certificate, and hence also the pinned-domain-cert. 571 When unencrypted, the ownership voucher artifact is as defined in 572 [RFC8366]. As described, it is a CMS structure whose top-most 573 content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), 574 whose eContentType MUST be OID id-ct-animaJSONVoucher 575 (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). 576 When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD 577 be communicated externally. In either case, the associated content 578 is an octet string containing ietf-voucher data in the expected 579 encoding. 581 When encrypted, the ownership voucher artifact's CMS structure's top- 582 most content type MUST be the OID id-envelopedData 583 (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type 584 MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose 585 eContentType MUST be OID id-ct-animaJSONVoucher 586 (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). 587 When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD 588 be communicated externally. In either case, the associated content 589 is an octet string containing ietf-voucher data in the expected 590 encoding. 592 3.4. Artifact Encryption 594 Each of the three artifacts MAY be individually encrypted. 595 Encryption may be important in some environments where the content is 596 considered sensitive. 598 Each of the three artifacts are encrypted in the same way, by the 599 unencrypted form being encapsulated inside a CMS EnvelopedData type. 601 As a consequence, both the conveyed information and ownership voucher 602 artifacts are signed and then encrypted, never encrypted and then 603 signed. 605 This sequencing has the advantage of shrouding the signer's 606 certificate, and ensuring that the owner knows the content being 607 signed. This sequencing further enables the owner to inspect an 608 unencrypted voucher obtained from a manufacturer and then encrypt the 609 voucher later themselves, perhaps while also stapling in current 610 revocation objects, when ready to place the artifact in an unsafe 611 location. 613 When encrypted, the CMS MUST be encrypted using a secure device 614 identity certificate for the device. This certificate MAY be the 615 same as the TLS-level client certificate the device uses when 616 connecting to bootstrap servers. The owner must possess the device's 617 identity certificate at the time of encrypting the data. How the 618 owner comes to posses the device's identity certificate for this 619 purpose is outside the scope of this document. 621 3.5. Artifact Groupings 623 The previous sections discussed the bootstrapping artifacts, but only 624 certain groupings of these artifacts make sense to return in the 625 various bootstrapping situations described in this document. These 626 groupings are: 628 Unsigned Data: This artifact grouping is useful for cases when 629 transport level security can be used to convey trust (e.g., 630 HTTPS), or when the conveyed information can be processed in a 631 provisional manner (i.e. unsigned redirect information). 633 Signed Data, without revocations: This artifact grouping is 634 useful when signed data is needed (i.e., because the data is 635 obtained from an untrusted source and it cannot be processed 636 provisionally) and either revocations are not needed or the 637 revocations can be obtained dynamically. 639 Signed Data, with revocations: This artifact grouping is useful 640 when signed data is needed (i.e., because the data is obtained 641 from an untrusted source and it cannot be processed 642 provisionally), and revocations are needed, and the revocations 643 cannot be obtained dynamically. 645 The presence of each artifact, and any distinguishing 646 characteristics, are identified for each artifact grouping in the 647 table below ("yes/no" regards if the artifact is present in the 648 artifact grouping): 650 +---------------------+---------------+--------------+--------------+ 651 | Artifact | Conveyed | Ownership | Owner | 652 | Grouping | Information | Voucher | Certificate | 653 +=====================+===============+==============+==============+ 654 | Unsigned Data | Yes, no sig | No | No | 655 +---------------------+---------------+--------------+--------------+ 656 | Signed Data, | Yes, with sig | Yes, without | Yes, without | 657 | without revocations | | revocations | revocations | 658 +---------------------+---------------+--------------+--------------+ 659 | Signed Data, | Yes, with sig | Yes, with | Yes, with | 660 | with revocations | | revocations | revocations | 661 +---------------------+---------------+--------------+--------------+ 663 4. Sources of Bootstrapping Data 665 This section defines some sources for bootstrapping data that a 666 device can access. The list of sources defined here is not meant to 667 be exhaustive. It is left to future documents to define additional 668 sources for obtaining bootstrapping data. 670 For each source of bootstrapping data defined in this section, 671 details are given for how the three artifacts listed in Section 3 are 672 provided. 674 4.1. Removable Storage 676 A directly attached removable storage device (e.g., a USB flash 677 drive) MAY be used as a source of SZTP bootstrapping data. 679 Use of a removable storage device is compelling, as it does not 680 require any external infrastructure to work. It is notable that the 681 raw boot image file can also be located on the removable storage 682 device, enabling a removable storage device to be a fully self- 683 standing bootstrapping solution. 685 To use a removable storage device as a source of bootstrapping data, 686 a device need only detect if the removable storage device is plugged 687 in and mount its filesystem. 689 A removable storage device is an untrusted source of bootstrapping 690 data. This means that the information stored on the removable 691 storage device either MUST be signed or MUST be information that can 692 be processed provisionally (e.g., unsigned redirect information). 694 From an artifact perspective, since a removable storage device 695 presents itself as a filesystem, the bootstrapping artifacts need to 696 be presented as files. The three artifacts defined in Section 3 are 697 mapped to files below. 699 Artifact to File Mapping: 701 Conveyed Information: Mapped to a file containing the binary 702 artifact described in Section 3.1 (e.g., conveyed- 703 information.cms). 705 Owner Certificate: Mapped to a file containing the binary 706 artifact described in Section 3.2 (e.g., owner- 707 certificate.cms). 709 Ownership Voucher: Mapped to a file containing the binary 710 artifact described in Section 3.3 (e.g., ownership-voucher.cms 711 or ownership-voucher.vcj). 713 The format of the removable storage device's filesystem and the 714 naming of the files are outside the scope of this document. However, 715 in order to facilitate interoperability, it is RECOMMENDED devices 716 support open and/or standards based filesystems. It is also 717 RECOMMENDED that devices assume a file naming convention that enables 718 more than one instance of bootstrapping data (i.e., for different 719 devices) to exist on a removable storage device. The file naming 720 convention SHOULD additionally be unique to the manufacturer, in 721 order to enable bootstrapping data from multiple manufacturers to 722 exist on a removable storage device. 724 4.2. DNS Server 726 A DNS server MAY be used as a source of SZTP bootstrapping data. 728 Using a DNS server may be a compelling option for deployments having 729 existing DNS infrastructure, as it enables a touchless bootstrapping 730 option that does not entail utilizing an Internet based resource 731 hosted by a 3rd-party. 733 DNS is an untrusted source of bootstrapping data. Even if DNSSEC 734 [RFC6698] is used to authenticate the various DNS resource records 735 (e.g., A, AAAA, CERT, TXT, and TLSA), the device cannot be sure that 736 the domain returned to it from e.g., a DHCP server, belongs to its 737 rightful owner. This means that the information stored in the DNS 738 records either MUST be signed (per this document, not DNSSEC), or 739 MUST be information that can be processed provisionally (e.g., 740 unsigned redirect information). 742 4.2.1. DNS Queries 744 Devices claiming to support DNS as a source of bootstrapping data 745 MUST first query for device-specific DNS records and, only if doing 746 so does not result in a successful bootstrap, then MUST query for 747 device-independent DNS records. 749 For each of the device-specific and device-independent queries, 750 devices MUST first query using multicast DNS [RFC6762] and, only if 751 doing so does not result in a successful bootstrap, then MUST query 752 again using unicast DNS [RFC1035] [RFC7766], assuming the address of 753 a DNS server is known, such as it may be using techniques similar to 754 those described in Section 11 of [RFC6763], which is referenced a few 755 times in this document, even though this document does not itself use 756 DNS-SD (RFC 6763 is identified herein as an Informative reference). 758 When querying for device-specific DNS records, devices MUST query for 759 TXT records [RFC1035] under "._sztp", where is the device's serial number (the same value as in the 761 device's secure device identity certificate), and "_sztp" is the 762 globally scoped DNS attribute registered by this document in 763 Section 10.7. 765 Example device-specific DNS record queries: 767 TXT in ._sztp.local. (multicast) 768 TXT in ._sztp.. (unicast) 770 When querying for device-independent DNS records, devices MUST query 771 for SRV records [RFC2782] under "_sztp._tcp", where "_sztp" is the 772 service name registered by this document in Section 10.6, and "_tcp" 773 is the globally scoped DNS attribute registered by 774 [I-D.ietf-dnsop-attrleaf]. 776 Note that a device-independent response is anyway only able to encode 777 unsigned data, since signed data necessitates the use of a device- 778 specific ownership voucher. Use of SRV records maximumly leverages 779 existing DNS standards. A response containing multiple SRV records 780 is comparable to an unsigned redirect information's list of bootstrap 781 servers. 783 Example device-independent DNS record queries: 785 SRV in _sztp._tcp.local. (multicast) 786 SRV in _sztp._tcp.. (unicast) 788 4.2.2. DNS Response for Device-Specific Queries 790 For device-specific queries, the three bootstrapping artifacts 791 defined in Section 3 are encoded into the TXT records using key/value 792 pairs, similar to the technique described in Section 6.3 of 793 [RFC6763]. 795 Artifact to TXT Record Mapping: 797 Conveyed Information: Mapped to a TXT record having the key "ci" 798 and the value being the binary artifact described in 799 Section 3.1. 801 Owner Certificate: Mapped to a TXT record having the key "oc" and 802 the value being the binary artifact described in Section 3.2. 804 Ownership Voucher: Mapped to a TXT record having the key "ov" and 805 the value being the binary artifact described in Section 3.3. 807 Devices MUST ignore any other keys that may be returned. 809 Note that, despite the name, TXT records can and SHOULD (per 810 Section 6.5 of [RFC6763]) encode binary data. 812 Following is an example of a device-specific response, as it might be 813 presented by a user-agent, containing signed data. This example 814 assumes that the device's serial number is "", the 815 domain is "example.com", and that "" represents the 816 binary artifact: 818 ._sztp.example.com. 3600 IN TXT "ci=" 819 ._sztp.example.com. 3600 IN TXT "oc=" 820 ._sztp.example.com. 3600 IN TXT "ov=" 822 Note that, in the case that "ci" encodes unsigned data, the "oc" and 823 "ov" keys would not be present in the response. 825 4.2.3. DNS Response for Device-Independent Queries 827 For device-independent queries, the three bootstrapping artifacts 828 defined in Section 3 are encoded into the SVR records as follows. 830 Artifact to SRV Record Mapping: 832 Conveyed Information: This artifact is not supported directly. 833 Instead, the essence of unsigned redirect information is mapped 834 to SVR records per [RFC2782]. 836 Owner Certificate: Not supported. Device-independent responses 837 are never encode signed data, and hence there is no need for an 838 owner certificate artifact. 840 Ownership Voucher: Not supported. Device-independent responses 841 are never encode signed data, and hence there is no need for an 842 ownership voucher artifact. 844 Following is an example of a device-independent response, as it might 845 be presented by a user-agent, containing (effectively) unsigned 846 redirect information to four bootstrap servers. This example assumes 847 that the domain is "example.com" and that there are four bootstrap 848 servers "sztp[1-4]": 850 _sztp._tcp.example.com. 1800 IN SRV 0 0 443 sztp1.example.com. 851 _sztp._tcp.example.com. 1800 IN SRV 1 0 443 sztp2.example.com. 852 _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp3.example.com. 853 _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp4.example.com. 855 Note that, in this example, "sztp3" and "sztp4" have equal priority, 856 and hence effectively represent a clustered pair of bootstrap 857 servers. While "sztp1" and "sztp2" only have a single SRV record 858 each, it may be that the record points to a load-balancer fronting a 859 cluster of bootstrap servers. 861 While this document does not use DNS-SD [RFC6763], per Section 12.2 862 of that RFC, mDNS responses SHOULD also include all address records 863 (type "A" and "AAAA") named in the SRV rdata. 865 4.2.4. Size of Signed Data 867 The signed data artifacts are large by DNS conventions. In the 868 smallest-footprint scenario, they are each a few kilobytes in size. 869 However, onboarding information can easily be several kilobytes in 870 size, and has the potential to be many kilobytes in size. 872 All resource records, including TXT records, have an upper size limit 873 of 65535 bytes, since "RDLENGTH" is a 16-bit field (Section 3.2.1 in 874 [RFC1035]). If it is ever desired to encode onboarding information 875 that exceeds this limit, the DNS records returned should instead 876 encode redirect information, to direct the device to a bootstrap 877 server from which the onboarding information can be obtained. 879 Given the expected size of the TXT records, it is unlikely that 880 signed data will fit into a UDP-based DNS packet, even with the 881 EDNS(0) Extensions [RFC6891] enabled. Depending on content, signed 882 data may also not fit into a multicast DNS packet, which bounds the 883 size to 9000 bytes, per Section 17 in [RFC6762]. Thus it is expected 884 that DNS Transport over TCP [RFC7766] will be required in order to 885 return signed data. 887 4.3. DHCP Server 889 A DHCP server MAY be used as a source of SZTP bootstrapping data. 891 Using a DHCP server may be a compelling option for deployments having 892 existing DHCP infrastructure, as it enables a touchless bootstrapping 893 option that does not entail utilizing an Internet based resource 894 hosted by a 3rd-party. 896 A DHCP server is an untrusted source of bootstrapping data. Thus the 897 information stored on the DHCP server either MUST be signed, or it 898 MUST be information that can be processed provisionally (e.g., 899 unsigned redirect information). 901 However, unlike other sources of bootstrapping data described in this 902 document, the DHCP protocol (especially DHCP for IPv4) is very 903 limited in the amount of data that can be conveyed, to the extent 904 that signed data cannot be communicated. This means that only 905 unsigned redirect information can be conveyed via DHCP. 907 Since the redirect information is unsigned, it SHOULD NOT include the 908 optional trust anchor certificate, as it takes up space in the DHCP 909 message, and the device would have to discard it anyway. For this 910 reason, the DHCP options defined in Section 8 do not enable the trust 911 anchor certificate to be encoded. 913 From an artifact perspective, the three artifacts defined in 914 Section 3 are mapped to the DHCP fields specified in Section 8 as 915 follows. 917 Artifact to DHCP Option Fields Mapping: 919 Conveyed Information: This artifact is not supported directly. 920 Instead, the essence of unsigned redirect information is mapped 921 to the DHCP options described in Section 8. 923 Owner Certificate: Not supported. There is not enough space in 924 the DHCP packet to hold an owner certificate artifact. 926 Ownership Voucher: Not supported. There is not enough space in 927 the DHCP packet to hold an ownership voucher artifact. 929 4.4. Bootstrap Server 931 A bootstrap server MAY be used as a source of SZTP bootstrapping 932 data. A bootstrap server is defined as a RESTCONF [RFC8040] server 933 implementing the YANG module provided in Section 7. 935 Using a bootstrap server as a source of bootstrapping data is a 936 compelling option as it MAY use transport-level security, obviating 937 the need for signed data, which may be easier to deploy in some 938 situations. 940 Unlike any other source of bootstrapping data described in this 941 document, a bootstrap server is not only a source of data, but it can 942 also receive data from devices using the YANG-defined "report- 943 progress" RPC defined in the YANG module (Section 7.3). The "report- 944 progress" RPC enables visibility into the bootstrapping process 945 (e.g., warnings and errors), and provides potentially useful 946 information upon completion (e.g., the device's SSH host-keys). 948 A bootstrap server may be a trusted or an untrusted source of 949 bootstrapping data, depending on if the device learned about the 950 bootstrap server's trust anchor from a trusted source. When a 951 bootstrap server is trusted, the conveyed information returned from 952 it MAY be signed. When the bootstrap server is untrusted, the 953 conveyed information either MUST be signed or MUST be information 954 that can be processed provisionally (e.g., unsigned redirect 955 information). 957 From an artifact perspective, since a bootstrap server presents data 958 conforming to a YANG data model, the bootstrapping artifacts need to 959 be mapped to YANG nodes. The three artifacts defined in Section 3 960 are mapped to "output" nodes of the "get-bootstrapping-data" RPC 961 defined in Section 7.3 below. 963 Artifact to Bootstrap Server Mapping: 965 Conveyed Information: Mapped to the "conveyed-information" leaf 966 in the output of the "get-bootstrapping-data" RPC. 968 Owner Certificate: Mapped to the "owner-certificate" leaf in the 969 output of the "get-bootstrapping-data" RPC. 971 Ownership Voucher: Mapped to the "ownership-voucher" leaf in the 972 output of the "get-bootstrapping-data" RPC. 974 SZTP bootstrap servers have only two endpoints, one for the "get- 975 bootstrapping-data" RPC and one for the "report-progress" RPC. These 976 RPCs use the authenticated RESTCONF username to isolate the execution 977 of the RPC from other devices. 979 5. Device Details 981 Devices supporting the bootstrapping strategy described in this 982 document MUST have the preconfigured state and bootstrapping logic 983 described in the following sections. 985 5.1. Initial State 986 +-------------------------------------------------------------+ 987 | | 988 | | 989 | +---------------------------------------------------------+ | 990 | | | | 991 | | | | 992 | | 1. flag to enable SZTP bootstrapping set to "true" | | 993 | +---------------------------------------------------------+ | 994 | | 995 | +---------------------------------------------------------+ | 996 | | | | 997 | | | | 998 | | 2. TLS client cert & related intermediate certificates | | 999 | | 3. list of trusted well-known bootstrap servers | | 1000 | | 4. list of trust anchor certs for bootstrap servers | | 1001 | | 5. list of trust anchor certs for ownership vouchers | | 1002 | +---------------------------------------------------------+ | 1003 | | 1004 | +-----------------------------------------------------+ | 1005 | | | | 1006 | | | | 1007 | | 6. private key for TLS client certificate | | 1008 | | 7. private key for decrypting SZTP artifacts | | 1009 | +-----------------------------------------------------+ | 1010 | | 1011 +-------------------------------------------------------------+ 1013 Each numbered item below corresponds to a numbered item in the 1014 diagram above. 1016 1. Devices MUST have a configurable variable that is used to enable/ 1017 disable SZTP bootstrapping. This variable MUST be enabled by 1018 default in order for SZTP bootstrapping to run when the device 1019 first powers on. Because it is a goal that the configuration 1020 installed by the bootstrapping process disables SZTP 1021 bootstrapping, and because the configuration may be merged into 1022 the existing configuration, using a configuration node that 1023 relies on presence is NOT RECOMMENDED, as it cannot be removed by 1024 the merging process. 1026 2. Devices that support loading bootstrapping data from bootstrap 1027 servers (see Section 4.4) SHOULD possess a TLS-level client 1028 certificate and any intermediate certificates leading to the 1029 certificate's well-known trust-anchor. The well-known trust 1030 anchor certificate may be an intermediate certificate or a self- 1031 signed root certificate. To support devices not having a client 1032 certificate, devices MAY, alternatively or in addition to, 1033 identify and authenticate themselves to the bootstrap server 1034 using an HTTP authentication scheme, as allowed by Section 2.5 in 1035 [RFC8040]; however, this document does not define a mechanism for 1036 operator input enabling, for example, the entering of a password. 1038 3. Devices that support loading bootstrapping data from well-known 1039 bootstrap servers MUST possess a list of the well-known bootstrap 1040 servers. Consistent with redirect information (Section 2.1, each 1041 bootstrap server can be identified by its hostname or IP address, 1042 and an optional port. 1044 4. Devices that support loading bootstrapping data from well-known 1045 bootstrap servers MUST also possess a list of trust anchor 1046 certificates that can be used to authenticate the well-known 1047 bootstrap servers. For each trust anchor certificate, if it is 1048 not itself a self-signed root certificate, the device SHOULD also 1049 possess the chain of intermediate certificates leading up to and 1050 including the self-signed root certificate. 1052 5. Devices that support loading signed data (see Section 1.2) MUST 1053 possess the trust anchor certificates for validating ownership 1054 vouchers. For each trust anchor certificate, if it is not itself 1055 a self-signed root certificate, the device SHOULD also possess 1056 the chain of intermediate certificates leading up to and 1057 including the self-signed root certificate. 1059 6. Devices that support using a TLS-level client certificate to 1060 identify and authenticate themselves to a bootstrap server MUST 1061 possess the private key that corresponds to the public key 1062 encoded in the TLS-level client certificate. This private key 1063 SHOULD be securely stored, ideally in a cryptographic processor, 1064 such as a trusted platform module (TPM) chip. 1066 7. Devices that support decrypting SZTP artifacts MUST posses the 1067 private key that corresponds to the public key encoded in the 1068 secure device identity certificate used when encrypting the 1069 artifacts. This private key SHOULD be securely stored, ideally 1070 in a cryptographic processor, such as a trusted platform module 1071 (TPM) chip. This private key MAY be the same as the one 1072 associated to the TLS-level client certificate used when 1073 connecting to bootstrap servers. 1075 A YANG module representing this data is provided in Appendix A. 1077 5.2. Boot Sequence 1079 A device claiming to support the bootstrapping strategy defined in 1080 this document MUST support the boot sequence described in this 1081 section. 1083 Power On 1084 | 1085 v No 1086 1. SZTP bootstrapping configured ------> Boot normally 1087 | 1088 | Yes 1089 v 1090 2. For each supported source of bootstrapping data, 1091 try to load bootstrapping data from the source 1092 | 1093 | 1094 v Yes 1095 3. Able to bootstrap from any source? -----> Run with new config 1096 | 1097 | No 1098 v 1099 4. Loop back to Step 1. 1101 Note: At any time, the device MAY be configured via an alternate 1102 provisioning mechanism (e.g., CLI). 1104 Each numbered item below corresponds to a numbered item in the 1105 diagram above. 1107 1. When the device powers on, it first checks to see if SZTP 1108 bootstrapping is configured, as is expected to be the case for 1109 the device's preconfigured initial state. If SZTP bootstrapping 1110 is not configured, then the device boots normally. 1112 2. The device iterates over its list of sources for bootstrapping 1113 data (Section 4). Details for how to processes a source of 1114 bootstrapping data are provided in Section 5.3. 1116 3. If the device is able to bootstrap itself from any of the sources 1117 of bootstrapping data, it runs with the new bootstrapped 1118 configuration. 1120 4. Otherwise the device MUST loop back through the list of 1121 bootstrapping sources again. 1123 This document does not limit the simultaneous use of alternate 1124 provisioning mechanisms. Such mechanisms may include, for instance, 1125 a command line interface (CLI), a web-based user interface, or even 1126 another bootstrapping protocol. Regardless how it is configured, the 1127 configuration SHOULD unset the flag enabling SZTP bootstrapping 1128 discussed in Section 5.1. 1130 5.3. Processing a Source of Bootstrapping Data 1132 This section describes a recursive algorithm that devices can use to, 1133 ultimately, obtain onboarding information. The algorithm is 1134 recursive because sources of bootstrapping data may return redirect 1135 information, which causes the algorithm to run again, for the newly 1136 discovered sources of bootstrapping data. An expression that 1137 captures all possible successful sequences of bootstrapping data is: 1138 zero or more redirect information responses, followed by one 1139 onboarding information response. 1141 An important aspect of the algorithm is knowing when data needs to be 1142 signed or not. The following figure provides a summary of options: 1144 Untrusted Source Trusted Source 1145 Kind of Bootstrapping Data Can Provide? Can Provide? 1147 Unsigned Redirect Info : Yes+ Yes 1148 Signed Redirect Info : Yes Yes* 1149 Unsigned Onboarding Info : No Yes 1150 Signed Onboarding Info : Yes Yes* 1152 The '+' above denotes that the source redirected to MUST 1153 return signed data, or more unsigned redirect information. 1155 The '*' above denotes that, while possible, it is generally 1156 unnecessary for a trusted source to return signed data. 1158 The recursive algorithm uses a conceptual global-scoped variable 1159 called "trust-state". The trust-state variable is initialized to 1160 FALSE. The ultimate goal of this algorithm is for the device to 1161 process onboarding information (Section 2.2) while the trust-state 1162 variable is TRUE. 1164 If the source of bootstrapping data (Section 4) is a bootstrap server 1165 (Section 4.4), and the device is able to authenticate the bootstrap 1166 server using X.509 certificate path validation ([RFC6125], Section 6) 1167 to one of the device's preconfigured trust anchors, or to a trust 1168 anchor that it learned from a previous step, then the device MUST set 1169 trust-state to TRUE. 1171 When establishing a connection to a bootstrap server, whether trusted 1172 or untrusted, the device MUST identify and authenticate itself to the 1173 bootstrap server using a TLS-level client certificate and/or an HTTP 1174 authentication scheme, per Section 2.5 in [RFC8040]. If both 1175 authentication mechanisms are used, they MUST both identify the same 1176 serial number. 1178 When sending a client certificate, the device MUST also send all of 1179 the intermediate certificates leading up to, and optionally 1180 including, the client certificate's well-known trust anchor 1181 certificate. 1183 For any source of bootstrapping data (e.g., Section 4), if any 1184 artifact obtained is encrypted, the device MUST first decrypt it 1185 using the private key associated with the device certificate used to 1186 encrypt the artifact. 1188 If the conveyed information artifact is signed, and the device is 1189 able to validate the signed data using the algorithm described in 1190 Section 5.4, then the device MUST set trust-state to TRUE; otherwise, 1191 if the device is unable to validate the signed data, the device MUST 1192 set trust-state to FALSE. Note, this is worded to cover the special 1193 case when signed data is returned even from a trusted source of 1194 bootstrapping data. 1196 If the conveyed information artifact contains redirect information, 1197 the device MUST, within limits of how many recursive loops the device 1198 allows, process the redirect information as described in Section 5.5. 1199 Implementations MUST limit the maximum number of recursive redirects 1200 allowed; the maximum number of recursive redirects allowed SHOULD be 1201 no more than ten. This is the recursion step, it will cause the 1202 device to reenter this algorithm, but this time the data source will 1203 definitely be a bootstrap server, as redirect information is only 1204 able to redirect devices to bootstrap servers. 1206 If the conveyed information artifact contains onboarding information, 1207 and trust-state is FALSE, the device MUST exit the recursive 1208 algorithm (as this is not allowed, see the figure above), returning 1209 to the bootstrapping sequence described in Section 5.2. Otherwise, 1210 the device MUST attempt to process the onboarding information as 1211 described in Section 5.6. Whether the processing of the onboarding 1212 information succeeds or fails, the device MUST exit the recursive 1213 algorithm, returning to the bootstrapping sequence described in 1214 Section 5.2, the only difference being in how it responds to the 1215 "Able to bootstrap from any source?" conditional described in the 1216 figure in the section. 1218 5.4. Validating Signed Data 1220 Whenever a device is presented signed data, it MUST validate the 1221 signed data as described in this section. This includes the case 1222 where the signed data is provided by a trusted source. 1224 Whenever there is signed data, the device MUST also be provided an 1225 ownership voucher and an owner certificate. How all the needed 1226 artifacts are provided for each source of bootstrapping data is 1227 described in Section 4. 1229 In order to validate signed data, the device MUST first authenticate 1230 the ownership voucher by validating its signature to one of its 1231 preconfigured trust anchors (see Section 5.1), which may entail using 1232 additional intermediate certificates attached to the ownership 1233 voucher. If the device has an accurate clock, it MUST verify that 1234 the ownership voucher was created in the past (i.e., "created-on" < 1235 now) and, if the "expires-on" leaf is present, the device MUST verify 1236 that the ownership voucher has not yet expired (i.e., now < "expires- 1237 on"). The device MUST verify that the ownership voucher's 1238 "assertion" value is acceptable (e.g., some devices may only accept 1239 the assertion value "verified"). The device MUST verify that the 1240 ownership voucher specifies the device's serial number in the 1241 "serial-number" leaf. If the "idevid-issuer" leaf is present, the 1242 device MUST verify that the value is set correctly. If the 1243 authentication of the ownership voucher is successful, the device 1244 extracts the "pinned-domain-cert" node, an X.509 certificate, that is 1245 needed to verify the owner certificate in the next step. 1247 The device MUST next authenticate the owner certificate by performing 1248 X.509 certificate path verification to the trusted certificate 1249 extracted from the ownership voucher's "pinned-domain-cert" node. 1250 This verification may entail using additional intermediate 1251 certificates attached to the owner certificate artifact. If the 1252 ownership voucher's "domain-cert-revocation-checks" node's value is 1253 set to "true", the device MUST verify the revocation status of the 1254 certificate chain used to sign the owner certificate and, if 1255 suitably-fresh revocation status is unattainable or if it is 1256 determined that a certificate has been revoked, the device MUST NOT 1257 validate the owner certificate. 1259 Finally, the device MUST verify that the conveyed information 1260 artifact was signed by the validated owner certificate. 1262 If any of these steps fail, the device MUST invalidate the signed 1263 data and not perform any subsequent steps. 1265 5.5. Processing Redirect Information 1267 In order to process redirect information (Section 2.1), the device 1268 MUST follow the steps presented in this section. 1270 Processing redirect information is straightforward; the device 1271 sequentially steps through the list of provided bootstrap servers 1272 until it can find one it can bootstrap from. 1274 If a hostname is provided, and the hostname's DNS resolution is to 1275 more than one IP address, the device MUST attempt to connect to all 1276 of the DNS resolved addresses at least once, before moving on to the 1277 next bootstrap server. If the device is able to obtain bootstrapping 1278 data from any of the DNS resolved addresses, it MUST immediately 1279 process that data, without attempting to connect to any of the other 1280 DNS resolved addresses. 1282 If the redirect information is trusted (e.g., trust-state is TRUE), 1283 and the bootstrap server entry contains a trust anchor certificate, 1284 then the device MUST authenticate the specified bootstrap server's 1285 TLS server certificate using X.509 certificate path validation 1286 ([RFC6125], Section 6) to the specified trust anchor. If the 1287 bootstrap server entry does not contain a trust anchor certificate 1288 device, the device MUST establish a provisional connection to the 1289 bootstrap server (i.e., by blindly accepting its server certificate), 1290 and set trust-state to FALSE. 1292 If the redirect information is untrusted (e.g., trust-state is 1293 FALSE), the device MUST discard any trust anchors provided by the 1294 redirect information and establish a provisional connection to the 1295 bootstrap server (i.e., by blindly accepting its TLS server 1296 certificate). 1298 5.6. Processing Onboarding Information 1300 In order to process onboarding information (Section 2.2), the device 1301 MUST follow the steps presented in this section. 1303 When processing onboarding information, the device MUST first process 1304 the boot image information (if any), then execute the pre- 1305 configuration script (if any), then commit the initial configuration 1306 (if any), and then execute the post-configuration script (if any), in 1307 that order. 1309 When the onboarding information is obtained from a trusted bootstrap 1310 server, the device MUST send the "bootstrap-initiated" progress 1311 report, and send either a terminating "boot-image-installed- 1312 rebooting", "bootstrap-complete", or error specific progress report. 1313 If the bootstrap server's "get-bootstrapping-data" RPC-reply's 1314 "reporting-level" node is set to "verbose", the device MUST 1315 additionally send all appropriate non-terminating progress reports 1316 (e.g., initiated, warning, complete, etc.). Regardless of the 1317 reporting-level indicated by the bootstrap server, the device MAY 1318 send progress reports beyond the mandatory ones specified for the 1319 given reporting level. 1321 When the onboarding information is obtained from an untrusted 1322 bootstrap server, the device MUST NOT send any progress reports to 1323 the bootstrap server, even though the onboarding information was, 1324 necessarily, signed and authenticated. Please be aware that 1325 bootstrap servers are recommended to promote untrusted connections to 1326 trusted connections, in the last paragraph of Section 9.6, so as to, 1327 in part, be able to collect progress reports from devices. 1329 If the device encounters an error at any step, it MUST stop 1330 processing the onboarding information and return to the bootstrapping 1331 sequence described in Section 5.2. In the context of a recursive 1332 algorithm, the device MUST return to the enclosing loop, not back to 1333 the very beginning. Some state MAY be retained from the 1334 bootstrapping process (e.g., updated boot image, logs, remnants from 1335 a script, etc.). However, the retained state MUST NOT be active in 1336 any way (e.g., no new configuration or running of software), and MUST 1337 NOT hinder the ability for the device to continue the bootstrapping 1338 sequence (i.e., process onboarding information from another bootstrap 1339 server). 1341 At this point, the specific ordered sequence of actions the device 1342 MUST perform is described. 1344 If the onboarding information is obtained from a trusted bootstrap 1345 server, the device MUST send a "bootstrap-initiated" progress report. 1346 It is an error if the device does not receive back the "204 No 1347 Content" HTTP status line. If an error occurs, the device MUST try 1348 to send a "bootstrap-error" progress report before exiting. 1350 The device MUST parse the provided onboarding information document, 1351 to extract values used in subsequent steps. Whether using a stream- 1352 based parser or not, if there is an error when parsing the onboarding 1353 information, and the device is connected to a trusted bootstrap 1354 server, the device MUST try to send a "parsing-error" progress report 1355 before exiting. 1357 If boot image criteria are specified, the device MUST first determine 1358 if the boot image it is running satisfies the specified boot image 1359 criteria. If the device is already running the specified boot image, 1360 then it skips the remainder of this step. If the device is not 1361 running the specified boot image, then it MUST download, verify, and 1362 install, in that order, the specified boot image, and then reboot. 1363 If connected to a trusted bootstrap server, the device MAY try to 1364 send a "boot-image-mismatch" progress report. To download the boot 1365 image, the device MUST only use the URIs supplied by the onboarding 1366 information. To verify the boot image, the device MUST either use 1367 one of the verification fingerprints supplied by the onboarding 1368 information, or use a cryptographic signature embedded into the boot 1369 image itself using a mechanism not described by this document. 1370 Before rebooting, if connected to a trusted bootstrap server, the 1371 device MUST try to send a "boot-image-installed-rebooting" progress 1372 report. Upon rebooting, the bootstrapping process runs again, which 1373 will eventually come to this step again, but then the device will be 1374 running the specified boot image, and thus will move to processing 1375 the next step. If an error occurs at any step while the device is 1376 connected to a trusted bootstrap server (i.e., before the reboot), 1377 the device MUST try to send a "boot-image-error" progress report 1378 before exiting. 1380 If a pre-configuration script has been specified, the device MUST 1381 execute the script, capture any output emitted from the script, and 1382 check if the script had any warnings or errors. If an error occurs 1383 while the device is connected to a trusted bootstrap server, the 1384 device MUST try to send a "pre-script-error" progress report before 1385 exiting. 1387 If an initial configuration has been specified, the device MUST 1388 atomically commit the provided initial configuration, using the 1389 approach specified by the "configuration-handling" leaf. If an error 1390 occurs while the device is connected to a trusted bootstrap server, 1391 the device MUST try to send a "config-error" progress report before 1392 exiting. 1394 If a post-configuration script has been specified, the device MUST 1395 execute the script, capture any output emitted from the script, and 1396 check if the script had any warnings or errors. If an error occurs 1397 while the device is connected to a trusted bootstrap server, the 1398 device MUST try to send a "post-script-error" progress report before 1399 exiting. 1401 If the onboarding information was obtained from a trusted bootstrap 1402 server, and the result of the bootstrapping process did not disable 1403 the "flag to enable SZTP bootstrapping" described in Section 5.1, the 1404 device SHOULD send an "bootstrap-warning" progress report. 1406 If the onboarding information was obtained from a trusted bootstrap 1407 server, the device MUST send a "bootstrap-complete" progress report. 1408 It is an error if the device does not receive back the "204 No 1409 Content" HTTP status line. If an error occurs, the device MUST try 1410 to send a "bootstrap-error" progress report before exiting. 1412 At this point, the device has completely processed the bootstrapping 1413 data. 1415 The device is now running its initial configuration. Notably, if 1416 NETCONF Call Home or RESTCONF Call Home [RFC8071] is configured, the 1417 device initiates trying to establish the call home connections at 1418 this time. 1420 Implementation Notes: 1422 Implementations may vary in how to ensure no unwanted state is 1423 retained when an error occurs. 1425 Following are some guidelines for if the implementation chooses to 1426 undo previous steps: 1428 * When an error occurs, the device must rollback the current step 1429 and any previous steps. 1431 * Most steps are atomic. For example, the processing of a 1432 configuration is specified above as atomic, and the processing 1433 of scripts is similarly specified as atomic in the "ietf-sztp- 1434 conveyed-info" YANG module. 1436 * In case the error occurs after the initial configuration was 1437 committed, the device must restore the configuration to the 1438 configuration that existed prior to the configuration being 1439 committed. 1441 * In case the error occurs after a script had executed 1442 successfully, it may be helpful for the implementation to 1443 define scripts as being able to take a conceptual input 1444 parameter indicating that the script should remove its 1445 previously set state. 1447 6. The Conveyed Information Data Model 1449 This section defines a YANG 1.1 [RFC7950] module that is used to 1450 define the data model for the conveyed information artifact described 1451 in Section 3.1. This data model uses the "yang-data" extension 1452 statement defined in [RFC8040]. Examples illustrating this data 1453 model are provided in Section 6.2. 1455 6.1. Data Model Overview 1457 The following tree diagram provides an overview of the data model for 1458 the conveyed information artifact. 1460 module: ietf-sztp-conveyed-info 1462 yang-data conveyed-information: 1463 +-- (information-type) 1464 +--:(redirect-information) 1465 | +-- redirect-information 1466 | +-- bootstrap-server* [address] 1467 | +-- address inet:host 1468 | +-- port? inet:port-number 1469 | +-- trust-anchor? cms 1470 +--:(onboarding-information) 1471 +-- onboarding-information 1472 +-- boot-image 1473 | +-- os-name? string 1474 | +-- os-version? string 1475 | +-- download-uri* inet:uri 1476 | +-- image-verification* [hash-algorithm] 1477 | +-- hash-algorithm identityref 1478 | +-- hash-value yang:hex-string 1479 +-- configuration-handling? enumeration 1480 +-- pre-configuration-script? script 1481 +-- configuration? binary 1482 +-- post-configuration-script? script 1484 6.2. Example Usage 1486 The following example illustrates how redirect information 1487 (Section 2.1) can be encoded using JSON. 1489 { 1490 "ietf-sztp-conveyed-info:redirect-information" : { 1491 "bootstrap-server" : [ 1492 { 1493 "address" : "sztp1.example.com", 1494 "port" : 8443, 1495 "trust-anchor" : "base64encodedvalue==" 1496 }, 1497 { 1498 "address" : "sztp2.example.com", 1499 "port" : 8443, 1500 "trust-anchor" : "base64encodedvalue==" 1501 }, 1502 { 1503 "address" : "sztp3.example.com", 1504 "port" : 8443, 1505 "trust-anchor" : "base64encodedvalue==" 1506 } 1507 ] 1508 } 1509 } 1511 The following example illustrates how onboarding information 1512 (Section 2.2) can be encoded using JSON. 1514 [Note: '\' line wrapping for formatting only] 1516 { 1517 "ietf-sztp-conveyed-info:onboarding-information" : { 1518 "boot-image" : { 1519 "os-name" : "VendorOS", 1520 "os-version" : "17.2R1.6", 1521 "download-uri" : [ "http://some/path/to/raw/file" ], 1522 "image-verification" : [ 1523 { 1524 "hash-algorithm" : "ietf-sztp-conveyed-info:sha-256", 1525 "hash-value" : "ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:\ 1526 7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33" 1527 } 1528 ] 1529 }, 1530 "configuration-handling" : "merge", 1531 "pre-configuration-script" : "base64encodedvalue==", 1532 "configuration" : "base64encodedvalue==", 1533 "post-configuration-script" : "base64encodedvalue==" 1534 } 1535 } 1537 6.3. YANG Module 1539 The conveyed information data model is defined by the YANG module 1540 presented in this section. 1542 This module uses data types defined in [RFC5280], [RFC5652], 1543 [RFC6234], and [RFC6991], an extension statement from [RFC8040], and 1544 an encoding defined in [ITU.X690.2015]. 1546 file "ietf-sztp-conveyed-info@2019-01-15.yang" 1547 module ietf-sztp-conveyed-info { 1548 yang-version 1.1; 1549 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info"; 1550 prefix sztp-info; 1552 import ietf-yang-types { 1553 prefix yang; 1554 reference "RFC 6991: Common YANG Data Types"; 1555 } 1556 import ietf-inet-types { 1557 prefix inet; 1558 reference "RFC 6991: Common YANG Data Types"; 1559 } 1560 import ietf-restconf { 1561 prefix rc; 1562 reference "RFC 8040: RESTCONF Protocol"; 1563 } 1565 organization 1566 "IETF NETCONF (Network Configuration) Working Group"; 1568 contact 1569 "WG Web: http://tools.ietf.org/wg/netconf 1570 WG List: 1571 Author: Kent Watsen "; 1573 description 1574 "This module defines the data model for the Conveyed 1575 Information artifact defined in RFC XXXX: Secure Zero Touch 1576 Provisioning (SZTP). 1578 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1579 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1580 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1581 are to be interpreted as described in BCP 14 (RFC 2119, 1582 RFC 8174) when, and only when, they appear in all 1583 capitals, as shown here. 1585 Copyright (c) 2019 IETF Trust and the persons identified as 1586 authors of the code. All rights reserved. 1588 Redistribution and use in source and binary forms, with or 1589 without modification, is permitted pursuant to, and subject 1590 to the license terms contained in, the Simplified BSD License 1591 set forth in Section 4.c of the IETF Trust's Legal Provisions 1592 Relating to IETF Documents (http://trustee.ietf.org/license-info) 1594 This version of this YANG module is part of RFC XXXX; see the 1595 RFC itself for full legal notices."; 1597 revision 2019-01-15 { 1598 description 1599 "Initial version"; 1600 reference 1601 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 1602 } 1604 // identities 1606 identity hash-algorithm { 1607 description 1608 "A base identity for hash algorithm verification"; 1609 } 1611 identity sha-256 { 1612 base "hash-algorithm"; 1613 description "The SHA-256 algorithm."; 1614 reference "RFC 6234: US Secure Hash Algorithms."; 1615 } 1617 // typedefs 1619 typedef cms { 1620 type binary; 1621 description 1622 "A ContentInfo structure, as specified in RFC 5652, 1623 encoded using ASN.1 distinguished encoding rules (DER), 1624 as specified in ITU-T X.690."; 1625 reference 1626 "RFC 5652: 1627 Cryptographic Message Syntax (CMS) 1628 ITU-T X.690: 1629 Information technology - ASN.1 encoding rules: 1630 Specification of Basic Encoding Rules (BER), 1631 Canonical Encoding Rules (CER) and Distinguished 1632 Encoding Rules (DER)."; 1634 } 1636 // yang-data 1638 rc:yang-data "conveyed-information" { 1639 choice information-type { 1640 mandatory true; 1641 description 1642 "This choice statement ensures the response contains 1643 redirect-information or onboarding-information."; 1644 container redirect-information { 1645 description 1646 "Redirect information is described in Section 2.1 in 1647 RFC XXXX. Its purpose is to redirect a device to 1648 another bootstrap server."; 1649 reference 1650 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 1651 list bootstrap-server { 1652 key "address"; 1653 min-elements 1; 1654 description 1655 "A bootstrap server entry."; 1656 leaf address { 1657 type inet:host; 1658 mandatory true; 1659 description 1660 "The IP address or hostname of the bootstrap server the 1661 device should redirect to."; 1662 } 1663 leaf port { 1664 type inet:port-number; 1665 default "443"; 1666 description 1667 "The port number the bootstrap server listens on. If no 1668 port is specified, the IANA-assigned port for 'https' 1669 (443) is used."; 1670 } 1671 leaf trust-anchor { 1672 type cms; 1673 description 1674 "A CMS structure that MUST contain the chain of 1675 X.509 certificates needed to authenticate the TLS 1676 certificate presented by this bootstrap server. 1678 The CMS MUST only contain a single chain of 1679 certificates. The bootstrap server MUST only 1680 authenticate to last intermediate CA certificate 1681 listed in the chain. 1683 In all cases, the chain MUST include a self-signed 1684 root certificate. In the case where the root 1685 certificate is itself the issuer of the bootstrap 1686 server's TLS certificate, only one certificate 1687 is present. 1689 If needed by the device, this CMS structure MAY 1690 also contain suitably fresh revocation objects 1691 with which the device can verify the revocation 1692 status of the certificates. 1694 This CMS encodes the degenerate form of the SignedData 1695 structure that is commonly used to disseminate X.509 1696 certificates and revocation objects (RFC 5280)."; 1697 reference 1698 "RFC 5280: 1699 Internet X.509 Public Key Infrastructure Certificate 1700 and Certificate Revocation List (CRL) Profile."; 1701 } 1702 } 1703 } 1704 container onboarding-information { 1705 description 1706 "Onboarding information is described in Section 2.2 in 1707 RFC XXXX. Its purpose is to provide the device everything 1708 it needs to bootstrap itself."; 1709 reference 1710 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 1711 container boot-image { 1712 description 1713 "Specifies criteria for the boot image the device MUST 1714 be running, as well as information enabling the device 1715 to install the required boot image."; 1716 leaf os-name { 1717 type string; 1718 description 1719 "The name of the operating system software the device 1720 MUST be running in order to not require a software 1721 image upgrade (ex. VendorOS)."; 1722 } 1723 leaf os-version { 1724 type string; 1725 description 1726 "The version of the operating system software the 1727 device MUST be running in order to not require a 1728 software image upgrade (ex. 17.3R2.1)."; 1729 } 1730 leaf-list download-uri { 1731 type inet:uri; 1732 ordered-by user; 1733 description 1734 "An ordered list of URIs to where the same boot image 1735 file may be obtained. How the URI schemes (http, ftp, 1736 etc.) a device supports are known is vendor specific. 1737 If a secure scheme (e.g., https) is provided, a device 1738 MAY establish an untrusted connection to the remote 1739 server, by blindly accepting the server's end-entity 1740 certificate, to obtain the boot image."; 1741 } 1742 list image-verification { 1743 must '../download-uri' { 1744 description 1745 "Download URIs must be provided if an image is to 1746 be verified."; 1747 } 1748 key hash-algorithm; 1749 description 1750 "A list of hash values that a device can use to verify 1751 boot image files with."; 1752 leaf hash-algorithm { 1753 type identityref { 1754 base "hash-algorithm"; 1755 } 1756 description 1757 "Identifies the hash algorithm used."; 1758 } 1759 leaf hash-value { 1760 type yang:hex-string; 1761 mandatory true; 1762 description 1763 "The hex-encoded value of the specified hash 1764 algorithm over the contents of the boot image 1765 file."; 1766 } 1767 } 1768 } 1769 leaf configuration-handling { 1770 type enumeration { 1771 enum "merge" { 1772 description 1773 "Merge configuration into the running datastore."; 1774 } 1775 enum "replace" { 1776 description 1777 "Replace the existing running datastore with the 1778 passed configuration."; 1780 } 1781 } 1782 must '../configuration'; 1783 description 1784 "This enumeration indicates how the server should process 1785 the provided configuration."; 1786 } 1787 leaf pre-configuration-script { 1788 type script; 1789 description 1790 "A script that, when present, is executed before the 1791 configuration has been processed."; 1792 } 1793 leaf configuration { 1794 type binary; 1795 must '../configuration-handling'; 1796 description 1797 "Any configuration known to the device. The use of 1798 the 'binary' type enables e.g., XML-content to be 1799 embedded into a JSON document. The exact encoding 1800 of the content, as with the scripts, is vendor 1801 specific."; 1802 } 1803 leaf post-configuration-script { 1804 type script; 1805 description 1806 "A script that, when present, is executed after the 1807 configuration has been processed."; 1808 } 1809 } 1810 } 1811 } 1813 typedef script { 1814 type binary; 1815 description 1816 "A device specific script that enables the execution of 1817 commands to perform actions not possible thru configuration 1818 alone. 1820 No attempt is made to standardize the contents, running 1821 context, or programming language of the script, other than 1822 that it can indicate if any warnings or errors occurred and 1823 can emit output. The contents of the script are considered 1824 specific to the vendor, product line, and/or model of the 1825 device. 1827 If the script execution indicates that an warning occurred, 1828 then the device MUST assume that the script had a soft error 1829 that the script believes will not affect manageability. 1831 If the script execution indicates that an error occurred, 1832 the device MUST assume the script had a hard error that the 1833 script believes will affect manageability. In this case, 1834 the script is required to gracefully exit, removing any 1835 state that might hinder the device's ability to continue 1836 the bootstrapping sequence (e.g., process onboarding 1837 information obtained from another bootstrap server)."; 1838 } 1839 } 1840 1842 7. The SZTP Bootstrap Server API 1844 This section defines the API for bootstrap servers. The API is 1845 defined as that produced by a RESTCONF [RFC8040] server that supports 1846 the YANG 1.1 [RFC7950] module defined in this section. 1848 7.1. API Overview 1850 The following tree diagram provides an overview for the bootstrap 1851 server RESTCONF API. 1853 module: ietf-sztp-bootstrap-server 1855 rpcs: 1856 +---x get-bootstrapping-data 1857 | +---w input 1858 | | +---w signed-data-preferred? empty 1859 | | +---w hw-model? string 1860 | | +---w os-name? string 1861 | | +---w os-version? string 1862 | | +---w nonce? binary 1863 | +--ro output 1864 | +--ro reporting-level? enumeration {onboarding-server}? 1865 | +--ro conveyed-information cms 1866 | +--ro owner-certificate? cms 1867 | +--ro ownership-voucher? cms 1868 +---x report-progress {onboarding-server}? 1869 +---w input 1870 +---w progress-type enumeration 1871 +---w message? string 1872 +---w ssh-host-keys 1873 | +---w ssh-host-key* [] 1874 | +---w algorithm string 1875 | +---w key-data binary 1876 +---w trust-anchor-certs 1877 +---w trust-anchor-cert* cms 1879 7.2. Example Usage 1881 This section presents three examples illustrating the bootstrap 1882 server's API. Two examples are provided for the "get-bootstrapping- 1883 data" RPC (once to an untrusted bootstrap server, and again to a 1884 trusted bootstrap server), and one example for the "report-progress" 1885 RPC. 1887 The following example illustrates a device using the API to fetch its 1888 bootstrapping data from a untrusted bootstrap server. In this 1889 example, the device sends the "signed-data-preferred" input parameter 1890 and receives signed data in the response. 1892 REQUEST 1894 [Note: '\' line wrapping for formatting only] 1896 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 1897 ng-data HTTP/1.1 1898 HOST: example.com 1899 Content-Type: application/yang.data+xml 1901 1903 1904 1906 RESPONSE 1908 HTTP/1.1 200 OK 1909 Date: Sat, 31 Oct 2015 17:02:40 GMT 1910 Server: example-server 1911 Content-Type: application/yang.data+xml 1913 1915 base64encodedvalue== 1916 base64encodedvalue== 1917 base64encodedvalue== 1918 1920 The following example illustrates a device using the API to fetch its 1921 bootstrapping data from a trusted bootstrap server. In this example, 1922 the device sends addition input parameters to the bootstrap server, 1923 which it may use when formulating its response to the device. 1925 REQUEST 1927 [Note: '\' line wrapping for formatting only] 1929 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 1930 ng-data HTTP/1.1 1931 HOST: example.com 1932 Content-Type: application/yang.data+xml 1934 1936 model-x 1937 vendor-os 1938 17.3R2.1 1939 extralongbase64encodedvalue= 1940 1942 RESPONSE 1944 HTTP/1.1 200 OK 1945 Date: Sat, 31 Oct 2015 17:02:40 GMT 1946 Server: example-server 1947 Content-Type: application/yang.data+xml 1949 1951 verbose 1952 base64encodedvalue== 1953 1955 The following example illustrates a device using the API to post a 1956 progress report to a bootstrap server. Illustrated below is the 1957 "bootstrap-complete" message, but the device may send other progress 1958 reports to the server while bootstrapping. In this example, the 1959 device is sending both its SSH host keys and a TLS server 1960 certificate, which the bootstrap server may, for example, pass to an 1961 NMS, as discussed in Appendix C.3. 1963 REQUEST 1965 [Note: '\' line wrapping for formatting only] 1967 POST /restconf/operations/ietf-sztp-bootstrap-server:report-progress\ 1968 HTTP/1.1 1969 HOST: example.com 1970 Content-Type: application/yang.data+xml 1972 1974 bootstrap-complete 1975 example message 1976 1977 1978 ssh-rsa 1979 base64encodedvalue== 1980 1981 1982 rsa-sha2-256 1983 base64encodedvalue== 1984 1985 1986 1987 base64encodedvalue== 1988 1989 1991 RESPONSE 1993 HTTP/1.1 204 No Content 1994 Date: Sat, 31 Oct 2015 17:02:40 GMT 1995 Server: example-server 1997 7.3. YANG Module 1999 The bootstrap server's device-facing API is normatively defined by 2000 the YANG module defined in this section. 2002 This module uses data types defined in [RFC4253], [RFC5652], 2003 [RFC5280], [RFC6960], and [RFC8366], uses an encoding defined in 2004 [ITU.X690.2015], and makes a reference to [RFC4250] and [RFC6187]. 2006 file "ietf-sztp-bootstrap-server@2019-01-15.yang" 2007 module ietf-sztp-bootstrap-server { 2008 yang-version 1.1; 2009 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server"; 2010 prefix sztp-svr; 2011 organization 2012 "IETF NETCONF (Network Configuration) Working Group"; 2014 contact 2015 "WG Web: 2016 WG List: 2017 Author: Kent Watsen "; 2019 description 2020 "This module defines an interface for bootstrap servers, as 2021 defined by RFC XXXX: Secure Zero Touch Provisioning (SZTP). 2023 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2024 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 2025 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 2026 are to be interpreted as described in BCP 14 (RFC 2119, 2027 RFC 8174) when, and only when, they appear in all 2028 capitals, as shown here. 2030 Copyright (c) 2019 IETF Trust and the persons identified as 2031 authors of the code. All rights reserved. 2033 Redistribution and use in source and binary forms, with or 2034 without modification, is permitted pursuant to, and subject 2035 to the license terms contained in, the Simplified BSD License 2036 set forth in Section 4.c of the IETF Trust's Legal Provisions 2037 Relating to IETF Documents (http://trustee.ietf.org/license-info) 2039 This version of this YANG module is part of RFC XXXX; see the 2040 RFC itself for full legal notices."; 2042 revision 2019-01-15 { 2043 description 2044 "Initial version"; 2045 reference 2046 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 2047 } 2049 // features 2050 feature redirect-server { 2051 description 2052 "The server supports being a 'redirect server'."; 2053 } 2055 feature onboarding-server { 2056 description 2057 "The server supports being an 'onboarding server'."; 2058 } 2059 // typedefs 2061 typedef cms { 2062 type binary; 2063 description 2064 "A CMS structure, as specified in RFC 5652, encoded using 2065 ASN.1 distinguished encoding rules (DER), as specified in 2066 ITU-T X.690."; 2067 reference 2068 "RFC 5652: 2069 Cryptographic Message Syntax (CMS) 2070 ITU-T X.690: 2071 Information technology - ASN.1 encoding rules: 2072 Specification of Basic Encoding Rules (BER), 2073 Canonical Encoding Rules (CER) and Distinguished 2074 Encoding Rules (DER)."; 2075 } 2077 // RPCs 2079 rpc get-bootstrapping-data { 2080 description 2081 "This RPC enables a device, as identified by the RESTCONF 2082 username, to obtain bootstrapping data that has been made 2083 available for it."; 2084 input { 2085 leaf signed-data-preferred { 2086 type empty; 2087 description 2088 "This optional input parameter enables a device to 2089 communicate to the bootstrap server that it prefers 2090 to receive signed data. Devices SHOULD always send 2091 this parameter when the bootstrap server is untrusted. 2092 Upon receiving this input parameter, the bootstrap 2093 server MUST return either signed data, or unsigned 2094 redirect information; the bootstrap server MUST NOT 2095 return unsigned onboarding information."; 2096 } 2097 leaf hw-model { 2098 type string; 2099 description 2100 "This optional input parameter enables a device to 2101 communicate to the bootstrap server its vendor specific 2102 hardware model number. This parameter may be needed, 2103 for instance, when a device's IDevID certificate does 2104 not include the 'hardwareModelName' value in its 2105 subjectAltName field, as is allowed by 802.1AR-2009."; 2106 reference 2107 "IEEE 802.1AR-2009: IEEE Standard for Local and 2108 metropolitan area networks - Secure Device Identity"; 2109 } 2110 leaf os-name { 2111 type string; 2112 description 2113 "This optional input parameter enables a device to 2114 communicate to the bootstrap server the name of its 2115 operating system. This parameter may be useful if 2116 the device, as identified by its serial number, can 2117 run more than one type of operating system (e.g., 2118 on a white-box system."; 2119 } 2120 leaf os-version { 2121 type string; 2122 description 2123 "This optional input parameter enables a device to 2124 communicate to the bootstrap server the version of its 2125 operating system. This parameter may be used by a 2126 bootstrap server to return an operating system specific 2127 response to the device, thus negating the need for a 2128 potentially expensive boot-image update."; 2129 } 2130 leaf nonce { 2131 type binary { 2132 length "16..32"; 2133 } 2134 description 2135 "This optional input parameter enables a device to 2136 communicate to the bootstrap server a nonce value. 2137 This may be especially useful for devices lacking 2138 an accurate clock, as then the bootstrap server 2139 can dynamically obtain from the manufacturer a 2140 voucher with the nonce value in it, as described 2141 in RFC 8366."; 2142 reference 2143 "RFC 8366: 2144 A Voucher Artifact for Bootstrapping Protocols"; 2145 } 2146 } 2147 output { 2148 leaf reporting-level { 2149 if-feature onboarding-server; 2150 type enumeration { 2151 enum standard { 2152 description 2153 "Send just the progress reports required by RFC XXXX."; 2154 reference 2155 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 2156 } 2157 enum verbose { 2158 description 2159 "Send additional progress reports that might help 2160 troubleshooting an SZTP bootstrapping issue."; 2161 } 2162 } 2163 default standard; 2164 description 2165 "Specifies the reporting level for progress reports the 2166 bootstrap server would like to receive when processing 2167 onboarding information. Progress reports are not sent 2168 when processing redirect information, or when the 2169 bootstrap server is untrusted (e.g., device sent the 2170 '' input parameter)."; 2171 } 2172 leaf conveyed-information { 2173 type cms; 2174 mandatory true; 2175 description 2176 "An SZTP conveyed information artifact, as described in 2177 Section 3.1 of RFC XXXX."; 2178 reference 2179 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 2180 } 2181 leaf owner-certificate { 2182 type cms; 2183 must '../ownership-voucher' { 2184 description 2185 "An ownership voucher must be present whenever an owner 2186 certificate is presented."; 2187 } 2188 description 2189 "An owner certificate artifact, as described in Section 2190 3.2 of RFC XXXX. This leaf is optional because it is 2191 only needed when the conveyed information artifact is 2192 signed."; 2193 reference 2194 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 2195 } 2196 leaf ownership-voucher { 2197 type cms; 2198 must '../owner-certificate' { 2199 description 2200 "An owner certificate must be present whenever an 2201 ownership voucher is presented."; 2202 } 2203 description 2204 "An ownership voucher artifact, as described by Section 2205 3.3 of RFC XXXX. This leaf is optional because it is 2206 only needed when the conveyed information artifact is 2207 signed."; 2208 reference 2209 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 2210 } 2211 } 2212 } 2214 rpc report-progress { 2215 if-feature onboarding-server; 2216 description 2217 "This RPC enables a device, as identified by the RESTCONF 2218 username, to report its bootstrapping progress to the 2219 bootstrap server. This RPC is expected to be used when 2220 the device obtains onboarding-information from a trusted 2221 bootstap server."; 2222 input { 2223 leaf progress-type { 2224 type enumeration { 2225 enum "bootstrap-initiated" { 2226 description 2227 "Indicates that the device just used the 2228 'get-bootstrapping-data' RPC. The 'message' node 2229 below MAY contain any additional information that 2230 the manufacturer thinks might be useful."; 2231 } 2232 enum "parsing-initiated" { 2233 description 2234 "Indicates that the device is about to start parsing 2235 the onboarding information. This progress type is 2236 only for when parsing is implemented as a distinct 2237 step."; 2238 } 2239 enum "parsing-warning" { 2240 description 2241 "Indicates that the device had a non-fatal error when 2242 parsing the response from the bootstrap server. The 2243 'message' node below SHOULD indicate the specific 2244 warning that occurred."; 2245 } 2246 enum "parsing-error" { 2247 description 2248 "Indicates that the device encountered a fatal error 2249 when parsing the response from the bootstrap server. 2250 For instance, this could be due to malformed encoding, 2251 the device expecting signed data when only unsigned 2252 data is provided, the ownership voucher not listing 2253 the device's serial number, or because the signature 2254 didn't match. The 'message' node below SHOULD 2255 indicate the specific error. This progress type 2256 also indicates that the device has abandoned trying 2257 to bootstrap off this bootstrap server."; 2258 } 2259 enum "parsing-complete" { 2260 description 2261 "Indicates that the device successfully completed 2262 parsing the onboarding information. This progress 2263 type is only for when parsing is implemented as a 2264 distinct step."; 2265 } 2266 enum "boot-image-initiated" { 2267 description 2268 "Indicates that the device is about to start 2269 processing the boot-image information."; 2270 } 2271 enum "boot-image-warning" { 2272 description 2273 "Indicates that the device encountered a non-fatal 2274 error condition when trying to install a boot-image. 2275 A possible reason might include a need to reformat a 2276 partition causing loss of data. The 'message' node 2277 below SHOULD indicate any warning messages that were 2278 generated."; 2279 } 2280 enum "boot-image-error" { 2281 description 2282 "Indicates that the device encountered an error when 2283 trying to install a boot-image, which could be for 2284 reasons such as a file server being unreachable, 2285 file not found, signature mismatch, etc. The 2286 'message' node SHOULD indicate the specific error 2287 that occurred. This progress type also indicates 2288 that the device has abandoned trying to bootstrap 2289 off this bootstrap server."; 2290 } 2291 enum "boot-image-mismatch" { 2292 description 2293 "Indicates that the device that has determined that 2294 it is not running the correct boot image. This 2295 message SHOULD precipitate trying to download 2296 a boot image."; 2297 } 2298 enum "boot-image-installed-rebooting" { 2299 description 2300 "Indicates that the device successfully installed 2301 a new boot image and is about to reboot. After 2302 sending this progress type, the device is not 2303 expected to access the bootstrap server again 2304 for this bootstrapping attempt."; 2305 } 2306 enum "boot-image-complete" { 2307 description 2308 "Indicates that the device believes that it is 2309 running the correct boot-image."; 2310 } 2311 enum "pre-script-initiated" { 2312 description 2313 "Indicates that the device is about to execute the 2314 'pre-configuration-script'."; 2315 } 2316 enum "pre-script-warning" { 2317 description 2318 "Indicates that the device obtained a warning from the 2319 'pre-configuration-script' when it was executed. The 2320 'message' node below SHOULD capture any output the 2321 script produces."; 2322 } 2323 enum "pre-script-error" { 2324 description 2325 "Indicates that the device obtained an error from the 2326 'pre-configuration-script' when it was executed. The 2327 'message' node below SHOULD capture any output the 2328 script produces. This progress type also indicates 2329 that the device has abandoned trying to bootstrap 2330 off this bootstrap server."; 2331 } 2332 enum "pre-script-complete" { 2333 description 2334 "Indicates that the device successfully executed the 2335 'pre-configuration-script'."; 2336 } 2337 enum "config-initiated" { 2338 description 2339 "Indicates that the device is about to commit the 2340 initial configuration."; 2341 } 2342 enum "config-warning" { 2343 description 2344 "Indicates that the device obtained warning messages 2345 when it committed the initial configuration. The 2346 'message' node below SHOULD indicate any warning 2347 messages that were generated."; 2348 } 2349 enum "config-error" { 2350 description 2351 "Indicates that the device obtained error messages 2352 when it committed the initial configuration. The 2353 'message' node below SHOULD indicate the error 2354 messages that were generated. This progress type 2355 also indicates that the device has abandoned trying 2356 to bootstrap off this bootstrap server."; 2357 } 2358 enum "config-complete" { 2359 description 2360 "Indicates that the device successfully committed 2361 the initial configuration."; 2362 } 2363 enum "post-script-initiated" { 2364 description 2365 "Indicates that the device is about to execute the 2366 'post-configuration-script'."; 2367 } 2368 enum "post-script-warning" { 2369 description 2370 "Indicates that the device obtained a warning from the 2371 'post-configuration-script' when it was executed. The 2372 'message' node below SHOULD capture any output the 2373 script produces."; 2374 } 2375 enum "post-script-error" { 2376 description 2377 "Indicates that the device obtained an error from the 2378 'post-configuration-script' when it was executed. The 2379 'message' node below SHOULD capture any output the 2380 script produces. This progress type also indicates 2381 that the device has abandoned trying to bootstrap 2382 off this bootstrap server."; 2383 } 2384 enum "post-script-complete" { 2385 description 2386 "Indicates that the device successfully executed the 2387 'post-configuration-script'."; 2388 } 2389 enum "bootstrap-warning" { 2390 description 2391 "Indicates that a warning condition occurred for which 2392 there no other 'progress-type' enumeration is deemed 2393 suitable. The 'message' node below SHOULD describe 2394 the warning."; 2396 } 2397 enum "bootstrap-error" { 2398 description 2399 "Indicates that an error condition occurred for which 2400 there no other 'progress-type' enumeration is deemed 2401 suitable. The 'message' node below SHOULD describe 2402 the error. This progress type also indicates that 2403 the device has abandoned trying to bootstrap off 2404 this bootstrap server."; 2405 } 2406 enum "bootstrap-complete" { 2407 description 2408 "Indicates that the device successfully processed 2409 all 'onboarding-information' provided, and that it 2410 is ready to be managed. The 'message' node below 2411 MAY contain any additional information that the 2412 manufacturer thinks might be useful. After sending 2413 this progress type, the device is not expected to 2414 access the bootstrap server again."; 2415 } 2416 enum "informational" { 2417 description 2418 "Indicates any additional information not captured 2419 by any of the other progress types. For instance, 2420 a message indicating that the device is about to 2421 reboot after having installed a boot-image could 2422 be provided. The 'message' node below SHOULD 2423 contain information that the manufacturer thinks 2424 might be useful."; 2425 } 2426 } 2427 mandatory true; 2428 description 2429 "The type of progress report provided."; 2430 } 2431 leaf message { 2432 type string; 2433 description 2434 "An optional arbitrary value."; 2435 } 2436 container ssh-host-keys { 2437 when "../progress-type = 'bootstrap-complete'" { 2438 description 2439 "SSH host keys are only sent when the progress type 2440 is 'bootstrap-complete'."; 2441 } 2442 description 2443 "A list of SSH host keys an NMS may use to authenticate 2444 subsequent SSH-based connections to this device (e.g., 2445 netconf-ssh, netconf-ch-ssh)."; 2446 list ssh-host-key { 2447 description 2448 "An SSH host key an NMS may use to authenticate 2449 subsequent SSH-based connections to this device 2450 (e.g., netconf-ssh, netconf-ch-ssh)."; 2451 reference 2452 "RFC 4253: The Secure Shell (SSH) Transport Layer 2453 Protocol"; 2454 leaf algorithm { 2455 type string; 2456 mandatory true; 2457 description 2458 "The public key algorithm name for this SSH key. 2460 Valid values are listed in the 'Public Key Algorithm 2461 Names' subregistry of the 'Secure Shell (SSH) Protocol 2462 Parameters' registry maintained by IANA."; 2463 reference 2464 "RFC 4250: The Secure Shell (SSH) Protocol Assigned 2465 Numbers 2466 IANA URL: https://www.iana.org/assignments/ssh-param\\ 2467 eters/ssh-parameters.xhtml#ssh-parameters-19 2468 ('\\' added for formatting reasons)"; 2469 } 2470 leaf key-data { 2471 type binary; 2472 mandatory true; 2473 description 2474 "The binary public key data for this SSH key, as 2475 specified by RFC 4253, Section 6.6, i.e.: 2477 string certificate or public key format 2478 identifier 2479 byte[n] key/certificate data."; 2480 reference 2481 "RFC 4253: The Secure Shell (SSH) Transport Layer 2482 Protocol"; 2483 } 2484 } 2485 } 2486 container trust-anchor-certs { 2487 when "../progress-type = 'bootstrap-complete'" { 2488 description 2489 "Trust anchors are only sent when the progress type 2490 is 'bootstrap-complete'."; 2491 } 2492 description 2493 "A list of trust anchor certificates an NMS may use to 2494 authenticate subsequent certificate-based connections 2495 to this device (e.g., restconf-tls, netconf-tls, or 2496 even netconf-ssh with X.509 support from RFC 6187). 2497 In practice, trust anchors for IDevID certificates do 2498 not need to be conveyed using this mechanism."; 2499 reference 2500 "RFC 6187: 2501 X.509v3 Certificates for Secure Shell Authentication."; 2502 leaf-list trust-anchor-cert { 2503 type cms; 2504 description 2505 "A CMS structure whose top-most content type MUST be the 2506 signed-data content type, as described by Section 5 in 2507 RFC 5652. 2509 The CMS MUST contain the chain of X.509 certificates 2510 needed to authenticate the certificate presented by 2511 the device. 2513 The CMS MUST contain only a single chain of 2514 certificates. The last certificate in the chain 2515 MUST be the issuer for the device's end-entity 2516 certificate. 2518 In all cases, the chain MUST include a self-signed 2519 root certificate. In the case where the root 2520 certificate is itself the issuer of the device's 2521 end-entity certificate, only one certificate is 2522 present. 2524 This CMS encodes the degenerate form of the SignedData 2525 structure that is commonly used to disseminate X.509 2526 certificates and revocation objects (RFC 5280)."; 2527 reference 2528 "RFC 5280: 2529 Internet X.509 Public Key Infrastructure 2530 Certificate and Certificate Revocation List (CRL) 2531 Profile. 2532 RFC 5652: 2533 Cryptographic Message Syntax (CMS)"; 2534 } 2535 } 2536 } 2537 } 2538 } 2539 2541 8. DHCP Options 2543 This section defines two DHCP options, one for DHCPv4 and one for 2544 DHCPv6. These two options are semantically the same, though 2545 syntactically different. 2547 8.1. DHCPv4 SZTP Redirect Option 2549 The DHCPv4 SZTP Redirect Option is used to provision the client with 2550 one or more URIs for bootstrap servers that can be contacted to 2551 attempt further configuration. 2553 DHCPv4 SZTP Redirect Option 2555 0 1 2556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2557 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2558 | option-code (143) | option-length | 2559 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2560 . . 2561 . bootstrap-server-list (variable length) . 2562 . . 2563 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2565 * option-code: OPTION_V4_SZTP_REDIRECT (143) 2566 * option-length: The option length in octets. 2567 * bootstrap-server-list: A list of servers for the 2568 client to attempt contacting, in order to obtain 2569 further bootstrapping data, in the format shown 2570 in Section 8.3. 2572 DHCPv4 Client Behavior 2574 Clients MAY request the OPTION_V4_SZTP_REDIRECT by including its 2575 option code in the Parameter Request List (55) in DHCP request 2576 messages. 2578 On receipt of a DHCPv4 Reply message which contains the 2579 OPTION_V4_SZTP_REDIRECT, the client processes the response according 2580 to Section 5.5, with the understanding that the "address" and "port" 2581 values are encoded in the URIs. 2583 Any invalid URI entries received in the uri-data field are ignored by 2584 the client. If OPTION_V4_SZTP_REDIRECT does not contain at least one 2585 valid URI entry in the uri-data field, then the client MUST discard 2586 the option. 2588 As the list of URIs may exceed the maximum allowed length of a single 2589 DHCPv4 option (255 octets), the client MUST implement [RFC3396], 2590 allowing the URI list to be split across a number of 2591 OPTION_V4_SZTP_REDIRECT option instances. 2593 DHCPv4 Server Behavior 2595 The DHCPv4 server MAY include a single instance of Option 2596 OPTION_V4_SZTP_REDIRECT in DHCP messages it sends. Servers MUST NOT 2597 send more than one instance of the OPTION_V4_SZTP_REDIRECT option. 2599 The server's DHCP message MUST contain only a single instance of the 2600 OPTION_V4_SZTP_REDIRECT's 'bootstrap-server-list' field. However, 2601 the list of URIs in this field may exceed the maximum allowed length 2602 of a single DHCPv4 option (per [RFC3396]). 2604 If the length of 'bootstrap-server-list' is small enough to fit into 2605 a single instance of OPTION_V4_SZTP_REDIRECT, the server MUST NOT 2606 send more than one instance of this option. 2608 If the length of the 'bootstrap-server-list' field is too large to 2609 fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split 2610 into multiple instances of the option according to the process 2611 described in [RFC3396]. 2613 8.2. DHCPv6 SZTP Redirect Option 2615 The DHCPv6 SZTP Redirect Option is used to provision the client with 2616 one or more URIs for bootstrap servers that can be contacted to 2617 attempt further configuration. 2619 DHCPv6 SZTP Redirect Option 2621 0 1 2 3 2622 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 | option-code (136) | option-length | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 . bootstrap-server-list (variable length) . 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 * option-code: OPTION_V6_SZTP_REDIRECT (136) 2630 * option-length: The option length in octets. 2631 * bootstrap-server-list: A list of servers for the client to 2632 attempt contacting, in order to obtain further bootstrapping 2633 data, in the format shown in Section 8.3. 2635 DHCPv6 Client Behavior 2636 Clients MAY request the OPTION_V6_SZTP_REDIRECT option, as defined in 2637 [RFC8415], Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. 2638 As a convenience to the reader, we mention here that the client 2639 includes requested option codes in the Option Request Option. 2641 On receipt of a DHCPv6 Reply message which contains the 2642 OPTION_V6_SZTP_REDIRECT, the client processes the response according 2643 to Section 5.5, with the understanding that the "address" and "port" 2644 values are encoded in the URIs. 2646 Any invalid URI entries received in the uri-data field are ignored by 2647 the client. If OPTION_V6_SZTP_REDIRECT does not contain at least one 2648 valid URI entry in the uri-data field, then the client MUST discard 2649 the option. 2651 DHCPv6 Server Behavior 2653 Section 18.3 of [RFC8415] governs server operation in regard to 2654 option assignment. As a convenience to the reader, we mention here 2655 that the server will send a particular option code only if configured 2656 with specific values for that option code and if the client requested 2657 it. 2659 Option OPTION_V6_SZTP_REDIRECT is a singleton. Servers MUST NOT send 2660 more than one instance of the OPTION_V6_SZTP_REDIRECT option. 2662 8.3. Common Field Encoding 2664 Both of the DHCPv4 and DHCPv6 options defined in this section encode 2665 a list of bootstrap server URIs. The "URI" structure is a DHCP 2666 option that can contain multiple URIs (see [RFC7227], Section 5.7). 2667 Each URI entry in the bootstrap-server-list is structured as follows: 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 2670 | uri-length | URI | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 2673 * uri-length: 2 octets long, specifies the length of the URI data. 2674 * URI: URI of SZTP bootstrap server. 2676 The URI of the SZTP bootstrap server MUST use the "https" URI scheme 2677 defined in Section 2.7.2 of [RFC7230], and MUST be in form 2678 "https://[:]". 2680 9. Security Considerations 2682 9.1. Clock Sensitivity 2684 The solution in this document relies on TLS certificates, owner 2685 certificates, and ownership vouchers, all of which require an 2686 accurate clock in order to be processed correctly (e.g., to test 2687 validity dates and revocation status). Implementations SHOULD ensure 2688 devices have an accurate clock when shipped from manufacturing 2689 facilities, and take steps to prevent clock tampering. 2691 If it is not possible to ensure clock accuracy, it is RECOMMENDED 2692 that implementations disable the aspects of the solution having clock 2693 sensitivity. In particular, such implementations should assume that 2694 TLS certificates, ownership vouchers, and owner certificates never 2695 expire and are not revokable. From an ownership voucher perspective, 2696 manufacturers SHOULD issue a single ownership voucher for the 2697 lifetime of such devices. 2699 Implementations SHOULD NOT rely on NTP for time, as NTP is not a 2700 secure protocol at this time. Note, there is an IETF work-in- 2701 progress to secure NTP [I-D.ietf-ntp-using-nts-for-ntp]. 2703 9.2. Use of IDevID Certificates 2705 IDevID certificates, as defined in [Std-802.1AR-2018], are 2706 RECOMMENDED, both for the TLS-level client certificate used by 2707 devices when connecting to a bootstrap server, as well as for the 2708 device identity certificate used by owners when encrypting the SZTP 2709 bootstrapping data artifacts. 2711 9.3. Immutable Storage for Trust Anchors 2713 Devices MUST ensure that all their trust anchor certificates, 2714 including those for connecting to bootstrap servers and verifying 2715 ownership vouchers, are protected from external modification. 2717 It may be necessary to update these certificates over time (e.g., the 2718 manufacturer wants to delegate trust to a new CA). It is therefore 2719 expected that devices MAY update these trust anchors when needed 2720 through a verifiable process, such as a software upgrade using signed 2721 software images. 2723 9.4. Secure Storage for Long-lived Private Keys 2725 Manufacturer-generated device identifiers may have very long 2726 lifetimes. For instance, [Std-802.1AR-2018] recommends using the 2727 "notAfter" value 99991231235959Z in IDevID certificates. Given the 2728 long-lived nature of these private keys, it is paramount that they 2729 are stored so as to resist discovery, such as in a secure 2730 cryptographic processor, such as a trusted platform module (TPM) 2731 chip. 2733 9.5. Blindly Authenticating a Bootstrap Server 2735 This document allows a device to blindly authenticate a bootstrap 2736 server's TLS certificate. It does so to allow for cases where the 2737 redirect information may be obtained in an unsecured manner, which is 2738 desirable to support in some cases. 2740 To compensate for this, this document requires that devices, when 2741 connected to an untrusted bootstrap server, assert that data 2742 downloaded from the server is signed. 2744 9.6. Disclosing Information to Untrusted Servers 2746 This document allows devices to establish connections to untrusted 2747 bootstrap servers. However, since the bootstrap server is untrusted, 2748 it may be under the control of an adversary, and therefore devices 2749 SHOULD be cautious about the data they send to the bootstrap server 2750 in such cases. 2752 Devices send different data to bootstrap servers at each of the 2753 protocol layers TCP, TLS, HTTP, and RESTCONF. 2755 At the TCP protocol layer, devices may relay their IP address, 2756 subject to network translations. Disclosure of this information is 2757 not considered a security risk. 2759 At the TLS protocol layer, devices may use a client certificate to 2760 identify and authenticate themselves to untrusted bootstrap servers. 2761 At a minimum, the client certificate must disclose the device's 2762 serial number, and may disclose additional information such as the 2763 device's manufacturer, hardware model, public key, etc. Knowledge of 2764 this information may provide an adversary with details needed to 2765 launch an attack. It is RECOMMENDED that secrecy of the network 2766 constituency is not relied on for security. 2768 At the HTTP protocol layer, devices may use an HTTP authentication 2769 scheme to identify and authenticate themselves to untrusted bootstrap 2770 servers. At a minimum, the authentication scheme must disclose the 2771 device's serial number and, concerningly, may, depending on the 2772 authentication mechanism used, reveal a secret that is only supposed 2773 to be known to the device (e.g., a password). Devices SHOULD NOT use 2774 an HTTP authentication scheme (e.g., HTTP Basic) with an untrusted 2775 bootstrap server that reveals a secret that is only supposed to be 2776 known to the device. 2778 At the RESTCONF protocol layer, devices use the "get-bootstrapping- 2779 data" RPC, but not the "report-progress" RPC, when connected to an 2780 untrusted bootstrap server. The "get-bootstrapping-data" RPC allows 2781 additional input parameters to be passed to the bootstrap server 2782 (e.g., "os-name", "os-version", "hw-model"). It is RECOMMENDED that 2783 devices only pass the "signed-data-preferred" input parameter to an 2784 untrusted bootstrap server. While it is okay for a bootstrap server 2785 to immediately return signed onboarding information, it is 2786 RECOMMENDED that bootstrap servers instead promote the untrusted 2787 connection to a trusted connection, as described in Appendix B, thus 2788 enabling the device to use the "report-progress" RPC while processing 2789 the onboarding information. 2791 9.7. Sequencing Sources of Bootstrapping Data 2793 For devices supporting more than one source for bootstrapping data, 2794 no particular sequencing order has to be observed for security 2795 reasons, as the solution for each source is considered equally 2796 secure. However, from a privacy perspective, it is RECOMMENDED that 2797 devices access local sources before accessing remote sources. 2799 9.8. Safety of Private Keys used for Trust 2801 The solution presented in this document enables bootstrapping data to 2802 be trusted in two ways, either through transport level security or 2803 through the signing of artifacts. 2805 When transport level security (i.e., a trusted bootstrap server) is 2806 used, the private key for the end-entity certificate must be online 2807 in order to establish the TLS connection. 2809 When artifacts are signed, the signing key is required to be online 2810 only when the bootstrap server is returning a dynamically generated 2811 signed-data response. For instance, a bootstrap server, upon 2812 receiving the "signed-data-preferred" input parameter to the "get- 2813 bootstrapping-data" RPC, may dynamically generate a response that is 2814 signed. 2816 Bootstrap server administrators are RECOMMENDED to follow best 2817 practice to protect the private key used for any online operation. 2818 For instance, use of a hardware security module (HSM) is RECOMMENDED. 2819 If an HSM is not used, frequent private key refreshes are 2820 RECOMMENDED, assuming all bootstrapping devices have an accurate 2821 clock (see Section 9.1). 2823 For best security, it is RECOMMENDED that owners only provide 2824 bootstrapping data that has been signed, using a protected private 2825 key, and encrypted, using the device's public key from its secure 2826 device identity certificate. 2828 9.9. Increased Reliance on Manufacturers 2830 The SZTP bootstrapping protocol presented in this document shifts 2831 some control of initial configuration away from the rightful owner of 2832 the device and towards the manufacturer and its delegates. 2834 The manufacturer maintains the list of well-known bootstrap servers 2835 its devices will trust. By design, if no bootstrapping data is found 2836 via other methods first, the device will try to reach out to the 2837 well-known bootstrap servers. There is no mechanism to prevent this 2838 from occurring other than by using an external firewall to block such 2839 connections. Concerns related to trusted bootstrap servers are 2840 discussed in Section 9.10. 2842 Similarly, the manufacturer maintains the list of voucher signing 2843 authorities its devices will trust. The voucher signing authorities 2844 issue the vouchers that enable a device to trust an owner's domain 2845 certificate. It is vital that manufacturers ensure the integrity of 2846 these voucher signing authorities, so as to avoid incorrect 2847 assignments. 2849 Operators should be aware that this system assumes that they trust 2850 all the pre-configured bootstrap servers and voucher signing 2851 authorities designated by the manufacturers. While operators may use 2852 points in the network to block access to the well-known bootstrap 2853 servers, operators cannot prevent voucher signing authorities from 2854 generating vouchers for their devices. 2856 9.10. Concerns with Trusted Bootstrap Servers 2858 Trusted bootstrap servers, whether well-known or discovered, have the 2859 potential to cause problems, such as the following. 2861 o A trusted bootstrap server that has been compromised may be 2862 modified to return unsigned data of any sort. For instance, a 2863 bootstrap server that is only suppose to return redirect 2864 information might be modified to return onboarding information. 2865 Similarly, a bootstrap server that is only supposed to return 2866 signed data, may be modified to return unsigned data. In both 2867 cases, the device will accept the response, unaware that it wasn't 2868 supposed to be any different. It is RECOMMENDED that maintainers 2869 of trusted bootstrap servers ensure that their systems are not 2870 easily compromised and, in case of compromise, have mechanisms in 2871 place to detect and remediate the compromise as expediently as 2872 possible. 2874 o A trusted bootstrap server hosting either unsigned, or signed but 2875 not encrypted, data may disclose information to unwanted parties 2876 (e.g., an administrator of the bootstrap server). This is a 2877 privacy issue only, but could reveal information that might be 2878 used in a subsequent attack. Disclosure of redirect information 2879 has limited exposure (it is just a list of bootstrap servers), 2880 whereas disclosure of onboarding information could be highly 2881 revealing (e.g., network topology, firewall policies, etc.). It 2882 is RECOMMENDED that operators encrypt the bootstrapping data when 2883 its contents are considered sensitive, even to the point of hiding 2884 it from the administrators of the bootstrap server, which may be 2885 maintained by a 3rd-party. 2887 9.11. Validity Period for Conveyed Information 2889 The conveyed information artifact does not specify a validity period. 2890 For instance, neither redirect information nor onboarding information 2891 enable "not-before" or "not-after" values to be specified, and 2892 neither artifact alone can be revoked. 2894 For unsigned data provided by an untrusted source of bootstrapping 2895 data, it is not meaningful to discuss its validity period when the 2896 information itself has no authenticity and may have come from 2897 anywhere. 2899 For unsigned data provided by a trusted source of bootstrapping data 2900 (i.e., a bootstrap server), the availability of the data is the only 2901 measure of it being current. Since the untrusted data comes from a 2902 trusted source, its current availability is meaningful and, since 2903 bootstrap servers use TLS, the contents of the exchange cannot be 2904 modified or replayed. 2906 For signed data, whether provided by an untrusted or trusted source 2907 of bootstrapping data, the validity is constrained by the validity of 2908 the both the ownership voucher and owner certificate used to 2909 authenticate it. 2911 The ownership voucher's validity is primarily constrained by the 2912 ownership voucher's "created-on" and "expires-on" nodes. While 2913 [RFC8366] recommends short-lived vouchers (see Section 6.1), the 2914 "expires-on" node may be set to any point in the future, or omitted 2915 altogether to indicate that the voucher never expires. The ownership 2916 voucher's validity is secondarily constrained by the manufacturer's 2917 PKI used to sign the voucher; whilst an ownership voucher cannot be 2918 revoked directly, the PKI used to sign it may be. 2920 The owner certificate's validity is primarily constrained by the 2921 X.509's validity field, the "notBefore" and "notAfter" values, as 2922 specified by the certificate authority that signed it. The owner 2923 certificate's validity is secondarily constrained by the validity of 2924 the PKI used to sign the voucher. Owner certificates may be revoked 2925 directly. 2927 For owners that wish to have maximum flexibility in their ability to 2928 specify and constrain the validity of signed data, it is RECOMMENDED 2929 that a unique owner certificate is created for each signed artifact. 2930 Not only does this enable a validity period to be specified, for each 2931 artifact, but it also enables to the validity of each artifact to be 2932 revoked. 2934 9.12. Cascading Trust via Redirects 2936 Redirect Information (Section 2.1), by design, instructs a 2937 bootstrapping device to initiate a HTTPS connection to the specified 2938 bootstrap servers. 2940 When the redirect information is trusted, the redirect information 2941 can encode a trust anchor certificate used by the device to 2942 authenticate the TLS end-entity certificate presented by each 2943 bootstrap server. 2945 As a result, any compromise in an interaction providing redirect 2946 information may result in compromise of all subsequent interactions. 2948 9.13. Possible Reuse of Private Keys 2950 This document describes two uses for secure device identity 2951 certificates. 2953 The primary use is for when the device authenticates itself to a 2954 bootstrap server, using its private key for TLS-level client- 2955 certificate based authentication. 2957 A secondary use is for when the device needs to decrypt provided 2958 bootstrapping artifacts, using its private key to decrypt the data 2959 or, more precisely, per Section 6 in [RFC5652], decrypt a symmetric 2960 key used to decrypt the data. 2962 This document, in Section 3.4 allows for the possibility that the 2963 same secure device identity certificate is used for both uses, as 2964 [Std-802.1AR-2018] states that a DevID certificate MAY have the 2965 "keyEncipherment" KeyUsage bit, in addition to the "digitalSignature" 2966 KeyUsage bit, set. 2968 While it is understood that it is generally frowned upon to reuse 2969 private keys, this document views such reuse acceptable as there are 2970 not any known ways to cause a signature made in one context to be 2971 (mis)interpreted as valid in the other context. 2973 9.14. Non-Issue with Encrypting Signed Artifacts 2975 This document specifies the encryption of signed objects, as opposed 2976 to the signing of encrypted objects, as might be expected given well- 2977 publicized oracle attacks (e.g., the padding oracle attack). 2979 This document does not view such attacks as feasible in the context 2980 of the solution because the decrypted text never leaves the device. 2982 9.15. The "ietf-sztp-conveyed-info" YANG Module 2984 The ietf-sztp-conveyed-info module defined in this document defines a 2985 data structure that is always wrapped by a CMS structure. When 2986 accessed by a secure mechanism (e.g., protected by TLS), then the CMS 2987 structure may be unsigned. However, when accessed by an insecure 2988 mechanism (e.g., removable storage device), then the CMS structure 2989 must be signed, in order for the device to trust it. 2991 Implementations should be aware that signed bootstrapping data only 2992 protects the data from modification, and that the contents are still 2993 visible to others. This doesn't affect security so much as privacy. 2994 That the contents may be read by unintended parties when accessed by 2995 insecure mechanisms is considered next. 2997 The ietf-sztp-conveyed-info module defines a top-level "choice" 2998 statement that declares the contents are either "redirect- 2999 information" or "onboarding-information". Each of these two cases 3000 are now considered. 3002 When the content of the CMS structure is redirect-information, an 3003 observer can learn about the bootstrap servers the device is being 3004 directed to, their IP addresses or hostnames, ports, and trust anchor 3005 certificates. Knowledge of this information could provide an 3006 observer some insight into a network's inner structure. 3008 When the content of the CMS structure is onboarding information, an 3009 observer could learn considerable information about how the device is 3010 to be provisioned. This information includes the operating system 3011 version, initial configuration, and script contents. This 3012 information should be considered sensitive and precautions should be 3013 taken to protect it (e.g., encrypt the artifact using the device's 3014 public key). 3016 9.16. The "ietf-sztp-bootstrap-server" YANG Module 3018 The ietf-sztp-bootstrap-server module defined in this document 3019 specifies an API for a RESTCONF [RFC8040]. The lowest RESTCONF layer 3020 is HTTPS, and the mandatory-to-implement secure transport is TLS 3021 [RFC8446]. 3023 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 3024 to restrict access for particular users to a preconfigured subset of 3025 all available protocol operations and content. 3027 This module presents no data nodes (only RPCs). There is no need to 3028 discuss the sensitivity of data nodes. 3030 This module defines two RPC operations that may be considered 3031 sensitive in some network environments. These are the operations and 3032 their sensitivity/vulnerability: 3034 get-bootstrapping-data: This RPC is used by devices to obtain their 3035 bootstrapping data. By design, each device, as identified by its 3036 authentication credentials (e.g. client certificate), can only 3037 obtain its own data. NACM is not needed to further constrain 3038 access to this RPC. 3040 report-progress: This RPC is used by devices to report their 3041 bootstrapping progress. By design, each device, as identified by 3042 its authentication credentials (e.g. client certificate), can 3043 only report data for itself. NACM is not needed to further 3044 constrain access to this RPC. 3046 10. IANA Considerations 3048 10.1. The IETF XML Registry 3050 This document registers two URIs in the "ns" subregistry of the IETF 3051 XML Registry [RFC3688] maintained at 3052 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 3053 Following the format in [RFC3688], the following registrations are 3054 requested: 3056 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info 3057 Registrant Contact: The NETCONF WG of the IETF. 3058 XML: N/A, the requested URI is an XML namespace. 3060 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server 3061 Registrant Contact: The NETCONF WG of the IETF. 3062 XML: N/A, the requested URI is an XML namespace. 3064 10.2. The YANG Module Names Registry 3066 This document registers two YANG modules in the YANG Module Names 3067 registry [RFC6020] maintained at https://www.iana.org/assignments/ 3068 yang-parameters/yang-parameters.xhtml. Following the format defined 3069 in [RFC6020], the below registrations are requested: 3071 name: ietf-sztp-conveyed-info 3072 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info 3073 prefix: sztp-info 3074 reference: RFC XXXX 3076 name: ietf-sztp-bootstrap-server 3077 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server 3078 prefix: sztp-svr 3079 reference: RFC XXXX 3081 10.3. The SMI Security for S/MIME CMS Content Type Registry 3083 This document registers two SMI security codes in the "SMI Security 3084 for S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1) 3085 maintained at https://www.iana.org/assignments/smi-numbers/smi- 3086 numbers.xhtml#security-smime-1. Following the format used in 3087 Section 3.4 of [RFC7107], the below registrations are requested: 3089 Decimal Description References 3090 ------- -------------------------- ---------- 3091 TBD1 id-ct-sztpConveyedInfoXML [RFCXXXX] 3092 TBD2 id-ct-sztpConveyedInfoJSON [RFCXXXX] 3094 id-ct-sztpConveyedInfoXML indicates that the "conveyed-information" 3095 is encoded using XML. id-ct-sztpConveyedInfoJSON indicates that the 3096 "conveyed-information" is encoded using JSON. 3098 10.4. The BOOTP Manufacturer Extensions and DHCP Options Registry 3100 This document registers one DHCP code point in the "BOOTP 3101 Manufacturer Extensions and DHCP Options" registry maintained at 3102 http://www.iana.org/assignments/bootp-dhcp-parameters. Following the 3103 format used by other registrations, the below registration is 3104 requested: 3106 Tag: 143 3107 Name: OPTION_V4_SZTP_REDIRECT 3108 Data Length: N 3109 Meaning: This option provides a list of URIs 3110 for SZTP bootstrap servers 3111 Reference: [RFCXXXX] 3113 Note: this request is to make permanent a previously registered early 3114 code point allocation. 3116 10.5. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 3117 Registry 3119 This document registers one DHCP code point in "Option Codes" 3120 subregistry of the "Dynamic Host Configuration Protocol for IPv6 3121 (DHCPv6)" registry maintained at http://www.iana.org/assignments/ 3122 dhcpv6-parameters. Following the format used by other registrations, 3123 the below registration is requested: 3125 Value: 136 3126 Description: OPTION_V6_SZTP_REDIRECT 3127 Client ORO: Yes 3128 Singleton Option: Yes 3129 Reference: [RFCXXXX] 3131 Note: this request is to make permanent a previously registered early 3132 code point allocation. 3134 10.6. The Service Name and Transport Protocol Port Number Registry 3136 This document registers one service name in the Service Name and 3137 Transport Protocol Port Number Registry [RFC6335] maintained at 3138 https://www.iana.org/assignments/service-names-port-numbers/service- 3139 names-port-numbers.xhtml. Following the format defined in 3140 Section 8.1.1 of [RFC6335], the below registration is requested: 3142 Service Name: sztp 3143 Transport Protocol(s): TCP 3144 Assignee: IESG 3145 Contact: IETF Chair 3146 Description: This service name is used to construct the 3147 SRV service label "_sztp" for discovering 3148 SZTP bootstrap servers. 3149 Reference: [RFCXXXX] 3150 Port Number: N/A 3151 Service Code: N/A 3152 Known Unauthorized Uses: N/A 3153 Assignment Notes: This protocol uses HTTPS as a substrate. 3155 10.7. The DNS Underscore Global Scoped Entry Registry 3157 This document registers one service name in the DNS Underscore Global 3158 Scoped Entry Registry [I-D.ietf-dnsop-attrleaf] maintained at 3159 TBD_IANA_URL. Following the format defined in Section 4.3 of 3160 [I-D.ietf-dnsop-attrleaf], the below registration is requested: 3162 RR Type: TXT 3163 _NODE NAME: _sztp 3164 Reference: [RFCXXXX] 3166 11. References 3168 11.1. Normative References 3170 [I-D.ietf-dnsop-attrleaf] 3171 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 3172 of Attribute Leaves", draft-ietf-dnsop-attrleaf-16 (work 3173 in progress), November 2018. 3175 [ITU.X690.2015] 3176 International Telecommunication Union, "Information 3177 Technology - ASN.1 encoding rules: Specification of Basic 3178 Encoding Rules (BER), Canonical Encoding Rules (CER) and 3179 Distinguished Encoding Rules (DER)", ITU-T Recommendation 3180 X.690, ISO/IEC 8825-1, August 2015, 3181 . 3183 [RFC1035] Mockapetris, P., "Domain names - implementation and 3184 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3185 November 1987, . 3187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3188 Requirement Levels", BCP 14, RFC 2119, 3189 DOI 10.17487/RFC2119, March 1997, 3190 . 3192 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 3193 specifying the location of services (DNS SRV)", RFC 2782, 3194 DOI 10.17487/RFC2782, February 2000, 3195 . 3197 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 3198 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 3199 DOI 10.17487/RFC3396, November 2002, 3200 . 3202 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 3203 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 3204 January 2006, . 3206 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3207 Housley, R., and W. Polk, "Internet X.509 Public Key 3208 Infrastructure Certificate and Certificate Revocation List 3209 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3210 . 3212 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3213 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3214 . 3216 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3217 the Network Configuration Protocol (NETCONF)", RFC 6020, 3218 DOI 10.17487/RFC6020, October 2010, 3219 . 3221 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3222 Verification of Domain-Based Application Service Identity 3223 within Internet Public Key Infrastructure Using X.509 3224 (PKIX) Certificates in the Context of Transport Layer 3225 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3226 2011, . 3228 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3229 DOI 10.17487/RFC6762, February 2013, 3230 . 3232 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3233 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3234 . 3236 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 3237 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 3238 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 3239 . 3241 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3242 Protocol (HTTP/1.1): Message Syntax and Routing", 3243 RFC 7230, DOI 10.17487/RFC7230, June 2014, 3244 . 3246 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3247 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3248 . 3250 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3251 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3252 . 3254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3256 May 2017, . 3258 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3259 "A Voucher Artifact for Bootstrapping Protocols", 3260 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3261 . 3263 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 3264 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 3265 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3266 RFC 8415, DOI 10.17487/RFC8415, November 2018, 3267 . 3269 [Std-802.1AR-2018] 3270 IEEE SA-Standards Board, "IEEE Standard for Local and 3271 metropolitan area networks - Secure Device Identity", June 3272 2018, 3273 . 3275 11.2. Informative References 3277 [I-D.ietf-netconf-crypto-types] 3278 Watsen, K. and H. Wang, "Common YANG Data Types for 3279 Cryptography", draft-ietf-netconf-crypto-types-02 (work in 3280 progress), October 2018. 3282 [I-D.ietf-netconf-trust-anchors] 3283 Watsen, K., "YANG Data Model for Global Trust Anchors", 3284 draft-ietf-netconf-trust-anchors-02 (work in progress), 3285 October 2018. 3287 [I-D.ietf-ntp-using-nts-for-ntp] 3288 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 3289 Sundblad, "Network Time Security for the Network Time 3290 Protocol", draft-ietf-ntp-using-nts-for-ntp-15 (work in 3291 progress), December 2018. 3293 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3294 DOI 10.17487/RFC3688, January 2004, 3295 . 3297 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 3298 Protocol Assigned Numbers", RFC 4250, 3299 DOI 10.17487/RFC4250, January 2006, 3300 . 3302 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 3303 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 3304 March 2011, . 3306 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 3307 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 3308 DOI 10.17487/RFC6234, May 2011, 3309 . 3311 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3312 and A. Bierman, Ed., "Network Configuration Protocol 3313 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3314 . 3316 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3317 Cheshire, "Internet Assigned Numbers Authority (IANA) 3318 Procedures for the Management of the Service Name and 3319 Transport Protocol Port Number Registry", BCP 165, 3320 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3321 . 3323 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3324 of Named Entities (DANE) Transport Layer Security (TLS) 3325 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3326 2012, . 3328 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3329 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3330 . 3332 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 3333 for DNS (EDNS(0))", STD 75, RFC 6891, 3334 DOI 10.17487/RFC6891, April 2013, 3335 . 3337 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3338 Galperin, S., and C. Adams, "X.509 Internet Public Key 3339 Infrastructure Online Certificate Status Protocol - OCSP", 3340 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3341 . 3343 [RFC7107] Housley, R., "Object Identifier Registry for the S/MIME 3344 Mail Security Working Group", RFC 7107, 3345 DOI 10.17487/RFC7107, January 2014, 3346 . 3348 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 3349 D. Wessels, "DNS Transport over TCP - Implementation 3350 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 3351 . 3353 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 3354 RFC 8071, DOI 10.17487/RFC8071, February 2017, 3355 . 3357 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3358 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3359 . 3361 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3362 Access Control Model", STD 91, RFC 8341, 3363 DOI 10.17487/RFC8341, March 2018, 3364 . 3366 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3367 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3368 . 3370 Appendix A. Example Device Data Model 3372 This section defines a non-normative data model that enables the 3373 configuration of SZTP bootstrapping and discovery of what parameters 3374 are used by a device's bootstrapping logic. 3376 A.1. Data Model Overview 3378 The following tree diagram provides an overview for the SZTP device 3379 data model. 3381 module: example-device-data-model 3382 +--rw sztp 3383 +--rw enabled? boolean 3384 +--ro idevid-certificate? ct:end-entity-cert-cms 3385 | {bootstrap-servers}? 3386 +--ro bootstrap-servers {bootstrap-servers}? 3387 | +--ro bootstrap-server* [address] 3388 | +--ro address inet:host 3389 | +--ro port? inet:port-number 3390 +--ro bootstrap-server-trust-anchors {bootstrap-servers}? 3391 | +--ro reference* ta:pinned-certificates-ref 3392 +--ro voucher-trust-anchors {signed-data}? 3393 +--ro reference* ta:pinned-certificates-ref 3395 In the above diagram, notice that there is only one configurable node 3396 "enabled". The expectation is that this node would be set to "true" 3397 in device's factory default configuration and that it would either be 3398 set to "false" or deleted when the SZTP bootstrapping is longer 3399 needed. 3401 A.2. Example Usage 3403 Following is an instance example for this data model. 3405 3406 true 3407 base64encodedvalue== 3408 3409 3410
sztp1.example.com
3411 8443 3412 3413 3414
sztp2.example.com
3415 8443 3416 3417 3418
sztp3.example.com
3419 8443 3420 3421 3422 3423 manufacturers-root-ca-certs 3424 3425 3426 manufacturers-root-ca-certs 3427 3428 3430 A.3. YANG Module 3432 The device model is defined by the YANG module defined in this 3433 section. 3435 This module uses data types defined in [RFC6991], 3436 [I-D.ietf-netconf-crypto-types], and 3437 [I-D.ietf-netconf-trust-anchors]. 3439 module example-device-data-model { 3440 yang-version 1.1; 3441 namespace "https://example.com/sztp-device-data-model"; 3442 prefix sztp-ddm; 3444 import ietf-inet-types { 3445 prefix inet; 3446 reference "RFC 6991: Common YANG Data Types"; 3447 } 3449 import ietf-crypto-types { 3450 prefix ct; 3451 revision-date 2018-06-04; 3452 description 3453 "This revision is defined in the -00 version of 3454 draft-ietf-netconf-crypto-types"; 3455 reference 3456 "draft-ietf-netconf-crypto-types: 3457 Common YANG Data Types for Cryptography"; 3458 } 3460 import ietf-trust-anchors { 3461 prefix ta; 3462 revision-date 2018-06-04; 3463 description 3464 "This revision is defined in -00 version of 3465 draft-ietf-netconf-trust-anchors."; 3466 reference 3467 "draft-ietf-netconf-trust-anchors: 3468 YANG Data Model for Global Trust Anchors"; 3469 } 3471 organization 3472 "Example Corporation"; 3474 contact 3475 "Author: Bootstrap Admin "; 3477 description 3478 "This module defines a data model to enable SZTP 3479 bootstrapping and discover what parameters are used. 3480 This module assumes the use of an IDevID certificate, 3481 as opposed to any other client certificate, or the 3482 use of an HTTP-based client authentication scheme."; 3484 revision 2019-01-15 { 3485 description 3486 "Initial version"; 3487 reference 3488 "RFC XXXX: Secure Zero Touch Provisioning (SZTP)"; 3489 } 3491 // features 3493 feature bootstrap-servers { 3494 description 3495 "The device supports bootstrapping off bootstrap servers."; 3496 } 3498 feature signed-data { 3499 description 3500 "The device supports bootstrapping off signed data."; 3502 } 3504 // protocol accessible nodes 3506 container sztp { 3507 description 3508 "Top-level container for SZTP data model."; 3509 leaf enabled { 3510 type boolean; 3511 default false; 3512 description 3513 "The 'enabled' leaf controls if SZTP bootstrapping is 3514 enabled or disabled. The default is 'false' so that, when 3515 not enabled, which is most of the time, no configuration 3516 is needed."; 3517 } 3518 leaf idevid-certificate { 3519 if-feature bootstrap-servers; 3520 type ct:end-entity-cert-cms; 3521 config false; 3522 description 3523 "This CMS structure contains the IEEE 802.1AR-2009 3524 IDevID certificate itself, and all intermediate 3525 certificates leading up to, and optionally including, 3526 the manufacturer's well-known trust anchor certificate 3527 for IDevID certificates. The well-known trust anchor 3528 does not have to be a self-signed certificate."; 3529 reference 3530 "IEEE 802.1AR-2009: 3531 IEEE Standard for Local and metropolitan area 3532 networks - Secure Device Identity."; 3533 } 3534 container bootstrap-servers { 3535 if-feature bootstrap-servers; 3536 config false; 3537 description 3538 "List of bootstrap servers this device will attempt 3539 to reach out to when bootstrapping."; 3540 list bootstrap-server { 3541 key "address"; 3542 description 3543 "A bootstrap server entry."; 3544 leaf address { 3545 type inet:host; 3546 mandatory true; 3547 description 3548 "The IP address or hostname of the bootstrap server the 3549 device should redirect to."; 3551 } 3552 leaf port { 3553 type inet:port-number; 3554 default "443"; 3555 description 3556 "The port number the bootstrap server listens on. If no 3557 port is specified, the IANA-assigned port for 'https' 3558 (443) is used."; 3559 } 3560 } 3561 } 3562 container bootstrap-server-trust-anchors { 3563 if-feature bootstrap-servers; 3564 config false; 3565 description "Container for a list of trust anchor references."; 3566 leaf-list reference { 3567 type ta:pinned-certificates-ref; 3568 description 3569 "A reference to a list of pinned certificate authority (CA) 3570 certificates that the device uses to validate bootstrap 3571 servers with."; 3572 } 3573 } 3574 container voucher-trust-anchors { 3575 if-feature signed-data; 3576 config false; 3577 description "Container for a list of trust anchor references."; 3578 leaf-list reference { 3579 type ta:pinned-certificates-ref; 3580 description 3581 "A reference to a list of pinned certificate authority (CA) 3582 certificates that the device uses to validate ownership 3583 vouchers with."; 3584 } 3585 } 3586 } 3587 } 3589 Appendix B. Promoting a Connection from Untrusted to Trusted 3591 The following diagram illustrates a sequence of bootstrapping 3592 activities that promote an untrusted connection to a bootstrap server 3593 to a trusted connection to the same bootstrap server. This enables a 3594 device to limit the amount of information it might disclose to an 3595 adversary hosting an untrusted bootstrap server. 3597 +----------+ 3598 |Deployment| 3599 | Specific | 3600 +------+ |Bootstrap | 3601 |Device| | Server | 3602 +------+ +----------+ 3603 | | 3604 | 1. "HTTPS" Request ("signed-data-preferred", nonce) | 3605 |------------------------------------------------------->| 3606 | 2. "HTTPS" Response (signed redirect information) | 3607 |<-------------------------------------------------------| 3608 | | 3609 | | 3610 | 3. HTTPS Request (os-name=xyz, os-version=123, etc.) | 3611 |------------------------------------------------------->| 3612 | 4. HTTPS Response (unsigned onboarding information | 3613 |<-------------------------------------------------------| 3614 | | 3616 The interactions in the above diagram are described below. 3618 1. The device initiates an untrusted connection to a bootstrap 3619 server, as is indicated by putting "HTTPS" in double quotes 3620 above. It is still an HTTPS connection, but the device is unable 3621 to authenticate the bootstrap server's TLS certificate. Because 3622 the device is unable to trust the bootstrap server, it sends the 3623 "signed-data-preferred" input parameter, and optionally also the 3624 "nonce" input parameter, in the "get-bootstrapping-data" RPC. 3625 The "signed-data-preferred" parameter informs the bootstrap 3626 server that the device does not trust it and may be holding back 3627 some additional input parameters from the server (e.g., other 3628 input parameters, progress reports, etc.). The "nonce" input 3629 parameter enables the bootstrap server to dynamically obtain an 3630 ownership voucher from a MASA, which may be important for devices 3631 that do not have a reliable clock. 3633 2. The bootstrap server, seeing the "signed-data-preferred" input 3634 parameter, knows that it can either send unsigned redirect 3635 information or signed data of any type. But, in this case, the 3636 bootstrap server has the ability to sign data and chooses to 3637 respond with signed redirect information, not signed onboarding 3638 information as might be expected, securely redirecting the device 3639 back to it again. Not displayed but, if the "nonce" input 3640 parameter was passed, the bootstrap server could dynamically 3641 connect to a download a voucher from the MASA having the nonce 3642 value in it. Details regarding a protocol enabling this 3643 integration is outside the scope of this document. 3645 3. Upon validating the signed redirect information, the device 3646 establishes a secure connection to the bootstrap server. 3647 Unbeknownst to the device, it is the same bootstrap server it was 3648 connected to previously but, because the device is able to 3649 authenticate the bootstrap server this time, it sends its normal 3650 "get-bootstrapping-data" request (i.e., with additional input 3651 parameters) as well as its progress reports (not depicted). 3653 4. This time, because the "signed-data-preferred" parameter was not 3654 passed, having access to all of the device's input parameters, 3655 the bootstrap server returns, in this example, unsigned 3656 onboarding information to the device. Note also that, because 3657 the bootstrap server is now trusted, the device will send 3658 progress reports to the server. 3660 Appendix C. Workflow Overview 3662 The solution presented in this document is conceptualized to be 3663 composed of the non-normative workflows described in this section. 3664 Implementation details are expected to vary. Each diagram is 3665 followed by a detailed description of the steps presented in the 3666 diagram, with further explanation on how implementations may vary. 3668 C.1. Enrollment and Ordering Devices 3670 The following diagram illustrates key interactions that may occur 3671 from when a prospective owner enrolls in a manufacturer's SZTP 3672 program to when the manufacturer ships devices for an order placed by 3673 the prospective owner. 3675 +-----------+ 3676 +------------+ |Prospective| +---+ 3677 |Manufacturer| | Owner | |NMS| 3678 +------------+ +-----------+ +---+ 3679 | | | 3680 | | | 3681 | 1. initiate enrollment | | 3682 #<-----------------------------| | 3683 # | | 3684 # | | 3685 # IDevID trust anchor | | 3686 #-----------------------------># set IDevID trust anchor | 3687 # #--------------------------->| 3688 # | | 3689 # bootstrap server | | 3690 # account credentials | | 3691 #-----------------------------># set credentials | 3692 | #--------------------------->| 3693 | | | 3694 | | | 3695 | 2. set owner certificate trust anchor | 3696 |<----------------------------------------------------------| 3697 | | | 3698 | | | 3699 | 3. place device order | | 3700 |<-----------------------------# model devices | 3701 | #--------------------------->| 3702 | | | 3703 | 4. ship devices and send | | 3704 | device identifiers and | | 3705 | ownership vouchers | | 3706 |-----------------------------># set device identifiers | 3707 | # and ownership vouchers | 3708 | #--------------------------->| 3709 | | | 3711 Each numbered item below corresponds to a numbered item in the 3712 diagram above. 3714 1. A prospective owner of a manufacturer's devices initiates an 3715 enrollment process with the manufacturer. This process includes 3716 the following: 3718 * Regardless how the prospective owner intends to bootstrap 3719 their devices, they will always obtain from the manufacturer 3720 the trust anchor certificate for the IDevID certificates. 3721 This certificate will is installed on the prospective owner's 3722 NMS so that the NMS can authenticate the IDevID certificates 3723 when they are presented to subsequent steps. 3725 * If the manufacturer hosts an Internet based bootstrap server 3726 (e.g., a redirect server) such as described in Section 4.4, 3727 then credentials necessary to configure the bootstrap server 3728 would be provided to the prospective owner. If the bootstrap 3729 server is configurable through an API (outside the scope of 3730 this document), then the credentials might be installed on the 3731 prospective owner's NMS so that the NMS can subsequently 3732 configure the manufacturer-hosted bootstrap server directly. 3734 2. If the manufacturer's devices are able to validate signed data 3735 (Section 5.4), and assuming that the prospective owner's NMS is 3736 able to prepare and sign the bootstrapping data itself, the 3737 prospective owner's NMS might set a trust anchor certificate onto 3738 the manufacturer's bootstrap server, using the credentials 3739 provided in the previous step. This certificate is the trust 3740 anchor certificate that the prospective owner would like the 3741 manufacturer to place into the ownership vouchers it generates, 3742 thereby enabling devices to trust the owner's owner certificate. 3743 How this trust anchor certificate is used to enable devices to 3744 validate signed bootstrapping data is described in Section 5.4. 3746 3. Some time later, the prospective owner places an order with the 3747 manufacturer, perhaps with a special flag checked for SZTP 3748 handling. At this time, or perhaps before placing the order, the 3749 owner may model the devices in their NMS, creating virtual 3750 objects for the devices with no real-world device associations. 3751 For instance the model can be used to simulate the device's 3752 location in the network and the configuration it should have when 3753 fully operational. 3755 4. When the manufacturer fulfills the order, shipping the devices to 3756 their intended locations, they may notify the owner of the 3757 devices' serial numbers and shipping destinations, which the 3758 owner may use to stage the network for when the devices power on. 3759 Additionally, the manufacturer may send one or more ownership 3760 vouchers, cryptographically assigning ownership of those devices 3761 to the owner. The owner may set this information on their NMS, 3762 perhaps binding specific modeled devices to the serial numbers 3763 and ownership vouchers. 3765 C.2. Owner Stages the Network for Bootstrap 3767 The following diagram illustrates how an owner might stage the 3768 network for bootstrapping devices. 3770 +----------+ +------------+ 3771 |Deployment| |Manufacturer| +------+ +------+ 3772 | Specific | | Hosted | | Local| | Local| +---------+ 3773 +---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| 3774 |NMS| | Server | | Server | |Server| |Server| | Storage | 3775 +---+ +----------+ +------------+ +------+ +------+ +---------+ 3776 | | | | | | 3777 1. | | | | | | 3778 activate| | | | | | 3779 modeled | | | | | | 3780 device | | | | | | 3781 ------->| | | | | | 3782 | 2. (optional) | | | | 3783 | configure | | | | 3784 | bootstrap | | | | 3785 | server | | | | 3786 |------->| | | | | 3787 | | | | | | 3788 | 3. (optional) configure | | | 3789 | bootstrap server | | | | 3790 |--------------------->| | | | 3791 | | | | | | 3792 | | | | | | 3793 | 4. (optional) configure DNS server| | | 3794 |---------------------------------->| | | 3795 | | | | | | 3796 | | | | | | 3797 | 5. (optional) configure DHCP server | | 3798 |------------------------------------------->| | 3799 | | | | | | 3800 | | | | | | 3801 | 6. (optional) store bootstrapping artifacts on media | 3802 |----------------------------------------------------->| 3803 | | | | | | 3804 | | | | | | 3806 Each numbered item below corresponds to a numbered item in the 3807 diagram above. 3809 1. Having previously modeled the devices, including setting their 3810 fully operational configurations and associating device serial 3811 numbers and (optionally) ownership vouchers, the owner might 3812 "activate" one or more modeled devices. That is, the owner tells 3813 the NMS to perform the steps necessary to prepare for when the 3814 real-world devices power up and initiate the bootstrapping 3815 process. Note that, in some deployments, this step might be 3816 combined with the last step from the previous workflow. Here it 3817 is depicted that an NMS performs the steps, but they may be 3818 performed manually or through some other mechanism. 3820 2. If it is desired to use a deployment-specific bootstrap server, 3821 it must be configured to provide the bootstrapping data for the 3822 specific devices. Configuring the bootstrap server may occur via 3823 a programmatic API not defined by this document. Illustrated 3824 here as an external component, the bootstrap server may be 3825 implemented as an internal component of the NMS itself. 3827 3. If it is desired to use a manufacturer hosted bootstrap server, 3828 it must be configured to provide the bootstrapping data for the 3829 specific devices. The configuration must be either redirect or 3830 onboarding information. That is, either the manufacturer hosted 3831 bootstrap server will redirect the device to another bootstrap 3832 server, or provide the device with the onboarding information 3833 itself. The types of bootstrapping data the manufacturer hosted 3834 bootstrap server supports may vary by implementation; some 3835 implementations may only support redirect information, or only 3836 support onboarding information, or support both redirect and 3837 onboarding information. Configuring the bootstrap server may 3838 occur via a programmatic API not defined by this document. 3840 4. If it is desired to use a DNS server to supply bootstrapping 3841 data, a DNS server needs to be configured. If multicast DNS-SD 3842 is desired, then the DNS server must reside on the local network, 3843 otherwise the DNS server may reside on a remote network. Please 3844 see Section 4.2 for more information about how to configure DNS 3845 servers. Configuring the DNS server may occur via a programmatic 3846 API not defined by this document. 3848 5. If it is desired to use a DHCP server to supply bootstrapping 3849 data, a DHCP server needs to be configured. The DHCP server may 3850 be accessed directly or via a DHCP relay. Please see Section 4.3 3851 for more information about how to configure DHCP servers. 3852 Configuring the DHCP server may occur via a programmatic API not 3853 defined by this document. 3855 6. If it is desired to use a removable storage device (e.g., USB 3856 flash drive) to supply bootstrapping data, the data would need to 3857 be placed onto it. Please see Section 4.1 for more information 3858 about how to configure a removable storage device. 3860 C.3. Device Powers On 3862 The following diagram illustrates the sequence of activities that 3863 occur when a device powers on. 3865 +----------+ 3866 +-----------+ |Deployment| 3867 | Source of | | Specific | 3868 +------+ | Bootstrap | |Bootstrap | +---+ 3869 |Device| | Data | | Server | |NMS| 3870 +------+ +-----------+ +----------+ +---+ 3871 | | | | 3872 | | | | 3873 | 1. if SZTP bootstrap service | | | 3874 | is not enabled, then exit. | | | 3875 | | | | 3876 | 2. for each source supported, check | | | 3877 | for bootstrapping data. | | | 3878 |------------------------------------>| | | 3879 | | | | 3880 | 3. if onboarding information found, | | | 3881 | initialize self and, only if | | | 3882 | source is a trusted bootstrap | | | 3883 | server, send progress reports. | | | 3884 |------------------------------------># | | 3885 | # webhook | | 3886 | #----------------------->| 3887 | | | 3888 | 4. else if redirect-information found, for each | | 3889 | bootstrap server specified, check for data. | | 3890 |-+------------------------------------------------->| | 3891 | | | | 3892 | | if more redirect-information is found, recurse | | 3893 | | (not depicted), else if onboarding information | | 3894 | | found, initialize self and post progress reports | | 3895 | +-------------------------------------------------># | 3896 | # webhook | 3897 | #-------->| 3898 | 3899 | 5. retry sources and/or wait for manual provisioning. 3900 | 3902 The interactions in the above diagram are described below. 3904 1. Upon power being applied, the device checks to see if SZTP 3905 bootstrapping is configured, such as must be the case when 3906 running its "factory default" configuration. If SZTP 3907 bootstrapping is not configured, then the bootstrapping logic 3908 exits and none of the following interactions occur. 3910 2. For each source of bootstrapping data the device supports, 3911 preferably in order of closeness to the device (e.g., removable 3912 storage before Internet based servers), the device checks to see 3913 if there is any bootstrapping data for it there. 3915 3. If onboarding information is found, the device initializes itself 3916 accordingly (e.g., installing a boot-image and committing an 3917 initial configuration). If the source is a bootstrap server, and 3918 the bootstrap server can be trusted (i.e., TLS-level 3919 authentication), the device also sends progress reports to the 3920 bootstrap server. 3922 * The contents of the initial configuration should configure an 3923 administrator account on the device (e.g., username, SSH 3924 public key, etc.), and should configure the device either to 3925 listen for NETCONF or RESTCONF connections or to initiate call 3926 home connections [RFC8071], and should disable the SZTP 3927 bootstrapping service (e.g., the "enabled" leaf in data model 3928 presented in Appendix A). 3930 * If the bootstrap server supports forwarding device progress 3931 reports to external systems (e.g., via a webhook), a 3932 "bootstrap-complete" progress report (Section 7.3) informs the 3933 external system to know when it can, for instance, initiate a 3934 connection to the device. To support this scenario further, 3935 the "bootstrap-complete" progress report may also relay the 3936 device's SSH host keys and/or TLS certificates, with which the 3937 external system can use to authenticate subsequent connections 3938 to the device. 3940 If the device successfully completes the bootstrapping process, 3941 it exits the bootstrapping logic without considering any 3942 additional sources of bootstrapping data. 3944 4. Otherwise, if redirect information is found, the device iterates 3945 through the list of specified bootstrap servers, checking to see 3946 if the bootstrap server has bootstrapping data for the device. 3947 If the bootstrap server returns more redirect information, then 3948 the device processes it recursively. Otherwise, if the bootstrap 3949 server returns onboarding information, the device processes it 3950 following the description provided in (3) above. 3952 5. After having tried all supported sources of bootstrapping data, 3953 the device may retry again all the sources and/or provide 3954 manageability interfaces for manual configuration (e.g., CLI, 3955 HTTP, NETCONF, etc.). If manual configuration is allowed, and 3956 such configuration is provided, the configuration should also 3957 disable the SZTP bootstrapping service, as the need for 3958 bootstrapping would no longer be present. 3960 Appendix D. Change Log 3962 D.1. ID to 00 3964 o Major structural update; the essence is the same. Most every 3965 section was rewritten to some degree. 3967 o Added a Use Cases section 3969 o Added diagrams for "Actors and Roles" and "NMS Precondition" 3970 sections, and greatly improved the "Device Boot Sequence" diagram 3972 o Removed support for physical presence or any ability for 3973 configlets to not be signed. 3975 o Defined the Conveyed Information DHCP option 3977 o Added an ability for devices to also download images from 3978 configuration servers 3980 o Added an ability for configlets to be encrypted 3982 o Now configuration servers only have to support HTTP/S - no other 3983 schemes possible 3985 D.2. 00 to 01 3987 o Added boot-image and validate-owner annotations to the "Actors and 3988 Roles" diagram. 3990 o Fixed 2nd paragraph in section 7.1 to reflect current use of 3991 anyxml. 3993 o Added encrypted and signed-encrypted examples 3995 o Replaced YANG module with XSD schema 3997 o Added IANA request for the Conveyed Information DHCP Option 3999 o Added IANA request for media types for boot-image and 4000 configuration 4002 D.3. 01 to 02 4004 o Replaced the need for a configuration signer with the ability for 4005 each NMS to be able to sign its own configurations, using 4006 manufacturer signed ownership vouchers and owner certificates. 4008 o Renamed configuration server to bootstrap server, a more 4009 representative name given the information devices download from 4010 it. 4012 o Replaced the concept of a configlet by defining a southbound 4013 interface for the bootstrap server using YANG. 4015 o Removed the IANA request for the boot-image and configuration 4016 media types 4018 D.4. 02 to 03 4020 o Minor update, mostly just to add an Editor's Note to show how this 4021 draft might integrate with the draft-pritikin-anima-bootstrapping- 4022 keyinfra. 4024 D.5. 03 to 04 4026 o Major update formally introducing unsigned data and support for 4027 Internet-based redirect servers. 4029 o Added many terms to Terminology section. 4031 o Added all new "Guiding Principles" section. 4033 o Added all new "Sources for Bootstrapping Data" section. 4035 o Rewrote the "Interactions" section and renamed it "Workflow 4036 Overview". 4038 D.6. 04 to 05 4040 o Semi-major update, refactoring the document into more logical 4041 parts 4043 o Created new section for information types 4045 o Added support for DNS servers 4047 o Now allows provisional TLS connections 4049 o Bootstrapping data now supports scripts 4051 o Device Details section overhauled 4053 o Security Considerations expanded 4055 o Filled in enumerations for notification types 4057 D.7. 05 to 06 4059 o Minor update 4061 o Added many Normative and Informative references. 4063 o Added new section Other Considerations. 4065 D.8. 06 to 07 4067 o Minor update 4069 o Added an Editorial Note section for RFC Editor. 4071 o Updated the IANA Considerations section. 4073 D.9. 07 to 08 4075 o Minor update 4077 o Updated to reflect review from Michael Richardson. 4079 D.10. 08 to 09 4081 o Added in missing "Signature" artifact example. 4083 o Added recommendation for manufacturers to use interoperable 4084 formats and file naming conventions for removable storage devices. 4086 o Added configuration-handling leaf to guide if config should be 4087 merged, replaced, or processed like an edit-config/yang-patch 4088 document. 4090 o Added a pre-configuration script, in addition to the post- 4091 configuration script from -05 (issue #15). 4093 D.11. 09 to 10 4095 o Factored ownership voucher and voucher revocation to a separate 4096 document: draft-kwatsen-netconf-voucher. (issue #11) 4098 o Removed options "edit-config" and "yang- 4099 patch". (issue #12) 4101 o Defined how a signature over signed-data returned from a bootstrap 4102 server is processed. (issue #13) 4104 o Added recommendation for removable storage devices to use open/ 4105 standard file systems when possible. (issue #14) 4107 o Replaced notifications "script-[warning/error]" with "[pre/post]- 4108 script-[warning/error]". (goes with issue #15) 4110 o switched owner-certificate to be encoded using the PKCS #7 format. 4111 (issue #16) 4113 o Replaced md5/sha1 with sha256 inside a choice statement, for 4114 future extensibility. (issue #17) 4116 o A ton of editorial changes, as I went thru the entire draft with a 4117 fine-toothed comb. 4119 D.12. 10 to 11 4121 o fixed yang validation issues found by IETFYANGPageCompilation. 4122 note: these issues were NOT found by pyang --ietf or by the 4123 submission-time validator... 4125 o fixed a typo in the yang module, someone the config false 4126 statement was removed. 4128 D.13. 11 to 12 4130 o fixed typo that prevented Appendix B from loading the examples 4131 correctly. 4133 o fixed more yang validation issues found by 4134 IETFYANGPageCompilation. note: again, these issues were NOT found 4135 by pyang --ietf or by the submission-time validator... 4137 o updated a few of the notification enumerations to be more 4138 consistent with the other enumerations (following the warning/ 4139 error pattern). 4141 o updated the information-type artifact to state how it is encoded, 4142 matching the language that was in Appendix B. 4144 D.14. 12 to 13 4146 o defined a standalone artifact to encode the old information-type 4147 into a PKCS #7 structure. 4149 o standalone information artifact hardcodes JSON encoding (to match 4150 the voucher draft). 4152 o combined the information and signature PKCS #7 structures into a 4153 single PKCS #7 structure. 4155 o moved the certificate-revocations into the owner-certificate's 4156 PKCS #7 structure. 4158 o eliminated support for voucher-revocations, to reflect the 4159 voucher-draft's switch from revocations to renewals. 4161 D.15. 13 to 14 4163 o Renamed "bootstrap information" to "onboarding information". 4165 o Rewrote DHCP sections to address the packet-size limitation issue, 4166 as discussed in Chicago. 4168 o Added Ian as an author for his text-contributions to the DHCP 4169 sections. 4171 o Removed the Guiding Principles section. 4173 D.16. 14 to 15 4175 o Renamed action "notification" to "update-progress" and, likewise 4176 "notification-type" to "update-type". 4178 o Updated examples to use "base64encodedvalue==" for binary values. 4180 o Greatly simplified the "Artifact Groupings" section, and moved it 4181 as a subsection to the "Artifacts" section. 4183 o Moved the "Workflow Overview" section to the Appendix. 4185 o Renamed "bootstrap information" to "update information". 4187 o Removed "Other Considerations" section. 4189 o Tons of editorial updates. 4191 D.17. 15 to 16 4193 o tweaked language to refer to "initial state" rather than "factory 4194 default configuration", so as accommodate white-box scenarios. 4196 o added a paragraph to Intro regarding how the solution primarily 4197 regards physical machines, but could be extended to VMs by a 4198 future document. 4200 o added a pointer to the Workflow Overview section (recently moved 4201 to the Appendix) to the Intro. 4203 o added a note that, in order to simplify the verification process, 4204 the "Conveyed Information" PKCS #7 structure MUST also contain the 4205 signing X.509 certificate. 4207 o noted that the owner certificate's must either have no Key Usage 4208 or the Key Usage must set the "digitalSignature" bit. 4210 o noted that the owner certificate's subject and subjectAltName 4211 values are not constrained. 4213 o moved/consolidated some text from the Artifacts section down to 4214 the Device Details section. 4216 o tightened up some ambiguous language, for instance, by referring 4217 to specific leaf names in the Voucher artifact. 4219 o reverted a previously overzealous s/unique-id/serial-number/ 4220 change. 4222 o modified language for when ZTP runs from when factory-default 4223 config is running to when ZTP is configured, which the factory- 4224 defaults should set . 4226 D.18. 16 to 17 4228 o Added an example for how to promote an untrusted connection to a 4229 trusted connection. 4231 o Added a "query parameters" section defining some parameters 4232 enabling scenarios raised in last call. 4234 o Added a "Disclosing Information to Untrusted Servers" section to 4235 the Security Considerations. 4237 D.19. 17 to 18 4239 o Added Security Considerations for each YANG module. 4241 o Reverted back to the device always sending its DevID cert. 4243 o Moved data tree to "get-bootstrapping-data" RPC. 4245 o Moved the "update-progress" action to a "report-progress" RPC. 4247 o Added an "signed-data-preferred" parameter to "get-bootstrapping- 4248 data" RPC. 4250 o Added the "ietf-zerotouch-device" module. 4252 o Lots of small updates. 4254 D.20. 18 to 19 4256 o Fixed "must" expressions, by converting "choice" to a "list" of 4257 "image-verification", each of which now points to a base identity 4258 called "hash-algorithm". There's just one algorithm currently 4259 defined (sha-256). Wish there was a standard crypto module that 4260 could identify such identities. 4262 D.21. 19 to 20 4264 o Now references I-D.ietf-netmod-yang-tree-diagrams. 4266 o Fixed tree-diagrams in Section 2 to always reflect current YANG 4267 (now they are now dynamically generated). 4269 o The "redirect-information" container's "trust-anchor" is now a CMS 4270 structure that can contain a chain of certificates, rather than a 4271 single certificate. 4273 o The "onboarding-information" container's support for image 4274 verification reworked to be extensible. 4276 o Added a reference to the "Device Details" section to the new 4277 example-device-data-model module. 4279 o Clarified that the device must always pass its IDevID certificate, 4280 even for untrusted bootstrap servers. 4282 o Fixed the description statement for the "script" typedef to refer 4283 to the [pre/post]-script-[warning/error] enums, rather than the 4284 legacy script-[warning/error] enums. 4286 o For the get-bootstrapping-data RPC's input, removed the "remote- 4287 id" and "circuit-id" fields, and added a "hw-model" field. 4289 o Improved DHCP error handling text. 4291 o Added MUST requirement for DHCPv6 client and server implementing 4292 [RFC3396] to handle URI lists longer than 255 octets. 4294 o Changed the "configuration" value in onboarding-information to be 4295 type "binary" instead of "anydata". 4297 o Moved everything from PKCS#7 to CMS (this shows up as a big 4298 change). 4300 o Added the early code point allocation assignments for the DHCP 4301 Options in the IANA Considerations section, and updated the RFC 4302 Editor note accordingly. 4304 o Added RFC Editor request to replace the assigned values for the 4305 CMS content types. 4307 o Relaxed auth requirements from device needing to always send 4308 IDevID cert to device needing to always send authentication 4309 credentials, as this better matches what RFC 8040 Section 2.5 4310 says. 4312 o Moved normative module "ietf-zerotouch-device" to non-normative 4313 module "example-device-data-model". 4315 o Updated Title, Abstract, and Introduction per discussion on list. 4317 D.22. 20 to 21 4319 o Now any of the three artifact can be encrypted. 4321 o Fixed some line-too-long issues. 4323 D.23. 21 to 22 4325 o Removed specifics around how scripts indicate warnings or errors 4326 and how scripts emit output. 4328 o Moved the SZTP Device Data Model section to the Appendix. 4330 o Modified the YANG module in the SZTP Device Data Model section to 4331 reflect the latest trust-anchors and keystore drafts. 4333 o Modified types in other YANG modules to more closely emulate what 4334 is in draft-ietf-netconf-crypto-types. 4336 D.24. 22 to 23 4338 o Rewrote section 5.6 (processing onboboarding information) to be 4339 clearer about error handling and retained state. Specifically: 4341 * Clarified that a script, upon having an error, must gracefully 4342 exit, cleaning up any state that might hinder subsequent 4343 executions. 4345 * Added ability for scripts to be executed again with a flag 4346 enabling them to clean up state from a previous execution. 4348 * Clarified that the conifguration commit is atomic. 4350 * Clarified that any error encountered after committing the 4351 configuration (e.g., in the "post-configuration-script") must 4352 rollback the configuration to the previous configuration. 4354 * Clarified that failure to successfully deliver the "bootstrap- 4355 initiated" and "bootstrap-complete" progress types must be 4356 treated as an error. 4358 * Clarified that "return to bootstrapping sequence" is to be 4359 interpreted in the recursive context. Meaning that the device 4360 rolls-back one loop, rather than start over from scratch. 4362 o Changed how a device verifies a boot-image from just "MUST match 4363 one of the supplied fingerprints" to also allow for the 4364 verification to use an cryptographic signature embedded into the 4365 image itself. 4367 o Added more "progress-type" enums for visibility reasons, enabling 4368 more strongly-typed debug information to be sent to the bootstrap 4369 server. 4371 o Added Security Considerations based on early SecDir review. 4373 o Added recommendation for device to send warning if the initial 4374 config does not disable the bootstrapping process. 4376 D.25. 23 to 24 4378 o Follow-ups from SecDir and Shepherd. 4380 o Added "boot-image-complete" enumeration. 4382 D.26. 24 to 25 4384 o Removed remaining old "bootstrapping information" term usage. 4386 o Fixed DHCP Option length definition. 4388 o Added reference to RFC 6187. 4390 D.27. 25 to 26 4392 o Updated URI structure text (sec 8.3) and added norm. ref to 4393 RFC7230 reflecting Alexey Melnikov's comment. 4395 o Added IANA registration for the 'zerotouch' service, per IESG 4396 review from Adam Roach. 4398 o Clarified device's looping behavior and support for alternative 4399 provisioning mechanisms, per IESG review from Mirja Kuehlewind. 4401 o Updated "ietf-sztp-bootstrap-server:ssh-host-key" from leaf-list 4402 to list, per IESG review from Benjamin Kaduk. 4404 o Added option size text to DHCPv4 option size to address Suresh 4405 Krishnan's IESG review discuss point. 4407 o Updated RFC3315 to RFC8415 and associated section references. 4409 o Revamped the DNS Server section, after digging into Alexey 4410 Melnikov comment. 4412 o Fixed IETF terminology template section in both YANG modules. 4414 D.28. 26 to 27 4416 o Added Security Consideration for cascading trust via redirects. 4418 o Modified the get-bootstrapping-data RPC's "nonce" input parameter 4419 to being a minimum of 16-bytes (used to be 8-bytes). 4421 o Added Security Consideration regarding possible reuse of device's 4422 private key. 4424 o Added Security Consideration regarding use of sign-then-encrypt. 4426 o Renamed "Zero Touch"/"zerotouch" throughout. Now uses "SZTP" when 4427 referring to the draft/solution, and "conveyed" when referring to 4428 the bootstrapping artifact. 4430 o Added missing text for "encrypted unsigned conveyed information" 4431 case. 4433 o Renamed "untrusted-connection" input paramter to "signed-data- 4434 preferred" 4436 o Switch yd:yang-data back to rc:yang-data 4437 o Added a couple features to the bootstrap-server module. 4439 D.29. 27 to 28 4441 o Modified DNS section to no longer reference DNS-SD (now just plain 4442 TXT and SRV lookups, via multicast or unicast. 4444 o Registers "_sztp" in the DNS Underscore Global Scoped Entry 4445 Registry. 4447 o Updated 802.1AR reference to current spec version. 4449 Acknowledgements 4451 The authors would like to thank for following for lively discussions 4452 on list and in the halls (ordered by last name): Michael Behringer, 4453 Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Dave Crocker, Toerless 4454 Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, David 4455 Harrington, Mirja Kuehlewind, Radek Krejci, Suresh Krishnan, Benjamin 4456 Kaduk, David Mandelberg, Alexey Melnikov, Russ Mundy, Reinaldo Penno, 4457 Randy Presuhn, Max Pritikin, Michael Richardson, Adam Roach, Phil 4458 Shafer, Juergen Schoenwaelder. 4460 Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for 4461 brainstorming the original solution during the IETF 87 meeting in 4462 Berlin. 4464 Authors' Addresses 4466 Kent Watsen 4467 Juniper Networks 4469 EMail: kwatsen@juniper.net 4471 Mikael Abrahamsson 4472 T-Systems 4474 EMail: mikael.abrahamsson@t-systems.se 4476 Ian Farrer 4477 Deutsche Telekom AG 4479 EMail: ian.farrer@telekom.de