idnits 2.17.00 (12 Aug 2021) /tmp/idnits53540/draft-ietf-opsawg-sdi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2020) is 855 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AU' is mentioned on line 570, but not defined == Missing Reference: 'Some-State' is mentioned on line 571, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 **Important:** Read CONTRIBUTING.md before submitting feedback or contributing 2 ``` 4 Network Working Group W. Kumari 5 Internet-Draft Google 6 Intended status: Informational C. Doyle 7 Expires: January 23, 2020 Juniper Networks 8 January 17, 2020 10 Secure Device Install 11 draft-ietf-opsawg-sdi-01 13 Abstract 15 Deploying a new network device often requires that an employee 16 physically travel to a datacenter to perform the initial install and 17 configuration, even in shared datacenters with "smart-hands" type 18 support. In many cases, this could be avoided if there were a 19 standard, secure way to initially provision the devices. 21 This document extends existing auto-install / Zero-Touch Provisioning 22 mechanisms to make the process more secure. 24 [ Ed note: Text inside square brackets ([]) is additional background 25 information, answers to frequently asked questions, general musings, 26 etc. They will be removed before publication. This document is 27 being collaborated on in Github at: https://github.com/wkumari/draft- 28 wkumari-opsawg-sdi. The most recent version of the document, open 29 issues, etc should all be available here. The authors (gratefully) 30 accept pull requests. ] 32 [ Ed note: This document introduces concepts and serves as the basic 33 for discussion - because of this, it is conversational, and would 34 need to be firmed up before being published ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on January 23, 2020. 52 Copyright Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (https://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 71 2. Overview / Example Scenario . . . . . . . . . . . . . . . . . 4 72 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5 73 3.1. Device key generation . . . . . . . . . . . . . . . . . . 5 74 3.2. Certificate Publication Server . . . . . . . . . . . . . 5 75 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6 76 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6 77 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.3. Initial Customer Boot . . . . . . . . . . . . . . . . . . 7 79 5. Additional Considerations . . . . . . . . . . . . . . . . . . 10 80 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 10 82 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 10 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 9.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 90 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 13 91 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 13 92 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 13 93 B.1.2. Step 1.2: Generate the certificate signing request. . 13 94 B.1.3. Step 1.3: Generate the (self signed) certificate 95 itself. . . . . . . . . . . . . . . . . . . . . . . . 14 96 B.2. Step 2: Generating the encrypted config. . . . . . . . . 14 97 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 14 98 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 14 99 B.2.3. Step 2.3: Copy config to the config server. . . . . . 15 100 B.3. Step 3: Decrypting and using the config. . . . . . . . . 15 101 B.3.1. Step 3.1: Fetch encrypted config file from config 102 server. . . . . . . . . . . . . . . . . . . . . . . . 15 103 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 106 1. Introduction 108 In a growing, global network, significant amounts of time and money 109 are spent simply deploying new devices and "forklift" upgrading 110 existing devices. In many cases, these devices are in shared 111 datacenters (for example, Internet Exchange Points (IXP) or "carrier 112 neutral datacenters"), which have staff on hand that can be 113 contracted to perform tasks including physical installs, device 114 reboots, loading initial configurations, etc. There are also a 115 number of (often vendor proprietary) protocols to perform initial 116 device installs and configurations - for example, many network 117 devices will attempt to use DHCP to get an IP address and 118 configuration server, and then fetch and install a configuration when 119 they are first powered on. 121 Network device configurations contain a significant amount of 122 security related and / or proprietary information (for example, 123 RADIUS or TACACS+ secrets). Exposing these to a third party to load 124 onto a new device (or using an auto-install techniques which fetch an 125 (unencrypted) config file via something like TFTP) is simply not 126 acceptable to many operators, and so they have to send employees to 127 remote locations to perform the initial configuration work. As well 128 as having a significant monetary cost, it also takes significantly 129 longer to 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] are much 147 more fully featured, but also more complex to implement and / or are 148 not widely deployed yet. 150 1.1. Requirements notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2. Overview / Example Scenario 160 Sirius Cybernetics Corp needs another peering router, and so they 161 order another router from Acme Network Widgets, to be drop-shipped to 162 the Point of Presence (POP) / datacenter. Acme begins assembling the 163 new device, and tells Sirius what the new device's serial number will 164 be (SN:17894321). When Acme first installs the firmware on the 165 device and boots it, the device generates a public-private keypair, 166 and Acme publishes it on their keyserver (in a certificate, for ease 167 of use). 169 While the device is being shipped, Sirius generates the initial 170 device configuration, fetches the certificate from Acme keyservers by 171 providing the serial number of the new device. Sirius then encrypts 172 the device configuration and puts this encrypted config on a (local) 173 TFTP server. 175 When the device arrives at the POP, it gets installed in Sirius' 176 rack, and cabled as instructed. The new device powers up and 177 discovers that it has not yet been configured. It enters its 178 autoboot state, and begins the DHCP process. Sirius' DHCP server 179 provides it with an IP address and the address of the configuration 180 server. The router uses TFTP to fetch its config file (note that all 181 this is existing functionality). The device attempts to load the 182 config file - if the config file is unparsable, (new functionality) 183 the device tries to use its private key to decrypt the file, and, 184 assuming it validates, installs the new configuration. 186 Only the "correct" device will have the required private key and be 187 able to decrypt and use the config file (See Security 188 Considerations). An attacker would be able to connect to the network 189 and get an IP address. They would also be able to retrieve 190 (encrypted) config files by guessing serial numbers (or perhaps the 191 server would allow directory listing), but without the private keys 192 an attacker will not be able to decrypt the files. 194 This document uses the serial number of the device as a unique 195 identifier for simplicity; some vendors may not want to implement the 196 system using the serial number as the identifier for business reasons 197 (a competitor or similar could enumerate the serial numbers and 198 determine how many devices have been manufactured). Implementors are 199 free to choose some other way of generating identifiers (e.g UUID 200 [RFC4122]), but this will likely make it somewhat harder for 201 operators to use (the serial number is usually easy to find on a 202 device, a more complex system is likely harder to track). 204 [ Ed note: This example uses TFTP because that is what many vendors 205 use in their auto-install / ZTP feature. It could easily instead be 206 HTTP, FTP, etc. ] 208 3. Vendor Role / Requirements 210 This section describes the vendors roles and responsibilities and 211 provides an overview of what the device needs to do. 213 3.1. Device key generation 215 During the manufacturing stage, when the device is intially powered 216 on, it will generate a public-private keypair. It will send its 217 unique identifier and the public key to the vendor's Certificate 218 Publication Server to be published. The mechanism used to do this is 219 left undefined. Note that some devices may be contrained, and so may 220 send the raw public key and unique identifier to the certificate 221 publication server, while mode capable devices may generate and send 222 self-signed certifcates. 224 3.2. Certificate Publication Server 226 The certificate publication server contains a database of 227 certificates. If newly manufactured devices upload certificates the 228 certificate publication server can simply publish these, if the 229 devices provide raw public keys and unique identfiers the certificate 230 publication server will need to wrap these in a certificate. Note 231 that the certificat publication server MUST only accept certifcates 232 or keys from the vendor's manufacturing facilities. 234 The customers (e.g Sirius Cybernetics Corp) query this server with 235 the serial number (or other provided unique identifier) of a device, 236 and retrieve the associated certificate. It is expected that 237 operators will receive the unique identifier (serial number) of 238 devices when they purchase them, and will download and store / cache 239 the certificate. This means that there is not a hard requirement on 240 the uptime / reachability of the certificate publication server. 242 +------------+ 243 +------+ |Certificate | 244 |Device| |Publication | 245 +------+ | Server | 246 +------------+ 247 +----------------+ +--------------+ 248 | +---------+ | | | 249 | | Initial | | | | 250 | | boot? | | | | 251 | +----+----+ | | | 252 | | | | | 253 | +------v-----+ | | | 254 | | Generate | | | | 255 | |Self-signed | | | | 256 | |Certificate | | | | 257 | +------------+ | | | 258 | | | | +-------+ | 259 | +-------|---|-->|Receive| | 260 | | | +---+---+ | 261 | | | | | 262 | | | +---v---+ | 263 | | | |Publish| | 264 | | | +-------+ | 265 | | | | 266 +----------------+ +--------------+ 268 Initial certificate generation and publication. 270 4. Operator Role / Responsibilities 272 4.1. Administrative 274 When purchasing a new device, the accounting department will need to 275 get the unique device identifier (likely serial number) of the new 276 device and communicate it to the operations group. 278 4.2. Technical 280 The operator will contact the vendor's publication server, and 281 download the certificate (by providing the unique device identifier 282 of the device). The operator SHOULD fetch the certificate using a 283 secure transport (e.g HTTPS). The operator will then encrypt the 284 initial configuration to the key in the certifcate, and place it on 285 their TFTP server. See Appendix B for examples. 287 +------------+ 288 +--------+ |Certificate | 289 |Operator| |Publication | 290 +--------+ | Server | 291 +------------+ 292 +----------------+ +----------------+ 293 | +-----------+ | | +-----------+ | 294 | | Fetch | | | | | | 295 | | Device |<------>|Certificate| | 296 | |Certificate| | | | | | 297 | +-----+-----+ | | +-----------+ | 298 | | | | | 299 | +-----v------+ | | | 300 | | Encrypt | | | | 301 | | Device | | | | 302 | | Config | | | | 303 | +-----+------+ | | | 304 | | | | | 305 | +-----v------+ | | | 306 | | Publish | | | | 307 | | TFTP | | | | 308 | | Server | | | | 309 | +------------+ | | | 310 | | | | 311 +----------------+ +----------------+ 313 Fetching the certificate, encrypting the configuration, publishing 314 the encrypted configuration. 316 4.3. Initial Customer Boot 318 When the device is first booted by the customer (and on subsequent 319 boots), if the device has no valid configuration, it will use 320 existing auto-install type functionality - it performs DHCP Discovery 321 until it gets a DHCP offer including DHCP option 66 or 150, contact 322 the server listed in these DHCP options and download its config file. 324 After retrieving the config file, the device will examine the file 325 and determine if it seems to be a valid config, and if so, proceeds 326 as it normally would. Note that this is existing functionality (for 327 example, Cisco devices fetch the config file named by the Bootfile- 328 Name DHCP option (67)). 330 If the file appears be "garbage", the device will attempt to decrypt 331 the configuration file using its private key. If it is able to 332 decrypt and validate the file it will install the configuration, and 333 start using it. The exact method that the device uses to determine 334 if a config file is "valid" is implementation specific, but a normal 335 config file looks significantly different to an encrypted blob. 337 Note that the device only needs DHCP and to be able to download the 338 config file; after the initial power-on in the factory it never need 339 to access the Internet or vendor or certifcate publication server - 340 it (and only it) has the private key and so has the ability to 341 decrypt the config file. 343 +--------+ +--------------+ 344 | Device | |Config server | 345 +--------+ | (e.g TFTP) | 346 +--------------+ 347 +---------------------------+ +------------------+ 348 | +-----------+ | | | 349 | | | | | | 350 | | DHCP | | | | 351 | | | | | | 352 | +-----+-----+ | | | 353 | | | | | 354 | +-----v------+ | | +-----------+ | 355 | | | | | | Encrypted | | 356 | |Fetch config|<------------------>| config | | 357 | | | | | | file | | 358 | +-----+------+ | | +-----------+ | 359 | | | | | 360 | X | | | 361 | / \ | | | 362 | / \ Y +--------+ | | | 363 | |Sane?|---->|Install,| | | | 364 | \ / | Boot | | | | 365 | \ / +--------+ | | | 366 | V | | | 367 | |N | | | 368 | | | | | 369 | +-----v------+ | | | 370 | |Decrypt with| | | | 371 | |private key | | | | 372 | +-----+------+ | | | 373 | | | | | 374 | v | | | 375 | / \ | | | 376 | / \ Y +--------+ | | | 377 | |Sane?|---->|Install,| | | | 378 | \ / | Boot | | | | 379 | \ / +--------+ | | | 380 | V | | | 381 | |N | | | 382 | | | | | 383 | +----v---+ | | | 384 | |Give up | | | | 385 | |go home | | | | 386 | +--------+ | | | 387 | | | | 388 +---------------------------+ +------------------+ 390 Device boot, fetch and install config file 392 5. Additional Considerations 394 5.1. Key storage 396 Ideally, the keypair would be stored in a TPM on something which is 397 identified as the "router" - for example, the chassis / backplane. 398 This is so that a keypair is bound to what humans think of as the 399 "device", and not, for example (redundant) routing engines. Devices 400 which implement IEEE 802.1AR could choose to use the IDevID for this 401 purpose. 403 5.2. Key replacement 405 It is anticipated that some operator may want to replace the (vendor 406 provided) keys after installing the device. There are two options 407 when implementing this - a vendor could allow the operator's key to 408 completely replace the initial device generated key (which means 409 that, if the device is ever sold, the new owner couldn't use this 410 technique to install the device), or the device could prefer the 411 operators installed key. This is an implementation decision left to 412 the vendor. 414 5.3. Device reinstall 416 Increasingly, operations is moving towards an automated model of 417 device management, whereby portions (or the entire) configuration is 418 programmatically generated. This means that operators may want to 419 generate an entire configuration after the device has been initially 420 installed and ask the device to load and use this new configuration. 421 It is expected (but not defined in this document, as it is vendor 422 specific) that vendors will allow the operator to copy a new, 423 encrypted config (or part of a config) onto a device and then request 424 that the device decrypt and install it (e.g: 'load replace 425 encrypted)). The operator could also choose to reset the device to 426 factory defaults, and allow the device to act as though it were the 427 initial boot (see Section 4.3). 429 6. IANA Considerations 431 This document makes no requests of the IANA. 433 7. Security Considerations 435 This mechanism is intended to replace either expensive (traveling 436 employees) or insecure mechanisms of installing newly deployed 437 devices such as: unencrypted config files which can be downloaded by 438 connecting to unprotected ports in datacenters, mailing initial 439 config files on flash drives, or emailing config files and asking a 440 third-party to copy and paste it over a serial terminal. It does not 441 protect against devices with malicious firmware, nor theft and reuse 442 of devices. 444 An attacker (e.g a malicious datacenter employee) who has physical 445 access to the device before it is connected to the network the 446 attacker may be able to extract the device private key (especially if 447 it isn't stored in a TPM), pretend to be the device when connecting 448 to the network, and download and extract the (encrypted) config file. 450 This mechanism does not protect against a malicious vendor - while 451 the keypair should be generated on the device, and the private key 452 should be securely stored, the mechanism cannot detect or protect 453 against a vendor who claims to do this, but instead generates the 454 keypair off device and keeps a copy of the private key. It is 455 largely understood in the operator community that a malicious vendor 456 or attacker with physical access to the device is largely a "Game 457 Over" situation. 459 Even when using a secure bootstrapping mechanism, security conscious 460 operators may wish to bootstrapping devices with a minimal / less 461 sensitive config, and then replace this with a more complete one 462 after install. 464 8. Acknowledgements 466 The authors wish to thank everyone who contributed, including Benoit 467 Claise, Sam Ribeiro, Michael Richardson, Sean Turner and Kent Watsen. 468 Joe Clarke provided significant comments and review. 470 9. References 472 9.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 9.2. Informative References 485 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 486 Unique IDentifier (UUID) URN Namespace", RFC 4122, 487 DOI 10.17487/RFC4122, July 2005, 488 . 490 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 491 Touch Provisioning (SZTP)", RFC 8572, 492 DOI 10.17487/RFC8572, April 2019, 493 . 495 Appendix A. Changes / Author Notes. 497 [RFC Editor: Please remove this section before publication ] 499 From individual -04 to WG-01: 501 o Renamed from draft-wkumari-opsawg-sdi-04 -> draft-ietf-opsawg- 502 sdi-00 504 From -00 to -01 506 o Nothing changed in the template! 508 From -01 to -03: 510 o See github commit log (AKA, we forgot to update this!) 512 o Added Colin Doyle. 514 From -03 to -04: 516 Addressed a number of comments received before / at IETF104 (Prague). 517 These include: 519 o Pointer to https://datatracker.ietf.org/doc/draft-ietf-netconf- 520 zerotouch -- included reference to (now) RFC8572 (KW) 522 o Suggested that 802.1AR IDevID (or similar) could be used. Stress 523 that this is designed for simplicity (MR) 525 o Added text to explain that any unique device identifier can be 526 used, not just serial number - serial number is simple and easy, 527 but anything which is unique (and can be communicated to the 528 customer) will work (BF). 530 o Lots of clarifications from Joe Clarke. 532 o Make it clear it should first try use the config, and if it 533 doesn't work, then try decrypt and use it. 535 o The CA part was confusing people - the certificate is simply a 536 wrapper for the key, and the Subject just an index, and so removed 537 that. 539 o Added a bunch of ASCII diagrams 541 Appendix B. Demo / proof of concept 543 This section contains a rough demo / proof of concept of the system. 544 It is only intended for illustration; presumably things like 545 algorithms, key lengths, format / containers will provide much fodder 546 for discussion. 548 It uses OpenSSL from the command line, in production something more 549 automated would be used. In this example, the unique identifier is 550 the serial number of the router, SN19842256. 552 B.1. Step 1: Generating the certificate. 554 This step is performed by the router. It generates a key, then a 555 csr, and then a self signed certificate. 557 B.1.1. Step 1.1: Generate the private key. 559 $ openssl genrsa -out key.pem 2048 560 Generating RSA private key, 2048 bit long modulus 561 ................................................. 562 ................................................. 563 ..........................+++ 564 ...................+++ 565 e is 65537 (0x10001) 567 B.1.2. Step 1.2: Generate the certificate signing request. 569 $ openssl req -new -key key.pem -out SN19842256.csr 570 Country Name (2 letter code) [AU]:. 571 State or Province Name (full name) [Some-State]:. 572 Locality Name (eg, city) []:. 573 Organization Name (eg, company) [Internet Widgits Pty Ltd]:. 574 Organizational Unit Name (eg, section) []:. 575 Common Name (e.g. server FQDN or YOUR name) []:SN19842256 576 Email Address []:. 578 Please enter the following 'extra' attributes 579 to be sent with your certificate request 580 A challenge password []: 581 An optional company name []:. 583 B.1.3. Step 1.3: Generate the (self signed) certificate itself. 585 $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out 586 SN19842256.crt 588 The router then sends the key to the vendor's keyserver for 589 publication (not shown). 591 B.2. Step 2: Generating the encrypted config. 593 The operator now wants to deploy the new router. 595 They generate the initial config (using whatever magic tool generates 596 router configs!), fetch the router's certificate and encrypt the 597 config file to that key. This is done by the operator. 599 B.2.1. Step 2.1: Fetch the certificate. 601 $ wget http://keyserv.example.net/certificates/SN19842256.crt 603 B.2.2. Step 2.2: Encrypt the config file. 605 I'm using S/MIME because it is simple to demonstrate. This is almost 606 definitely not the best way to do this. 608 $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ 609 -out SN19842256.enc -outform PEM SN19842256.crt 610 $ more SN19842256.enc 611 -----BEGIN PKCS7----- 612 MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV 613 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 614 ... 615 LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt 616 -----END PKCS7----- 618 B.2.3. Step 2.3: Copy config to the config server. 620 $ scp SN19842256.enc config.example.com:/tftpboot 622 B.3. Step 3: Decrypting and using the config. 624 When the router connects to the operator's network it will detect 625 that does not have a valid configuration file, and will start the 626 "autoboot" process. This is a well documented process, but the high 627 level overview is that it will use DHCP to obtain an IP address and 628 config server. It will then use TFTP to download a configuration 629 file, based upon its serial number (this document modifies the 630 solution to fetch an encrypted config file (ending in .enc)). It 631 will then then decrypt the config file, and install it. 633 B.3.1. Step 3.1: Fetch encrypted config file from config server. 635 $ tftp 192.0.2.1 -c get SN19842256.enc 637 B.3.2. Step 3.2: Decrypt and use the config. 639 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 640 -out config.cfg -inkey key.pem 642 If an attacker does not have the correct key, they will not be able 643 to decrypt the config: 645 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 646 -out config.cfg -inkey wrongkey.pem 647 Error decrypting PKCS#7 structure 648 140352450692760:error:06065064:digital envelope 649 routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: 650 $ echo $? 651 4 653 Authors' Addresses 655 Warren Kumari 656 Google 657 1600 Amphitheatre Parkway 658 Mountain View, CA 94043 659 US 661 Email: warren@kumari.net 663 Colin Doyle 664 Juniper Networks 665 1133 Innovation Way 666 Sunnyvale, CA 94089 667 US 669 Email: cdoyle@juniper.net 671 ```