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