idnits 2.17.00 (12 Aug 2021) /tmp/idnits54337/draft-ietf-opsawg-sdi-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2020) is 760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AU' is mentioned on line 687, but not defined == Missing Reference: 'Some-State' is mentioned on line 688, but not defined == Outdated reference: draft-gutmann-scep has been published as RFC 8894 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: draft-ietf-opsawg-tacacs has been published as RFC 8907 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational C. Doyle 5 Expires: October 23, 2020 Juniper Networks 6 April 21, 2020 8 Secure Device Install 9 draft-ietf-opsawg-sdi-08 11 Abstract 13 Deploying a new network device in a location where the operator has 14 no staff of its own often requires that an employee physically travel 15 to the location to perform the initial install and configuration, 16 even in shared datacenters with "smart-hands" type support. In many 17 cases, this could be avoided if there were a secure way to initially 18 provision the device. 20 This document extends existing auto-install / Zero-Touch Provisioning 21 mechanisms to make the process more secure. 23 [ Ed note: Text inside square brackets ([]) is additional background 24 information, answers to frequently asked questions, general musings, 25 etc. They will be removed before publication. This document is 26 being collaborated on in Github at: https://github.com/wkumari/draft- 27 wkumari-opsawg-sdi. The most recent version of the document, open 28 issues, etc should all be available here. The authors (gratefully) 29 accept pull requests. ] 31 [ Ed note: This document introduces concepts and serves as the basic 32 for discussion - because of this, it is conversational, and would 33 need to be firmed up before being published ] 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on October 23, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5 72 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 6 73 3.1. Device key generation . . . . . . . . . . . . . . . . . . 6 74 3.2. Certificate Publication Server . . . . . . . . . . . . . 6 75 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 7 76 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 8 79 5. Additional Considerations . . . . . . . . . . . . . . . . . . 11 80 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 11 82 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 11 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 9.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 90 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15 91 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 15 92 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 15 93 B.1.2. Step 1.2: Generate the certificate signing request. . 16 94 B.1.3. Step 1.3: Generate the (self signed) certificate 95 itself. . . . . . . . . . . . . . . . . . . . . . . . 16 96 B.2. Step 2: Generating the encrypted config. . . . . . . . . 16 97 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 16 98 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17 99 B.2.3. Step 2.3: Copy config to the config server. . . . . . 17 100 B.3. Step 3: Decrypting and using the config. . . . . . . . . 17 101 B.3.1. Step 3.1: Fetch encrypted config file from config 102 server. . . . . . . . . . . . . . . . . . . . . . . . 17 103 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 In a growing, global network, significant amounts of time and money 109 are spent deploying new devices and "forklift" upgrading existing 110 devices. In many cases, these devices are in shared datacenters (for 111 example, Internet Exchange Points (IXP) or "carrier neutral 112 datacenters"), which have staff on hand that can be contracted to 113 perform tasks including physical installs, device reboots, loading 114 initial configurations, etc. There are also a number of (often 115 vendor proprietary) protocols to perform initial device installs and 116 configurations - for example, many network devices will attempt to 117 use DHCP [RFC2131]to get an IP address and configuration server, and 118 then fetch and install a configuration when they are first powered 119 on. 121 The configurations of network devices contain a significant amount of 122 security related and/or proprietary information (for example, RADIUS 123 [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing 124 these to a third party to load onto a new device (or using an auto- 125 install techniques which fetch an unencrypted config file via TFTP 126 [RFC1350]) or something similar, is an unacceptable security risk for 127 many operators, and so they send employees to remote locations to 128 perform the initial configuration work; this costs, time and money. 130 There are some workarounds to this, such as asking the vendor to pre- 131 configure the devices before shipping it; asking the smart-hands to 132 install a terminal server; providing a minimal, unsecured 133 configuration and using that to bootstrap to a complete 134 configuration, etc; but these are often clumsy and have security 135 issues - for example, in the terminal server case, the console port 136 connection could be easily snooped. 138 This document layers security onto existing auto-install solutions to 139 provide a secure method to initially configure new devices. It is 140 optimized for simplicity, both for the implementor and the operator; 141 it is explicitly not intended to be an "all singing, all dancing" 142 fully featured system for managing installed / deployed devices, nor 143 is it intended to solve all use-cases - rather it is a simple 144 targeted solution to solve a common operational issue where the 145 network device has been delivered, fibre laid (as appropriate) but 146 there is no trusted member of the operator's staff to perform the 147 initial configuration. 149 Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572], 150 [I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more 151 fully featured, but also more complex to implement and/or are not 152 widely deployed yet. 154 This solution is specifically designed to be a simple method on top 155 of exiting device functionality. If devices do not support this new 156 method, they can continue to use the existing functionality. In 157 addition, operators can choose to use this to protect their 158 configuration information, or can continue to use the existing 159 functionality. 161 The issue of securely installing devices is in no way a new issue, 162 nor is it limited to network devices; it occurs when deploying 163 servers, PCs, IoT devices, and in many other situations. While the 164 solution described in this document is obvious (encrypt the config, 165 then decrypt it with a device key), this document only discusses the 166 use for network devices, such as routers and switches. 168 1.1. Requirements notation 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 2. Overview 178 Most network devices already include some sort of initial 179 bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). 180 This generally works by having a newly installed / unconfigured 181 device obtain an IP address and address of a config server (often 182 called 'next-server', 'siaddr' or 'tftp-server-name') using DHCP (see 183 [RFC2131]). The device then contacts this configuration server to 184 download its initial configuration, which is often identified using 185 the devices serial number, MAC address or similar. This document 186 extends this (vendor specific) paradigm by allowing the configuration 187 file to be encrypted. 189 This document describes a concept, and some example ways of 190 implementing this concept. As devices have different capabilities, 191 and use different configuration paradigms, one method will not suit 192 all, and so it is expected that vendors will differ in exactly how 193 they implement this. 195 This document uses the serial number of the device as a unique device 196 identifier for simplicity; some vendors may not want to implement the 197 system using the serial number as the identifier for business reasons 198 (a competitor or similar could enumerate the serial numbers and 199 determine how many devices have been manufactured). Implementors are 200 free to choose some other way of generating identifiers (e.g., UUID 201 [RFC4122]), but this will likely make it somewhat harder for 202 operators to use (the serial number is usually easy to find on a 203 device, a more complex system is likely harder to track). 205 [ Ed note: This example also uses TFTP because that is what many 206 vendors use in their auto-install / ZTP feature. It could easily 207 instead be HTTP, FTP, etc. ] 209 2.1. Example Scenario 211 Sirius Cybernetics Corp needs another peering router, and so they 212 order another router from Acme Network Widgets, to be drop-shipped to 213 the Point of Presence (POP) / datacenter. Acme begins assembling the 214 new device, and tells Sirius what the new device's serial number will 215 be (SN:17894321). When Acme first installs the firmware on the 216 device and boots it, the device generates a public-private keypair, 217 and Acme publishes the public key on their keyserver (in a public key 218 certificate, for ease of use). 220 While the device is being shipped, Sirius generates the initial 221 device configuration, fetches the certificate from Acme keyservers by 222 providing the serial number of the new device. Sirius then encrypts 223 the device configuration and puts this encrypted config on a (local) 224 TFTP server. 226 When the device arrives at the POP, it gets installed in Sirius' 227 rack, and cabled as instructed. The new device powers up and 228 discovers that it has not yet been configured. It enters its 229 autoboot state, and begins the DHCP process. Sirius' DHCP server 230 provides it with an IP address and the address of the configuration 231 server. The router uses TFTP to fetch its config file (note that all 232 this is existing functionality). The device attempts to load the 233 config file - if the config file is unparsable, (new functionality) 234 the device tries to use its private key to decrypt the file, and, 235 assuming it validates, installs the new configuration. 237 Only the "correct" device will have the required private key and be 238 able to decrypt and use the config file (See Security 239 Considerations). An attacker would be able to connect to the network 240 and get an IP address. They would also be able to retrieve 241 (encrypted) config files by guessing serial numbers (or perhaps the 242 server would allow directory listing), but without the private keys 243 an attacker will not be able to decrypt the files. 245 3. Vendor Role / Requirements 247 This section describes the vendors roles and responsibilities and 248 provides an overview of what the device needs to do. 250 3.1. Device key generation 252 Each devices requires a public-private key keypair, and for the 253 public part to be published and retrievable by the operator. The 254 cryptograthic algorithm and key lenghts to be used are out of the 255 scope of this document. This section illustrates one method, but, as 256 with much of this document the exact mechanism may vary by vendor. 257 EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may 258 want to consider. 260 During the manufacturing stage, when the device is initially powered 261 on, it will generate a public-private keypair. It will send its 262 unique device identifier and the public key to the vendor's 263 Certificate Publication Server to be published. The vendor's 264 Certificate Publication Server should only accept certificates from 265 the manufacturing facility, and which match vendor defined policies 266 (for example, extended key usage, extensions, etc.) Note that some 267 devices may be constrained, and so may send the raw public key and 268 unique device identifier to the certificate publication server, while 269 more capable devices may generate and send self-signed certificates. 271 3.2. Certificate Publication Server 273 The certificate publication server contains a database of 274 certificates. If newly manufactured devices upload certificates the 275 certificate publication server can simply publish these; if the 276 devices provide the raw public keys and unique device identifier, the 277 certificate publication server will need to wrap these in a 278 certificate. 280 The customers (e.g., Sirius Cybernetics Corp) query this server with 281 the serial number (or other provided unique identifier) of a device, 282 and retrieve the associated certificate. It is expected that 283 operators will receive the unique device identifier (serial number) 284 of devices when they purchase them, and will download and store / 285 cache the certificate. This means that there is not a hard 286 requirement on the uptime / reachability of the certificate 287 publication server. 289 +------------+ 290 +------+ |Certificate | 291 |Device| |Publication | 292 +------+ | Server | 293 +------------+ 294 +----------------+ +--------------+ 295 | +---------+ | | | 296 | | Initial | | | | 297 | | boot? | | | | 298 | +----+----+ | | | 299 | | | | | 300 | +------v-----+ | | | 301 | | Generate | | | | 302 | |Self-signed | | | | 303 | |Certificate | | | | 304 | +------------+ | | | 305 | | | | +-------+ | 306 | +-------|---|-->|Receive| | 307 | | | +---+---+ | 308 | | | | | 309 | | | +---v---+ | 310 | | | |Publish| | 311 | | | +-------+ | 312 | | | | 313 +----------------+ +--------------+ 315 Initial certificate generation and publication. 317 4. Operator Role / Responsibilities 319 4.1. Administrative 321 When purchasing a new device, the accounting department will need to 322 get the unique device identifier (likely serial number) of the new 323 device and communicate it to the operations group. 325 4.2. Technical 327 The operator will contact the vendor's publication server, and 328 download the certificate (by providing the unique device identifier 329 of the device). The operator SHOULD fetch the certificate using a 330 secure transport (e.g., HTTPS). The operator will then encrypt the 331 initial configuration (for example, using SMIME [RFC5751]) using the 332 key in the certificate, and place it on their TFTP server. See 333 Appendix B for examples. 335 +------------+ 336 +--------+ |Certificate | 337 |Operator| |Publication | 338 +--------+ | Server | 339 +------------+ 340 +----------------+ +----------------+ 341 | +-----------+ | | +-----------+ | 342 | | Fetch | | | | | | 343 | | Device |<------>|Certificate| | 344 | |Certificate| | | | | | 345 | +-----+-----+ | | +-----------+ | 346 | | | | | 347 | +-----v------+ | | | 348 | | Encrypt | | | | 349 | | Device | | | | 350 | | Config | | | | 351 | +-----+------+ | | | 352 | | | | | 353 | +-----v------+ | | | 354 | | Publish | | | | 355 | | TFTP | | | | 356 | | Server | | | | 357 | +------------+ | | | 358 | | | | 359 +----------------+ +----------------+ 361 Fetching the certificate, encrypting the configuration, publishing 362 the encrypted configuration. 364 4.3. Example Initial Customer Boot 366 When the device is first booted by the customer (and on subsequent 367 boots), if the device does not have a valid configuration, it will 368 use existing auto-install functionality. As an example, it performs 369 DHCP Discovery until it gets a DHCP offer including DHCP option 66 370 (Server-Name) or 150 (TFTP server address), contacts the server 371 listed in these DHCP options and downloads its config file. Note 372 that this is existing functionality (for example, Cisco devices fetch 373 the config file named by the Bootfile-Name DHCP option (67)). 375 After retrieving the config file, the device needs to determine if it 376 is encrypted or not. If it is not encrypted, the existing behavior 377 is used. If the configuration is encrypted, the process continues as 378 described in this document. The method used to determine if the 379 config is encrypted or not is implementation dependant; there are a 380 number of (obvious) options, including having a magic string in the 381 file header, using a file name extension (e.g., config.enc), or using 382 specific DHCP options. 384 If the file is encrypted, the device will attempt to decrypt and 385 parse the file. If able, it will install the configuration, and 386 start using it. If it cannot decrypt the file, or if parsing the 387 configurations fails, the device will either abort the auto-install 388 process, or will repeat this process until it succeeds. 390 Note that the device only needs to be able to download the config 391 file; after the initial power-on in the factory it never needs to 392 access the Internet or vendor or certificate publication server - it 393 (and only it) has the private key and so has the ability to decrypt 394 the config file. 396 +--------+ +--------------+ 397 | Device | |Config server | 398 +--------+ | (e.g. TFTP) | 399 +--------------+ 400 +---------------------------+ +------------------+ 401 | +-----------+ | | | 402 | | | | | | 403 | | DHCP | | | | 404 | | | | | | 405 | +-----+-----+ | | | 406 | | | | | 407 | +-----v------+ | | +-----------+ | 408 | | | | | | Encrypted | | 409 | |Fetch config|<------------------>| config | | 410 | | | | | | file | | 411 | +-----+------+ | | +-----------+ | 412 | | | | | 413 | X | | | 414 | / \ | | | 415 | / \ N +--------+ | | | 416 | | Enc?|---->|Install,| | | | 417 | \ / | Boot | | | | 418 | \ / +--------+ | | | 419 | V | | | 420 | |Y | | | 421 | | | | | 422 | +-----v------+ | | | 423 | |Decrypt with| | | | 424 | |private key | | | | 425 | +-----+------+ | | | 426 | | | | | 427 | v | | | 428 | / \ | | | 429 | / \ Y +--------+ | | | 430 | |Sane?|---->|Install,| | | | 431 | \ / | Boot | | | | 432 | \ / +--------+ | | | 433 | V | | | 434 | |N | | | 435 | | | | | 436 | +----v---+ | | | 437 | |Give up,| | | | 438 | |go home | | | | 439 | +--------+ | | | 440 | | | | 441 +---------------------------+ +------------------+ 443 Device boot, fetch and install config file 445 5. Additional Considerations 447 5.1. Key storage 449 Ideally, the keypair would be stored in a Trusted Platform Module 450 (TPM) on something which is identified as the "router" - for example, 451 the chassis / backplane. This is so that a keypair is bound to what 452 humans think of as the "device", and not, for example (redundant) 453 routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR] 454 could choose to use the IDevID for this purpose. 456 5.2. Key replacement 458 It is anticipated that some operator may want to replace the (vendor 459 provided) keys after installing the device. There are two options 460 when implementing this - a vendor could allow the operator's key to 461 completely replace the initial device generated key (which means 462 that, if the device is ever sold, the new owner couldn't use this 463 technique to install the device), or the device could prefer the 464 operators installed key. This is an implementation decision left to 465 the vendor. 467 5.3. Device reinstall 469 Increasingly, operations is moving towards an automated model of 470 device management, whereby portions (or the entire) configuration is 471 programmatically generated. This means that operators may want to 472 generate an entire configuration after the device has been initially 473 installed and ask the device to load and use this new configuration. 474 It is expected (but not defined in this document, as it is vendor 475 specific) that vendors will allow the operator to copy a new, 476 encrypted config (or part of a config) onto a device and then request 477 that the device decrypt and install it (e.g.: 'load replace 478 encrypted)). The operator could also choose to reset the 479 device to factory defaults, and allow the device to act as though it 480 were the initial boot (see Section 4.3). 482 6. IANA Considerations 484 This document makes no requests of the IANA. 486 7. Security Considerations 488 This mechanism is intended to replace either expensive (traveling 489 employees) or insecure mechanisms of installing newly deployed 490 devices such as: unencrypted config files which can be downloaded by 491 connecting to unprotected ports in datacenters, mailing initial 492 config files on flash drives, or emailing config files and asking a 493 third-party to copy and paste it over a serial terminal. It does not 494 protect against devices with malicious firmware, nor theft and reuse 495 of devices. 497 An attacker (e.g., a malicious datacenter employee) who has physical 498 access to the device before it is connected to the network the 499 attacker may be able to extract the device private key (especially if 500 it is not stored in a TPM), pretend to be the device when connecting 501 to the network, and download and extract the (encrypted) config file. 503 This mechanism does not protect against a malicious vendor - while 504 the keypair should be generated on the device, and the private key 505 should be securely stored, the mechanism cannot detect or protect 506 against a vendor who claims to do this, but instead generates the 507 keypair off device and keeps a copy of the private key. It is 508 largely understood in the operator community that a malicious vendor 509 or attacker with physical access to the device is largely a "Game 510 Over" situation. 512 Even when using a secure bootstrapping mechanism, security conscious 513 operators may wish to bootstrapping devices with a minimal / less 514 sensitive config, and then replace this with a more complete one 515 after install. 517 8. Acknowledgments 519 The authors wish to thank everyone who contributed, including Benoit 520 Claise, Francis Dupont, Sam Ribeiro, Michael Richardson, Sean Turner 521 and Kent Watsen. Joe Clarke also provided significant comments and 522 review, and Tom Petch provided significant editorial contributions to 523 better describe the use cases, and clarify the scope. 525 9. References 527 9.1. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, 531 DOI 10.17487/RFC2119, March 1997, 532 . 534 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 535 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 536 May 2017, . 538 9.2. Informative References 540 [I-D.gutmann-scep] 541 Gutmann, P., "Simple Certificate Enrolment Protocol", 542 draft-gutmann-scep-16 (work in progress), March 2020. 544 [I-D.ietf-anima-bootstrapping-keyinfra] 545 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 546 and K. Watsen, "Bootstrapping Remote Secure Key 547 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 548 keyinfra-41 (work in progress), April 2020. 550 [I-D.ietf-opsawg-tacacs] 551 Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and 552 L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg- 553 tacacs-18 (work in progress), March 2020. 555 [IEEE802-1AR] 556 IEEE, "IEEE Standard for Local and Metropolitan Area 557 Networks - Secure Device Identity", June 2018, 558 . 560 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 561 RFC 1350, DOI 10.17487/RFC1350, July 1992, 562 . 564 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 565 RFC 2131, DOI 10.17487/RFC2131, March 1997, 566 . 568 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 569 "Remote Authentication Dial In User Service (RADIUS)", 570 RFC 2865, DOI 10.17487/RFC2865, June 2000, 571 . 573 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 574 Unique IDentifier (UUID) URN Namespace", RFC 4122, 575 DOI 10.17487/RFC4122, July 2005, 576 . 578 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 579 Mail Extensions (S/MIME) Version 3.2 Message 580 Specification", RFC 5751, DOI 10.17487/RFC5751, January 581 2010, . 583 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 584 "Enrollment over Secure Transport", RFC 7030, 585 DOI 10.17487/RFC7030, October 2013, 586 . 588 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 589 Touch Provisioning (SZTP)", RFC 8572, 590 DOI 10.17487/RFC8572, April 2019, 591 . 593 Appendix A. Changes / Author Notes. 595 [RFC Editor: Please remove this section before publication ] 597 From -03 to -04 599 o Addressed Joe's WGLC comments. This involved changing the "just 600 try decrypt and pray" to vendor specific, like a file extension, 601 magic header sting, etc. 603 o Addressed tom's comments. 605 From individual WG-01 to -03: 607 o Addressed Joe Clarke's comments - 608 https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw- 609 XtWXZIIFhH7aW_-0YY 611 o Many typos / nits 613 o Broke Overview and Example Scenario into 2 sections. 615 o Reordered text for above. 617 From individual -04 to WG-01: 619 o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg- 620 sdi-00 622 From -00 to -01 624 o Nothing changed in the template! 626 From -01 to -03: 628 o See github commit log (AKA, we forgot to update this!) 630 o Added Colin Doyle. 632 From -03 to -04: 634 Addressed a number of comments received before / at IETF104 (Prague). 635 These include: 637 o Pointer to https://datatracker.ietf.org/doc/draft-ietf-netconf- 638 zerotouch -- included reference to (now) RFC8572 (KW) 640 o Suggested that 802.1AR IDevID (or similar) could be used. Stress 641 that this is designed for simplicity (MR) 643 o Added text to explain that any unique device identifier can be 644 used, not just serial number - serial number is simple and easy, 645 but anything which is unique (and can be communicated to the 646 customer) will work (BF). 648 o Lots of clarifications from Joe Clarke. 650 o Make it clear it should first try use the config, and if it 651 doesn't work, then try decrypt and use it. 653 o The CA part was confusing people - the certificate is simply a 654 wrapper for the key, and the Subject just an index, and so removed 655 that. 657 o Added a bunch of ASCII diagrams 659 Appendix B. Demo / proof of concept 661 This section contains a rough demo / proof of concept of the system. 662 It is only intended for illustration, and is not intended to be used 663 in production. 665 It uses OpenSSL from the command line, in production something more 666 automated would be used. In this example, the unique device 667 identifier is the serial number of the router, SN19842256. 669 B.1. Step 1: Generating the certificate. 671 This step is performed by the router. It generates a key, then a 672 csr, and then a self signed certificate. 674 B.1.1. Step 1.1: Generate the private key. 676 $ openssl genrsa -out key.pem 2048 677 Generating RSA private key, 2048 bit long modulus 678 ................................................. 679 ................................................. 680 ..........................+++ 681 ...................+++ 682 e is 65537 (0x10001) 684 B.1.2. Step 1.2: Generate the certificate signing request. 686 $ openssl req -new -key key.pem -out SN19842256.csr 687 Country Name (2 letter code) [AU]:. 688 State or Province Name (full name) [Some-State]:. 689 Locality Name (eg, city) []:. 690 Organization Name (eg, company) [Internet Widgits Pty Ltd]:. 691 Organizational Unit Name (eg, section) []:. 692 Common Name (e.g. server FQDN or YOUR name) []:SN19842256 693 Email Address []:. 695 Please enter the following 'extra' attributes 696 to be sent with your certificate request 697 A challenge password []: 698 An optional company name []:. 700 B.1.3. Step 1.3: Generate the (self signed) certificate itself. 702 $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out 703 SN19842256.crt 705 The router then sends the key to the vendor's keyserver for 706 publication (not shown). 708 B.2. Step 2: Generating the encrypted config. 710 The operator now wants to deploy the new router. 712 They generate the initial config (using whatever magic tool generates 713 router configs!), fetch the router's certificate and encrypt the 714 config file to that key. This is done by the operator. 716 B.2.1. Step 2.1: Fetch the certificate. 718 $ wget http://keyserv.example.net/certificates/SN19842256.crt 720 B.2.2. Step 2.2: Encrypt the config file. 722 I'm using S/MIME because it is simple to demonstrate. This is almost 723 definitely not the best way to do this. 725 $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ 726 -out SN19842256.enc -outform PEM SN19842256.crt 727 $ more SN19842256.enc 728 -----BEGIN PKCS7----- 729 MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV 730 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 731 ... 732 LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt 733 -----END PKCS7----- 735 B.2.3. Step 2.3: Copy config to the config server. 737 $ scp SN19842256.enc config.example.com:/tftpboot 739 B.3. Step 3: Decrypting and using the config. 741 When the router connects to the operator's network it will detect 742 that does not have a valid configuration file, and will start the 743 "autoboot" process. This is a well documented process, but the high 744 level overview is that it will use DHCP to obtain an IP address and 745 config server. It will then use TFTP to download a configuration 746 file, based upon its serial number (this document modifies the 747 solution to fetch an encrypted config file (ending in .enc)). It 748 will then decrypt the config file, and install it. 750 B.3.1. Step 3.1: Fetch encrypted config file from config server. 752 $ tftp 2001:0db8::23 -c get SN19842256.enc 754 B.3.2. Step 3.2: Decrypt and use the config. 756 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 757 -out config.cfg -inkey key.pem 759 If an attacker does not have the correct key, they will not be able 760 to decrypt the config: 762 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 763 -out config.cfg -inkey wrongkey.pem 764 Error decrypting PKCS#7 structure 765 140352450692760:error:06065064:digital envelope 766 routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: 767 $ echo $? 768 4 770 Authors' Addresses 772 Warren Kumari 773 Google 774 1600 Amphitheatre Parkway 775 Mountain View, CA 94043 776 US 778 Email: warren@kumari.net 780 Colin Doyle 781 Juniper Networks 782 1133 Innovation Way 783 Sunnyvale, CA 94089 784 US 786 Email: cdoyle@juniper.net