idnits 2.17.1 draft-ietf-opsawg-sdi-11.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 (May 20, 2020) is 1436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AU' is mentioned on line 722, but not defined == Missing Reference: 'Some-State' is mentioned on line 723, but not defined == 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 (~~), 4 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: November 21, 2020 Juniper Networks 6 May 20, 2020 8 Secure Device Install 9 draft-ietf-opsawg-sdi-11 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 a secure way to initially 18 provision the device. 20 This document extends existing vendor proprietary auto-install to 21 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 November 21, 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 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Example Scenario . . . . . . . . . . . . . . . . . . . . 5 71 3. Vendor Role . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Device key generation . . . . . . . . . . . . . . . . . . 6 73 3.2. Certificate Publication Server . . . . . . . . . . . . . 6 74 4. Operator Role . . . . . . . . . . . . . . . . . . . . . . . . 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. Informative References . . . . . . . . . . . . . . . . . . . 13 86 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 87 Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 16 88 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16 89 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16 90 B.1.2. Step 1.2: Generate the certificate signing request. . 16 91 B.1.3. Step 1.3: Generate the (self signed) certificate 92 itself. . . . . . . . . . . . . . . . . . . . . . . . 17 93 B.2. Step 2: Generating the encrypted configuration. . . . . . 17 94 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17 95 B.2.2. Step 2.2: Encrypt the configuration file. . . . . . . 17 96 B.2.3. Step 2.3: Copy configuration to the configuration 97 server. . . . . . . . . . . . . . . . . . . . . . . . 17 98 B.3. Step 3: Decrypting and using the configuration. . . . . . 17 99 B.3.1. Step 3.1: Fetch encrypted configuration file from 100 configuration server. . . . . . . . . . . . . . . . . 18 101 B.3.2. Step 3.2: Decrypt and use the configuration. . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 104 1. Introduction 106 In a growing, global network, significant amounts of time and money 107 are spent deploying new devices and "forklift" upgrading existing 108 devices. In many cases, these devices are in shared facilities (for 109 example, Internet Exchange Points (IXP) or "carrier-neutral 110 datacenters"), which have staff on hand that can be contracted to 111 perform tasks including physical installs, device reboots, loading 112 initial configurations, etc. There are also a number of (often 113 proprietary) protocols to perform initial device installs and 114 configurations. For example, many network devices will attempt to 115 use DHCP [RFC2131] to get an IP address and configuration server, and 116 then fetch and install a configuration when they are first powered 117 on. 119 The configurations of network devices contain a significant amount of 120 security-related and proprietary information (for example, RADIUS 121 [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). Exposing 122 these to a third party to load onto a new device (or using an auto- 123 install technique which fetches an unencrypted configuration file via 124 TFTP [RFC1350]) or something similar is an unacceptable security risk 125 for many operators, and so they send employees to remote locations to 126 perform the initial configuration work; this costs time and money. 128 There are some workarounds to this, such as asking the vendor to pre- 129 configure the device before shipping it; asking the remote support to 130 install a terminal server; providing a minimal, unsecured 131 configuration and using that to bootstrap to a complete 132 configuration, etc. However, these are often clumsy and have 133 security issues. As an example, in the terminal server case, the 134 console port connection could be easily snooped. 136 This document layers security onto existing auto-install solutions 137 (one example of which is [Cisco_AutoInstall]) to provide a secure 138 method to initially configure new devices. It is optimized for 139 simplicity, for both the implementor and the operator; it is 140 explicitly not intended to be a fully featured system for managing 141 installed devices, nor is it intended to solve all use cases: rather 142 it is a simple targeted solution to solve a common operational issue 143 where the network device has been delivered, fibre laid (as 144 appropriate) but there is no trusted member of the operator's staff 145 to perform the initial configuration. This solution is only intended 146 to increase confidentiality of the information in the configuration 147 file, not to protect the device itself. 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 are not widely 152 deployed yet. In addition, work in the IETF "Software Updates for 153 Internet of Things (suit)" WG is expected to provide mechanisms for 154 firmware updates, and are out of scope for this document. 156 This document describes a concept, and some example ways of 157 implementing this concept. As devices have different capabilities, 158 and use different configuration paradigms, one method will not suit 159 all, and so it is expected that vendors will differ in exactly how 160 they implement this. 162 This solution is specifically designed to be a simple method on top 163 of exiting device functionality. If devices do not support this new 164 method, they can continue to use the existing functionality. In 165 addition, operators can choose to use this to protect their 166 configuration information, or can continue to use the existing 167 functionality. 169 The issue of securely installing devices is in no way a new issue, 170 nor is it limited to network devices; it occurs when deploying 171 servers, PCs, IoT devices, and in many other situations. While the 172 solution described in this document is obvious (encrypt the config, 173 then decrypt it with a device key), this document only discusses the 174 use for network devices, such as routers and switches. 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 device 181 obtain an IP address for itself and discover the address of a 182 configuration server (often called 'next-server', 'siaddr' or 'tftp- 183 server-name') using DHCP (see [RFC2131]). The device then contacts 184 this configuration server to download its initial configuration, 185 which is often identified using the device's serial number, MAC 186 address or similar. This document extends this (vendor-specific) 187 paradigm by allowing the configuration file to be encrypted. 189 This document uses the serial number of the device as a unique device 190 identifier for simplicity; some vendors may not want to implement the 191 system using the serial number as the identifier for business reasons 192 (a competitor or similar could enumerate the serial numbers and 193 determine how many devices have been manufactured). Implementors are 194 free to choose some other way of generating identifiers (e.g., UUID 195 [RFC4122]), but this will likely make it somewhat harder for 196 operators to use (the serial number is usually easy to find on a 197 device, a more complex system is likely harder to track). 199 [ Ed note: This example also uses TFTP because that is what many 200 vendors use in their auto-install feature. It could easily instead 201 be HTTP, FTP, etc. ] 203 2.1. Example Scenario 205 Operator_A needs another peering router, and so they order another 206 router from Vendor_B, to be drop-shipped to the facility. Vendor_B 207 begins assembling the new device, and tells Operator_A what the new 208 device's serial number will be (SN:17894321). When Vendor_B first 209 installs the firmware on the device and boots it, the device 210 generates a public-private key pair, and Vendor_B publishes the 211 public key on their keyserver (in a public key certificate, for ease 212 of use). 214 While the device is being shipped, Operator_A generates the initial 215 device configuration and fetches the certificate from Vendor_B 216 keyservers by providing the serial number of the new device. 217 Operator_A then encrypts the device configuration and puts this 218 encrypted configuration on a (local) TFTP server. 220 When the device arrives at the POP, it gets installed in Operator_A's 221 rack, and cabled as instructed. The new device powers up and 222 discovers that it has not yet been configured. It enters its 223 autoboot state, and begins the DHCP process. Operator_A's DHCP 224 server provides it with an IP address and the address of the 225 configuration server. The router uses TFTP to fetch its 226 configuration file. Note that all of this is existing functionality. 227 The device attempts to load the configuration file. As an added 228 step, if the configuration file cannot be parsed, the device tries to 229 use its private key to decrypt the file and, assuming it validates, 230 proceeds to install the new, decrypted, configuration. 232 Only the "correct" device will have the required private key and be 233 able to decrypt and use the configuration file (See Security 234 Considerations (Section 7)). An attacker would be able to connect to 235 the network and get an IP address. They would also be able to 236 retrieve (encrypted) configuration files by guessing serial numbers 237 (or perhaps the server would allow directory listing), but without 238 the private keys an attacker will not be able to decrypt the files. 240 3. Vendor Role 242 This section describes the vendor's roles and provides an overview of 243 what the device needs to do. 245 3.1. Device key generation 247 Each device requires a public-private key pair, and for the public 248 part to be published and retrievable by the operator. The 249 cryptographic algorithm and key lengths to be used are out of the 250 scope of this document. This section illustrates one method, but, as 251 with much of this document the exact mechanism may vary by vendor. 252 Enrollment over Secure Transport ([RFC7030]) and [I-D.gutmann-scep] 253 are methods which vendors may want to consider. 255 During the manufacturing stage, when the device is initially powered 256 on, it will generate a public-private key pair. It will send its 257 unique device identifier and the public key to the vendor's 258 Certificate Publication Server to be published. The vendor's 259 Certificate Publication Server should only accept certificates from 260 the manufacturing facility, and which match vendor defined policies 261 (for example, extended key usage, and extensions) Note that some 262 devices may be constrained, and so may send the raw public key and 263 unique device identifier to the certificate publication server, while 264 more capable devices may generate and send self-signed certificates. 266 This reference architecture needs a serialization format for the key 267 material. Due to the prevalence of tooling support for it on network 268 devices, X.509 certificates are a convenient format to exchange 269 public keys. However, most of the meta-data that would use for 270 revocation and aging will not be used and should be ignored by both 271 the client and server. 273 3.2. Certificate Publication Server 275 The certificate publication server contains a database of 276 certificates. If newly manufactured devices upload certificates the 277 certificate publication server can simply publish these; if the 278 devices provide the raw public keys and unique device identifier, the 279 certificate publication server will need to wrap these in a 280 certificate. 282 The customers (e.g., Operator_A) query this server with the serial 283 number (or other provided unique identifier) of a device, and 284 retrieve the associated certificate. It is expected that operators 285 will receive the unique device identifier (serial number) of devices 286 when they purchase them, and will download and store the certificate. 288 This means that there is not a hard requirement on the reachability 289 of the certificate publication server. 291 +------------+ 292 +------+ |Certificate | 293 |Device| |Publication | 294 +------+ | Server | 295 +------------+ 296 +----------------+ +--------------+ 297 | +---------+ | | | 298 | | Initial | | | | 299 | | boot? | | | | 300 | +----+----+ | | | 301 | | | | | 302 | +------v-----+ | | | 303 | | Generate | | | | 304 | |Self-signed | | | | 305 | |Certificate | | | | 306 | +------------+ | | | 307 | | | | +-------+ | 308 | +-------|---|-->|Receive| | 309 | | | +---+---+ | 310 | | | | | 311 | | | +---v---+ | 312 | | | |Publish| | 313 | | | +-------+ | 314 | | | | 315 +----------------+ +--------------+ 317 Initial certificate generation and publication. 319 4. Operator Role 321 4.1. Administrative 323 When purchasing a new device, the accounting department will need to 324 get the unique device identifier (e.g., serial number) of the new 325 device and communicate it to the operations group. 327 4.2. Technical 329 The operator will contact the vendor's publication server, and 330 download the certificate (by providing the unique device identifier 331 of the device). The operator fetches the certificate using a secure 332 transport (e.g., HTTPS). The operator will then encrypt the initial 333 configuration (for example, using SMIME [RFC5751]) using the key in 334 the certificate, and place it on their configuration server. 336 See Appendix B for examples. 338 +------------+ 339 +--------+ |Certificate | 340 |Operator| |Publication | 341 +--------+ | Server | 342 +------------+ 343 +----------------+ +----------------+ 344 | +-----------+ | | +-----------+ | 345 | | Fetch | | | | | | 346 | | Device |<------>|Certificate| | 347 | |Certificate| | | | | | 348 | +-----+-----+ | | +-----------+ | 349 | | | | | 350 | +-----v------+ | | | 351 | | Encrypt | | | | 352 | | Device | | | | 353 | | Config | | | | 354 | +-----+------+ | | | 355 | | | | | 356 | +-----v------+ | | | 357 | | Publish | | | | 358 | | TFTP | | | | 359 | | Server | | | | 360 | +------------+ | | | 361 | | | | 362 +----------------+ +----------------+ 364 Fetching the certificate, encrypting the configuration, publishing 365 the encrypted configuration. 367 4.3. Example Initial Customer Boot 369 When the device is first booted by the customer (and on subsequent 370 boots), if the device does not have a valid configuration, it will 371 use existing auto-install functionality. As an example, it performs 372 DHCP Discovery until it gets a DHCP offer including DHCP option 66 373 (Server-Name) or 150 (TFTP server address), contacts the server 374 listed in these DHCP options and downloads its configuration file. 375 Note that this is existing functionality (for example, Cisco devices 376 fetch the config file named by the Bootfile-Name DHCP option (67)). 378 After retrieving the configuration file, the device needs to 379 determine if it is encrypted or not. If it is not encrypted, the 380 existing behavior is used. If the configuration is encrypted, the 381 process continues as described in this document. The method used to 382 determine if the configuration is encrypted or not is implementation 383 dependent; there are a number of (obvious) options, including having 384 a magic string in the file header, using a file name extension (e.g., 385 config.enc), or using specific DHCP options. 387 If the file is encrypted, the device will attempt to decrypt and 388 parse the file. If able, it will install the configuration, and 389 start using it. If it cannot decrypt the file, or if parsing the 390 configuration fails, the device will either abort the auto-install 391 process, or repeat this process until it succeeds. When retrying, 392 care should be taken to not overwhelm the server hosting the 393 encrypted configuration files. It is suggested that the device retry 394 every 5 minutes for the first hour, and then every hour after that. 395 As it is expected that devices may be installed well before the 396 configuration file is ready, a maximum number of retries is not 397 specified. 399 Note that the device only needs to be able to download the 400 configuration file; after the initial power-on in the factory it 401 never needs to access the Internet or vendor or certificate 402 publication server. The device (and only the device) has the private 403 key and so has the ability to decrypt the configuration file. 405 +--------+ +--------------+ 406 | Device | |Config server | 407 +--------+ | (e.g. TFTP) | 408 +--------------+ 409 +---------------------------+ +------------------+ 410 | +-----------+ | | | 411 | | | | | | 412 | | DHCP | | | | 413 | | | | | | 414 | +-----+-----+ | | | 415 | | | | | 416 | +-----v------+ | | +-----------+ | 417 | | | | | | Encrypted | | 418 | |Fetch config|<------------------>| config | | 419 | | | | | | file | | 420 | +-----+------+ | | +-----------+ | 421 | | | | | 422 | X | | | 423 | / \ | | | 424 | / \ N +--------+ | | | 425 | | Enc?|---->|Install,| | | | 426 | \ / | Boot | | | | 427 | \ / +--------+ | | | 428 | V | | | 429 | |Y | | | 430 | | | | | 431 | +-----v------+ | | | 432 | |Decrypt with| | | | 433 | |private key | | | | 434 | +-----+------+ | | | 435 | | | | | 436 | v | | | 437 | / \ | | | 438 | / \ Y +--------+ | | | 439 | |Sane?|---->|Install,| | | | 440 | \ / | Boot | | | | 441 | \ / +--------+ | | | 442 | V | | | 443 | |N | | | 444 | | | | | 445 | +----v---+ | | | 446 | |Retry or| | | | 447 | | abort | | | | 448 | +--------+ | | | 449 | | | | 450 +---------------------------+ +------------------+ 452 Device boot, fetch and install configuration file 454 5. Additional Considerations 456 5.1. Key storage 458 Ideally, the key pair would be stored in a Trusted Platform Module 459 (TPM) on something which is identified as the "router" - for example, 460 the chassis / backplane. This is so that a key pair is bound to what 461 humans think of as the "device", and not, for example (redundant) 462 routing engines. Devices which implement IEEE 802.1AR [IEEE802-1AR] 463 could choose to use the IDevID for this purpose. 465 5.2. Key replacement 467 It is anticipated that some operator may want to replace the (vendor 468 provided) keys after installing the device. There are two options 469 when implementing this: a vendor could allow the operator's key to 470 completely replace the initial device-generated key (which means 471 that, if the device is ever sold, the new owner couldn't use this 472 technique to install the device), or the device could prefer the 473 operator's installed key. This is an implementation decision left to 474 the vendor. 476 5.3. Device reinstall 478 Increasingly, operations is moving towards an automated model of 479 device management, whereby portions of (or the entire) configuration 480 is programmatically generated. This means that operators may want to 481 generate an entire configuration after the device has been initially 482 installed and ask the device to load and use this new configuration. 483 It is expected (but not defined in this document, as it is vendor 484 specific) that vendors will allow the operator to copy a new, 485 encrypted configuration (or part of a configuration) onto a device 486 and then request that the device decrypt and install it (e.g.: 'load 487 replace encrypted). The operator could also choose to 488 reset the device to factory defaults, and allow the device to act as 489 though it were the initial boot (see Section 4.3). 491 6. IANA Considerations 493 This document makes no requests of the IANA. 495 7. Security Considerations 497 This reference architecture is intended to incrementally improve upon 498 commonly accepted "auto-install" practices used today that may 499 transmit configurations unencrypted (e.g., unencrypted configuration 500 files which can be downloaded connecting to unprotected ports in 501 datacenters, mailing initial configuration files on flash drives, or 502 emailing configuration files and asking a third-party to copy and 503 paste them over a serial terminal) or allow unrestricted access to 504 these configurations. 506 This document describes an object level security design to provide 507 confidentiality assurances for the configuration while it is in 508 transit between the configuration server and the unprovisioned device 509 even if the underly transport does not provide this security service. 511 The architecture provides no assurances about the source of the 512 encrypted configuration or protect against theft and reuse of 513 devices. 515 An attacker (e.g., a malicious datacenter employee, person in the 516 supply chain, etc.) who has physical access to the device before it 517 is connected to the network may be able to extract the device private 518 key (especially if it is not stored in a TPM), pretend to be the 519 device when connecting to the network, and download and extract the 520 (encrypted) configuration file. 522 An attacker with access to the configuration server (or the ability 523 to route traffic to configuration server under their control) and the 524 device's public key could return a configuration of the attacker's 525 choosing to the unprovisioned device. 527 This mechanism does not protect against a malicious vendor. While 528 the key pair should be generated on the device, and the private key 529 should be securely stored, the mechanism cannot detect or protect 530 against a vendor who claims to do this, but instead generates the key 531 pair off device and keeps a copy of the private key. It is largely 532 understood in the operator community that a malicious vendor or 533 attacker with physical access to the device is largely a "Game Over" 534 situation. 536 Even when using a secure bootstrap mechanism, security-conscious 537 operators may wish to bootstrap devices with a minimal or less- 538 sensitive configuration, and then replace this with a more complete 539 one after install. 541 8. Acknowledgments 543 The authors wish to thank everyone who contributed, including Benoit 544 Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael 545 Richardson, Sean Turner and Kent Watsen. Joe Clarke also provided 546 significant comments and review, and Tom Petch provided significant 547 editorial contributions to better describe the use cases, and clarify 548 the scope. 550 Roman Danyliw also provided helpful text around the certificate 551 usage. 553 9. Informative References 555 [Cisco_AutoInstall] 556 Cisco Systems, Inc., "Using AutoInstall to Remotely 557 Configure Cisco Networking Devices", Jan 2018, 558 . 562 [I-D.gutmann-scep] 563 Gutmann, P., "Simple Certificate Enrolment Protocol", 564 draft-gutmann-scep-16 (work in progress), March 2020. 566 [I-D.ietf-anima-bootstrapping-keyinfra] 567 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 568 and K. Watsen, "Bootstrapping Remote Secure Key 569 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 570 keyinfra-41 (work in progress), April 2020. 572 [I-D.ietf-opsawg-tacacs] 573 Dahm, T., Ota, A., dcmgash@cisco.com, d., Carrel, D., and 574 L. Grant, "The TACACS+ Protocol", draft-ietf-opsawg- 575 tacacs-18 (work in progress), March 2020. 577 [IEEE802-1AR] 578 IEEE, "IEEE Standard for Local and Metropolitan Area 579 Networks - Secure Device Identity", June 2018, 580 . 582 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 583 RFC 1350, DOI 10.17487/RFC1350, July 1992, 584 . 586 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 587 RFC 2131, DOI 10.17487/RFC2131, March 1997, 588 . 590 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 591 "Remote Authentication Dial In User Service (RADIUS)", 592 RFC 2865, DOI 10.17487/RFC2865, June 2000, 593 . 595 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 596 Unique IDentifier (UUID) URN Namespace", RFC 4122, 597 DOI 10.17487/RFC4122, July 2005, 598 . 600 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 601 Mail Extensions (S/MIME) Version 3.2 Message 602 Specification", RFC 5751, DOI 10.17487/RFC5751, January 603 2010, . 605 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 606 "Enrollment over Secure Transport", RFC 7030, 607 DOI 10.17487/RFC7030, October 2013, 608 . 610 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 611 Touch Provisioning (SZTP)", RFC 8572, 612 DOI 10.17487/RFC8572, April 2019, 613 . 615 Appendix A. Changes / Author Notes. 617 [RFC Editor: Please remove this section before publication ] 619 From -09 to -10 621 o Typos - "lenghts" => "lengths", missed a reference to Acme. 623 From -08 to -09 625 o Addressed Mirja's IETF LC comments. 627 From -04 to -08 629 o Please see GitHub commit log (I forgot to put them in here :-P ) 631 From -03 to -04 633 o Addressed Joe's WGLC comments. This involved changing the "just 634 try decrypt and pray" to vendor specific, like a file extension, 635 magic header sting, etc. 637 o Addressed tom's comments. 639 From individual WG-01 to -03: 641 o Addressed Joe Clarke's comments - 642 https://mailarchive.ietf.org/arch/msg/opsawg/JTzsdVXw- 643 XtWXZIIFhH7aW_-0YY 645 o Many typos / nits 647 o Broke Overview and Example Scenario into 2 sections. 649 o Reordered text for above. 651 From individual -04 to WG-01: 653 o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg- 654 sdi-00 656 From -00 to -01 658 o Nothing changed in the template! 660 From -01 to -03: 662 o See github commit log (AKA, we forgot to update this!) 664 o Added Colin Doyle. 666 From -03 to -04: 668 Addressed a number of comments received before / at IETF104 (Prague). 669 These include: 671 o Pointer to https://datatracker.ietf.org/doc/draft-ietf-netconf- 672 zerotouch -- included reference to (now) RFC8572 (KW) 674 o Suggested that 802.1AR IDevID (or similar) could be used. Stress 675 that this is designed for simplicity (MR) 677 o Added text to explain that any unique device identifier can be 678 used, not just serial number - serial number is simple and easy, 679 but anything which is unique (and can be communicated to the 680 customer) will work (BF). 682 o Lots of clarifications from Joe Clarke. 684 o Make it clear it should first try use the config, and if it 685 doesn't work, then try decrypt and use it. 687 o The CA part was confusing people - the certificate is simply a 688 wrapper for the key, and the Subject just an index, and so removed 689 that. 691 o Added a bunch of ASCII diagrams 693 Appendix B. Proof of Concept 695 This section contains a proof of concept of the system. It is only 696 intended for illustration, and is not intended to be used in 697 production. 699 It uses OpenSSL from the command line. In production something more 700 automated would be used. In this example, the unique device 701 identifier is the serial number of the router, SN19842256. 703 B.1. Step 1: Generating the certificate. 705 This step is performed by the router. It generates a key, then a 706 Certificate Signing Request (CSR), and then a self signed 707 certificate. 709 B.1.1. Step 1.1: Generate the private key. 711 $ openssl genrsa -out key.pem 2048 712 Generating RSA private key, 2048 bit long modulus 713 ................................................. 714 ................................................. 715 ..........................+++ 716 ...................+++ 717 e is 65537 (0x10001) 719 B.1.2. Step 1.2: Generate the certificate signing request. 721 $ openssl req -new -key key.pem -out SN19842256.csr 722 Country Name (2 letter code) [AU]:. 723 State or Province Name (full name) [Some-State]:. 724 Locality Name (eg, city) []:. 725 Organization Name (eg, company) [Internet Widgits Pty Ltd]:. 726 Organizational Unit Name (eg, section) []:. 727 Common Name (e.g. server FQDN or YOUR name) []:SN19842256 728 Email Address []:. 730 Please enter the following 'extra' attributes 731 to be sent with your certificate request 732 A challenge password []: 733 An optional company name []:. 735 B.1.3. Step 1.3: Generate the (self signed) certificate itself. 737 $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out 738 SN19842256.crt 740 The router then sends the key to the vendor's keyserver for 741 publication (not shown). 743 B.2. Step 2: Generating the encrypted configuration. 745 The operator now wants to deploy the new router. 747 They generate the initial configuration (using whatever magic tool 748 generates router configs!), fetch the router's certificate and 749 encrypt the configuration file to that key. This is done by the 750 operator. 752 B.2.1. Step 2.1: Fetch the certificate. 754 $ wget http://keyserv.example.net/certificates/SN19842256.crt 756 B.2.2. Step 2.2: Encrypt the configuration file. 758 S/MIME is used here because it is simple to demonstrate. This is 759 almost definitely not the best way to do this. 761 $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ 762 -out SN19842256.enc -outform PEM SN19842256.crt 763 $ more SN19842256.enc 764 -----BEGIN PKCS7----- 765 MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV 766 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 767 ... 768 LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt 769 -----END PKCS7----- 771 B.2.3. Step 2.3: Copy configuration to the configuration server. 773 $ scp SN19842256.enc config.example.com:/tftpboot 775 B.3. Step 3: Decrypting and using the configuration. 777 When the router connects to the operator's network it will detect 778 that does not have a valid configuration file, and will start the 779 "autoboot" process. This is a well documented process, but the high 780 level overview is that it will use DHCP to obtain an IP address and 781 configuration server. It will then use TFTP to download a 782 configuration file, based upon its serial number (this document 783 modifies the solution to fetch an encrypted configuration file 784 (ending in .enc)). It will then decrypt the configuration file, and 785 install it. 787 B.3.1. Step 3.1: Fetch encrypted configuration file from configuration 788 server. 790 $ tftp 2001:0db8::23 -c get SN19842256.enc 792 B.3.2. Step 3.2: Decrypt and use the configuration. 794 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 795 -out config.cfg -inkey key.pem 797 If an attacker does not have the correct key, they will not be able 798 to decrypt the configuration file: 800 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 801 -out config.cfg -inkey wrongkey.pem 802 Error decrypting PKCS#7 structure 803 140352450692760:error:06065064:digital envelope 804 routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: 805 $ echo $? 806 4 808 Authors' Addresses 810 Warren Kumari 811 Google 812 1600 Amphitheatre Parkway 813 Mountain View, CA 94043 814 US 816 Email: warren@kumari.net 818 Colin Doyle 819 Juniper Networks 820 1133 Innovation Way 821 Sunnyvale, CA 94089 822 US 824 Email: cdoyle@juniper.net