idnits 2.17.1 draft-ietf-opsawg-sdi-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (June 24, 2020) is 1401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 2 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: December 26, 2020 Juniper Networks 6 June 24, 2020 8 Secure Device Install 9 draft-ietf-opsawg-sdi-13 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 facilities with "remote-hands" type support. In many 17 cases, this could be avoided if there were an easy way to transfer 18 the initial configuration to a new device, while still maintaining 19 confidentiality of the configuration. 21 This document extends existing vendor proprietary auto-install to 22 provide limited confidentiality to initial configuration during 23 bootstrapping of the device. 25 [ Ed note: Text inside square brackets ([]) is additional background 26 information, answers to frequently asked questions, general musings, 27 etc. They will be removed before publication. This document is 28 being collaborated on in Github at: https://github.com/wkumari/draft- 29 wkumari-opsawg-sdi. The most recent version of the document, open 30 issues, etc should all be available here. The authors (gratefully) 31 accept pull requests. ] 33 [ Ed note: This document introduces concepts and serves as the basic 34 for discussion. Because of this, it is conversational, and would 35 need to be firmed up before being published ] 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 26, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5 74 3. Vendor Role . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Device key generation . . . . . . . . . . . . . . . . . . 6 76 3.2. Directory Server . . . . . . . . . . . . . . . . . . . . 7 77 4. Operator Role . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. Example Initial Customer Boot . . . . . . . . . . . . . . 9 81 5. Additional Considerations . . . . . . . . . . . . . . . . . . 12 82 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 12 83 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 88 9. Informative References . . . . . . . . . . . . . . . . . . . 14 89 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 15 90 Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 17 91 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 17 92 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 17 93 B.1.2. Step 1.2: Generate the certificate signing request. . 17 94 B.1.3. Step 1.3: Generate the (self signed) certificate 95 itself. . . . . . . . . . . . . . . . . . . . . . . . 17 96 B.2. Step 2: Generating the encrypted configuration. . . . . . 18 97 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 18 98 B.2.2. Step 2.2: Encrypt the configuration file. . . . . . . 18 99 B.2.3. Step 2.3: Copy configuration to the configuration 100 server. . . . . . . . . . . . . . . . . . . . . . . . 18 101 B.3. Step 3: Decrypting and using the configuration. . . . . . 18 102 B.3.1. Step 3.1: Fetch encrypted configuration file from 103 configuration server. . . . . . . . . . . . . . . . . 19 104 B.3.2. Step 3.2: Decrypt and use the configuration. . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 107 1. Introduction 109 In a growing, global network, significant amounts of time and money 110 are spent deploying new devices and "forklift" upgrading existing 111 devices. In many cases, these devices are in shared facilities (for 112 example, Internet Exchange Points (IXP) or "carrier-neutral 113 datacenters"), which have staff on hand that can be contracted to 114 perform tasks including physical installs, device reboots, loading 115 initial configurations, etc. There are also a number of (often 116 proprietary) protocols to perform initial device installs and 117 configurations. For example, many network devices will attempt to 118 use DHCP [RFC2131] or DHCPv6 [RFC8415] to get an IP address and 119 configuration server, and then fetch and install a configuration when 120 they are first powered on. 122 The configurations of network devices contain a significant amount of 123 security-related and proprietary information (for example, RADIUS 124 [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing 125 these to a third party to load onto a new device (or using an auto- 126 install technique which fetches an unencrypted configuration file via 127 TFTP [RFC1350]) or something similar is an unacceptable security risk 128 for many operators, and so they send employees to remote locations to 129 perform the initial configuration work; this costs time and money. 131 There are some workarounds to this, such as asking the vendor to pre- 132 configure the device before shipping it; asking the remote support to 133 install a terminal server; providing a minimal, unsecured 134 configuration and using that to bootstrap to a complete 135 configuration, etc. However, these are often clumsy and have 136 security issues. As an example, in the terminal server case, the 137 console port connection could be easily snooped. 139 An ideal solution in this space would protect both the 140 confidentiality of device configuration in transit and the 141 authenticity (and authorization status) of configuration to be used 142 by the device. The mechanism described in this document only 143 addresses the former, and makes no effort to do the latter, with the 144 device accepting any configuration file that comes its way and is 145 encrypted to the device's key (or not encrypted, as the case may be). 146 Other solutions (such as "Secure Zero Touch Provisioning (SZTP)" 147 [RFC8572], [I-D.ietf-anima-bootstrapping-keyinfra] and other voucher- 148 based methods) are more fully featured, but also require more 149 complicated machinery. This document describes something much 150 simpler, at the cost of only providing limited protection. 152 This document layers security onto existing auto-install solutions 153 (one example of which is [Cisco_AutoInstall]) to provide a method to 154 initially configure new devices while maintaining (limited) 155 confidentiality of the initial configuration. It is optimized for 156 simplicity, for both the implementor and the operator; it is 157 explicitly not intended to be a fully featured system for managing 158 installed devices, nor is it intended to solve all use cases: rather 159 it is a simple targeted solution to solve a common operational issue 160 where the network device has been delivered, fibre laid (as 161 appropriate) and there is no trusted member of the operator's staff 162 to perform the initial configuration. This solution is only intended 163 to increase confidentiality of the information in the configuration 164 file, and does not protect the device itself from loading a malicious 165 configuration. 167 This document describes a concept, and some example ways of 168 implementing this concept. As devices have different capabilities, 169 and use different configuration paradigms, one method will not suit 170 all, and so it is expected that vendors will differ in exactly how 171 they implement this. 173 This solution is specifically designed to be a simple method on top 174 of exiting device functionality. If devices do not support this new 175 method, they can continue to use the existing functionality. In 176 addition, operators can choose to use this to protect their 177 configuration information, or can continue to use the existing 178 functionality. 180 The issue of securely installing devices is in no way a new issue, 181 nor is it limited to network devices; it occurs when deploying 182 servers, PCs, IoT devices, and in many other situations. While the 183 solution described in this document is obvious (encrypt the config, 184 then decrypt it with a device key), this document only discusses the 185 use for network devices, such as routers and switches. 187 2. Overview 189 Most network devices already include some sort of initial 190 bootstrapping logic (sometimes called 'autoboot', or 'autoinstall'). 191 This generally works by having a newly installed, unconfigured device 192 obtain an IP address for itself and discover the address of a 193 configuration server (often called 'next-server', 'siaddr' or 'tftp- 194 server-name') using DHCP or DHCPv6 (see [RFC2131], [RFC8415]). The 195 device then contacts this configuration server to download its 196 initial configuration, which is often identified using the device's 197 serial number, MAC address or similar. This document extends this 198 (vendor-specific) paradigm by allowing the configuration file to be 199 encrypted. 201 This document uses the serial number of the device as a unique device 202 identifier for simplicity; some vendors may not want to implement the 203 system using the serial number as the identifier for business reasons 204 (a competitor or similar could enumerate the serial numbers and 205 determine how many devices have been manufactured). Implementors are 206 free to choose some other way of generating identifiers (e.g., UUID 207 [RFC4122]), but this will likely make it somewhat harder for 208 operators to use (the serial number is usually easy to find on a 209 device). 211 [ Ed note: This example also uses TFTP because that is what many 212 vendors use in their auto-install feature. It could easily instead 213 be HTTP, FTP, etc. ] 215 2.1. Example Scenario 217 Operator_A needs another peering router, and so they order another 218 router from Vendor_B, to be drop-shipped to the facility. Vendor_B 219 begins assembling the new device, and tells Operator_A what the new 220 device's serial number will be (SN:17894321). When Vendor_B first 221 installs the firmware on the device and boots it, the device 222 generates a public-private key pair, and Vendor_B publishes the 223 public key on their keyserver (in a public key certificate, for ease 224 of use). 226 While the device is being shipped, Operator_A generates the initial 227 device configuration and fetches the certificate from Vendor_B 228 keyservers by providing the serial number of the new device. 229 Operator_A then encrypts the device configuration and puts this 230 encrypted configuration on a (local) TFTP server. 232 When the device arrives at the POP, it gets installed in Operator_A's 233 rack, and cabled as instructed. The new device powers up and 234 discovers that it has not yet been configured. It enters its 235 autoboot state, and begins the DHCP process. Operator_A's DHCP 236 server provides it with an IP address and the address of the 237 configuration server. The router uses TFTP to fetch its 238 configuration file. Note that all of this is existing functionality. 239 The device attempts to load the configuration file. As an added 240 step, if the configuration file cannot be parsed, the device tries to 241 use its private key to decrypt the file and, assuming it validates, 242 proceeds to install the new, decrypted, configuration. 244 Only the "correct" device will have the required private key and be 245 able to decrypt and use the configuration file (See Security 246 Considerations (Section 7)). An attacker would be able to connect to 247 the network and get an IP address. They would also be able to 248 retrieve (encrypted) configuration files by guessing serial numbers 249 (or perhaps the server would allow directory listing), but without 250 the private keys an attacker will not be able to decrypt the files. 252 3. Vendor Role 254 This section describes the vendor's roles and provides an overview of 255 what the device needs to do. 257 3.1. Device key generation 259 Each device requires a public-private key pair, and for the public 260 part to be published and retrievable by the operator. The 261 cryptographic algorithm and key lengths to be used are out of the 262 scope of this document. This section illustrates one method, but, as 263 with much of this document the exact mechanism may vary by vendor. 264 Enrollment over Secure Transport ([RFC7030]) or possibly 265 [I-D.gutmann-scep] are methods which vendors may want to consider. 267 During the manufacturing stage, when the device is initially powered 268 on, it will generate a public-private key pair. It will send its 269 unique device identifier and the public key to the vendor's directory 270 server ([RFC5280]) to be published. The vendor's directory server 271 should only accept certificates from the manufacturing facility, and 272 which match vendor defined policies (for example, extended key usage, 273 and extensions) Note that some devices may be constrained, and so may 274 send the raw public key and unique device identifier to the 275 certificate publication server, while more capable devices may 276 generate and send self-signed certificates. This communication with 277 the directory server should be integrity protected, and in a 278 controlled environment. 280 This reference architecture needs a serialization format for the key 281 material. Due to the prevalence of tooling support for it on network 282 devices, X.509 certificates are a convenient format to exchange 283 public keys. However, most of the meta-data that would use for 284 revocation and aging will not be used and should be ignored by both 285 the client and server. In such cases the signature on the 286 certificate conveys no value and the consumer of the certificate is 287 expected to pin the end-entity key fingerprint (versus using a PKI 288 and signature chain). 290 3.2. Directory Server 292 The directory server contains a database of certificates. If newly 293 manufactured devices upload certificates the directory server can 294 simply publish these; if the devices provide the raw public keys and 295 unique device identifier, the directory server will need to wrap 296 these in a certificate. 298 The customers (e.g., Operator_A) query this server with the serial 299 number (or other provided unique identifier) of a device, and 300 retrieve the associated certificate. It is expected that operators 301 will receive the unique device identifier (serial number) of devices 302 when they purchase them, and will download and store the certificate. 303 This means that there is not a hard requirement on the reachability 304 of the directory server. 306 +------------+ 307 +------+ | | 308 |Device| | Directory | 309 +------+ | Server | 310 +------------+ 311 +----------------+ +--------------+ 312 | +---------+ | | | 313 | | Initial | | | | 314 | | boot? | | | | 315 | +----+----+ | | | 316 | | | | | 317 | +------v-----+ | | | 318 | | Generate | | | | 319 | |Self-signed | | | | 320 | |Certificate | | | | 321 | +------------+ | | | 322 | | | | +-------+ | 323 | +-------|---|-->|Receive| | 324 | | | +---+---+ | 325 | | | | | 326 | | | +---v---+ | 327 | | | |Publish| | 328 | | | +-------+ | 329 | | | | 330 +----------------+ +--------------+ 332 Initial certificate generation and publication. 334 4. Operator Role 336 4.1. Administrative 338 When purchasing a new device, the accounting department will need to 339 get the unique device identifier (e.g., serial number) of the new 340 device and communicate it to the operations group. 342 4.2. Technical 344 The operator will contact the vendor's publication server, and 345 download the certificate (by providing the unique device identifier 346 of the device). The operator fetches the certificate using a secure 347 transport that authenticates the source of the certificate, such as 348 HTTPS (confidentiality protection can provide some privacy and 349 metadata-leakage benefit, but is not key to the primary mechanism of 350 this document). The operator will then encrypt the initial 351 configuration (for example, using SMIME [RFC5751]) using the key in 352 the certificate, and place it on their configuration server. 354 See Appendix B for examples. 356 +------------+ 357 +--------+ | | 358 |Operator| | Directory | 359 +--------+ | Server | 360 +------------+ 361 +----------------+ +----------------+ 362 | +-----------+ | | +-----------+ | 363 | | Fetch | | | | | | 364 | | Device |<------>|Certificate| | 365 | |Certificate| | | | | | 366 | +-----+-----+ | | +-----------+ | 367 | | | | | 368 | +-----v------+ | | | 369 | | Encrypt | | | | 370 | | Device | | | | 371 | | Config | | | | 372 | +-----+------+ | | | 373 | | | | | 374 | +-----v------+ | | | 375 | | Publish | | | | 376 | | TFTP | | | | 377 | | Server | | | | 378 | +------------+ | | | 379 | | | | 380 +----------------+ +----------------+ 382 Fetching the certificate, encrypting the configuration, publishing 383 the encrypted configuration. 385 4.3. Example Initial Customer Boot 387 When the device is first booted by the customer (and on subsequent 388 boots), if the device does not have a valid configuration, it will 389 use existing auto-install functionality. As an example, it performs 390 DHCP Discovery until it gets a DHCP offer including DHCP option 66 391 (Server-Name) or 150 (TFTP server address), contacts the server 392 listed in these DHCP options and downloads its configuration file. 393 Note that this is existing functionality (for example, Cisco devices 394 fetch the config file named by the Bootfile-Name DHCP option (67)). 396 After retrieving the configuration file, the device needs to 397 determine if it is encrypted or not. If it is not encrypted, the 398 existing behavior is used. If the configuration is encrypted, the 399 process continues as described in this document. If the device has 400 been configured to only support encrypted configuration and 401 determines that the configuration file is not encrypted, it should 402 abort. The method used to determine if the configuration is 403 encrypted or not is implementation dependent; there are a number of 404 (obvious) options, including having a magic string in the file 405 header, using a file name extension (e.g., config.enc), or using 406 specific DHCP options. 408 If the file is encrypted, the device will attempt to decrypt and 409 parse the file. If able, it will install the configuration, and 410 start using it. If it cannot decrypt the file, or if parsing the 411 configuration fails, the device will either abort the auto-install 412 process, or repeat this process until it succeeds. When retrying, 413 care should be taken to not overwhelm the server hosting the 414 encrypted configuration files. It is suggested that the device retry 415 every 5 minutes for the first hour, and then every hour after that. 416 As it is expected that devices may be installed well before the 417 configuration file is ready, a maximum number of retries is not 418 specified. 420 Note that the device only needs to be able to download the 421 configuration file; after the initial power-on in the factory it 422 never needs to access the Internet or vendor or directory server. 423 The device (and only the device) has the private key and so has the 424 ability to decrypt the configuration file. 426 +--------+ +--------------+ 427 | Device | |Config server | 428 +--------+ | (e.g. TFTP) | 429 +--------------+ 430 +---------------------------+ +------------------+ 431 | +-----------+ | | | 432 | | | | | | 433 | | DHCP | | | | 434 | | | | | | 435 | +-----+-----+ | | | 436 | | | | | 437 | +-----v------+ | | +-----------+ | 438 | | | | | | Encrypted | | 439 | |Fetch config|<------------------>| config | | 440 | | | | | | file | | 441 | +-----+------+ | | +-----------+ | 442 | | | | | 443 | X | | | 444 | / \ | | | 445 | / \ N +--------+ | | | 446 | | Enc?|---->|Install,| | | | 447 | \ / | Boot | | | | 448 | \ / +--------+ | | | 449 | V | | | 450 | |Y | | | 451 | | | | | 452 | +-----v------+ | | | 453 | |Decrypt with| | | | 454 | |private key | | | | 455 | +-----+------+ | | | 456 | | | | | 457 | v | | | 458 | / \ | | | 459 | / \ Y +--------+ | | | 460 | |Sane?|---->|Install,| | | | 461 | \ / | Boot | | | | 462 | \ / +--------+ | | | 463 | V | | | 464 | |N | | | 465 | | | | | 466 | +----v---+ | | | 467 | |Retry or| | | | 468 | | abort | | | | 469 | +--------+ | | | 470 | | | | 471 +---------------------------+ +------------------+ 473 Device boot, fetch and install configuration file 475 5. Additional Considerations 477 5.1. Key storage 479 Ideally, the key pair would be stored in a Trusted Platform Module 480 (TPM) on something which is identified as the "router" - for example, 481 the chassis / backplane. This is so that a key pair is bound to what 482 humans think of as the "device", and not, for example (redundant) 483 routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR] 484 could choose to use the IDevID for this purpose. 486 5.2. Key replacement 488 It is anticipated that some operator may want to replace the (vendor 489 provided) keys after installing the device. There are two options 490 when implementing this: a vendor could allow the operator's key to 491 completely replace the initial device-generated key (which means 492 that, if the device is ever sold, the new owner couldn't use this 493 technique to install the device), or the device could prefer the 494 operator's installed key. This is an implementation decision left to 495 the vendor. 497 5.3. Device reinstall 499 Increasingly, operations is moving towards an automated model of 500 device management, whereby portions of (or the entire) configuration 501 is programmatically generated. This means that operators may want to 502 generate an entire configuration after the device has been initially 503 installed and ask the device to load and use this new configuration. 504 It is expected (but not defined in this document, as it is vendor 505 specific) that vendors will allow the operator to copy a new, 506 encrypted configuration (or part of a configuration) onto a device 507 and then request that the device decrypt and install it (e.g.: 'load 508 replace encrypted). The operator could also choose to 509 reset the device to factory defaults, and allow the device to act as 510 though it were the initial boot (see Section 4.3). 512 6. IANA Considerations 514 This document makes no requests of the IANA. 516 7. Security Considerations 518 This reference architecture is intended to incrementally improve upon 519 commonly accepted "auto-install" practices used today that may 520 transmit configurations unencrypted (e.g., unencrypted configuration 521 files which can be downloaded connecting to unprotected ports in 522 datacenters, mailing initial configuration files on flash drives, or 523 emailing configuration files and asking a third-party to copy and 524 paste them over a serial terminal) or allow unrestricted access to 525 these configurations. 527 > This document describes an object level security design to provide 528 confidentiality assurances for the configuration stored at rest on 529 the configuration server; and for configuration while it is in 530 transit between the configuration server and the unprovisioned device 531 even if the underly transport does not provide this security service. 533 The architecture provides no assurances about the source of the 534 encrypted configuration or protect against theft and reuse of 535 devices. 537 An attacker (e.g., a malicious datacenter employee, person in the 538 supply chain, etc.) who has physical access to the device before it 539 is connected to the network, or who manages to exploit it once 540 installed, may be able to extract the device private key (especially 541 if it is not stored in a TPM), pretend to be the device when 542 connecting to the network, and download and extract the (encrypted) 543 configuration file. 545 An attacker with access to the configuration server (or the ability 546 to route traffic to configuration server under their control) and the 547 device's public key could return a configuration of the attacker's 548 choosing to the unprovisioned device. 550 This mechanism does not protect against a malicious vendor. While 551 the key pair should be generated on the device, and the private key 552 should be securely stored, the mechanism cannot detect or protect 553 against a vendor who claims to do this, but instead generates the key 554 pair off device and keeps a copy of the private key. It is largely 555 understood in the operator community that a malicious vendor or 556 attacker with physical access to the device is largely a "Game Over" 557 situation. 559 Even when using a secure bootstrap mechanism, security-conscious 560 operators may wish to bootstrap devices with a minimal or less- 561 sensitive configuration, and then replace this with a more complete 562 one after install. 564 8. Acknowledgments 566 The authors wish to thank everyone who contributed, including Benoit 567 Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael 568 Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided 569 significant comments and review, and Tom Petch provided significant 570 editorial contributions to better describe the use cases, and clarify 571 the scope. 573 Roman Danyliw and Benjamin Kaduk also provided helpful text, 574 especially around the certificate usage and security considerations. 576 9. Informative References 578 [Cisco_AutoInstall] 579 Cisco Systems, Inc., "Using AutoInstall to Remotely 580 Configure Cisco Networking Devices", Jan 2018, 581 . 585 [I-D.gutmann-scep] 586 Gutmann, P., "Simple Certificate Enrolment Protocol", 587 draft-gutmann-scep-16 (work in progress), March 2020. 589 [I-D.ietf-anima-bootstrapping-keyinfra] 590 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 591 and K. Watsen, "Bootstrapping Remote Secure Key 592 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 593 keyinfra-41 (work in progress), April 2020. 595 [I-D.ietf-opsawg-tacacs] 596 Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and 597 L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg- 598 tacacs-18 (work in progress), March 2020. 600 [IEEE802-1AR] 601 IEEE, "IEEE Standard for Local and Metropolitan Area 602 Networks - Secure Device Identity", June 2018, 603 . 605 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 606 RFC 1350, DOI 10.17487/RFC1350, July 1992, 607 . 609 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 610 RFC 2131, DOI 10.17487/RFC2131, March 1997, 611 . 613 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 614 "Remote Authentication Dial In User Service (RADIUS)", 615 RFC 2865, DOI 10.17487/RFC2865, June 2000, 616 . 618 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 619 Unique IDentifier (UUID) URN Namespace", RFC 4122, 620 DOI 10.17487/RFC4122, July 2005, 621 . 623 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 624 Housley, R., and W. Polk, "Internet X.509 Public Key 625 Infrastructure Certificate and Certificate Revocation List 626 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 627 . 629 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 630 Mail Extensions (S/MIME) Version 3.2 Message 631 Specification", RFC 5751, DOI 10.17487/RFC5751, January 632 2010, . 634 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 635 "Enrollment over Secure Transport", RFC 7030, 636 DOI 10.17487/RFC7030, October 2013, 637 . 639 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 640 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 641 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 642 RFC 8415, DOI 10.17487/RFC8415, November 2018, 643 . 645 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 646 Touch Provisioning (SZTP)", RFC 8572, 647 DOI 10.17487/RFC8572, April 2019, 648 . 650 Appendix A. Changes / Author Notes. 652 [RFC Editor: Please remove this section before publication ] 654 From -09 to -10 656 o Typos - "lenghts" => "lengths", missed a reference to Acme. 658 From -08 to -09 660 o Addressed Mirja's IETF LC comments. 662 From -04 to -08 664 o Please see GitHub commit log (I forgot to put them in here :-P ) 665 From -03 to -04 667 o Addressed Joe's WGLC comments. This involved changing the "just 668 try decrypt and pray" to vendor specific, like a file extension, 669 magic header sting, etc. 671 o Addressed tom's comments. 673 From individual WG-01 to -03: 675 o Addressed Joe Clarke's comments - 676 https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw- 677 XtWXZIIFhH7aW_-0YY 679 o Many typos / nits 681 o Broke Overview and Example Scenario into 2 sections. 683 o Reordered text for above. 685 From individual -04 to WG-01: 687 o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg- 688 sdi-00 690 From -00 to -01 692 o Nothing changed in the template! 694 From -01 to -03: 696 o See github commit log (AKA, we forgot to update this!) 698 o Added Colin Doyle. 700 From -03 to -04: 702 Addressed a number of comments received before / at IETF104 (Prague). 703 These include: 705 o Pointer to https://datatracker.ietf.org/doc/draft-ietf-netconf- 706 zerotouch -- included reference to (now) RFC8572 (KW) 708 o Suggested that 802.1AR IDevID (or similar) could be used. Stress 709 that this is designed for simplicity (MR) 711 o Added text to explain that any unique device identifier can be 712 used, not just serial number - serial number is simple and easy, 713 but anything which is unique (and can be communicated to the 714 customer) will work (BF). 716 o Lots of clarifications from Joe Clarke. 718 o Make it clear it should first try use the config, and if it 719 doesn't work, then try decrypt and use it. 721 o The CA part was confusing people - the certificate is simply a 722 wrapper for the key, and the Subject just an index, and so removed 723 that. 725 o Added a bunch of ASCII diagrams 727 Appendix B. Proof of Concept 729 This section contains a proof of concept of the system. It is only 730 intended for illustration, and is not intended to be used in 731 production. 733 It uses OpenSSL from the command line. In production something more 734 automated would be used. In this example, the unique device 735 identifier is the serial number of the router, SN19842256. 737 B.1. Step 1: Generating the certificate. 739 This step is performed by the router. It generates a key, then a 740 Certificate Signing Request (CSR), and then a self signed 741 certificate. 743 B.1.1. Step 1.1: Generate the private key. 745 $ openssl ecparam -out privatekey.key -name prime256v1 -genkey 746 $ 748 B.1.2. Step 1.2: Generate the certificate signing request. 750 $ openssl req -new -key key.pem -out SN19842256.csr 751 Common Name (e.g. server FQDN or YOUR name) []:SN19842256 753 B.1.3. Step 1.3: Generate the (self signed) certificate itself. 755 $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out 756 SN19842256.crt 757 The router then sends the key to the vendor's keyserver for 758 publication (not shown). 760 B.2. Step 2: Generating the encrypted configuration. 762 The operator now wants to deploy the new router. 764 They generate the initial configuration (using whatever magic tool 765 generates router configs!), fetch the router's certificate and 766 encrypt the configuration file to that key. This is done by the 767 operator. 769 B.2.1. Step 2.1: Fetch the certificate. 771 $ wget http://keyserv.example.net/certificates/SN19842256.crt 773 B.2.2. Step 2.2: Encrypt the configuration file. 775 S/MIME is used here because it is simple to demonstrate. This is 776 almost definitely not the best way to do this. 778 $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ 779 -out SN19842256.enc -outform PEM SN19842256.crt 780 $ more SN19842256.enc 781 -----BEGIN PKCS7----- 782 MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV 783 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 784 ... 785 LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt 786 -----END PKCS7----- 788 B.2.3. Step 2.3: Copy configuration to the configuration server. 790 $ scp SN19842256.enc config.example.com:/tftpboot 792 B.3. Step 3: Decrypting and using the configuration. 794 When the router connects to the operator's network it will detect 795 that does not have a valid configuration file, and will start the 796 "autoboot" process. This is a well documented process, but the high 797 level overview is that it will use DHCP to obtain an IP address and 798 configuration server. It will then use TFTP to download a 799 configuration file, based upon its serial number (this document 800 modifies the solution to fetch an encrypted configuration file 801 (ending in .enc)). It will then decrypt the configuration file, and 802 install it. 804 B.3.1. Step 3.1: Fetch encrypted configuration file from configuration 805 server. 807 $ tftp 2001:0db8::23 -c get SN19842256.enc 809 B.3.2. Step 3.2: Decrypt and use the configuration. 811 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 812 -out config.cfg -inkey key.pem 814 If an attacker does not have the correct key, they will not be able 815 to decrypt the configuration file: 817 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 818 -out config.cfg -inkey wrongkey.pem 819 Error decrypting PKCS#7 structure 820 140352450692760:error:06065064:digital envelope 821 routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: 822 $ echo $? 823 4 825 Authors' Addresses 827 Warren Kumari 828 Google 829 1600 Amphitheatre Parkway 830 Mountain View, CA 94043 831 US 833 Email: warren@kumari.net 835 Colin Doyle 836 Juniper Networks 837 1133 Innovation Way 838 Sunnyvale, CA 94089 839 US 841 Email: cdoyle@juniper.net