idnits 2.17.1 draft-wkumari-opsawg-sdi-03.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 : ---------------------------------------------------------------------------- -- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 16, 2019) is 1921 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AU' is mentioned on line 381, but not defined == Missing Reference: 'Some-State' is mentioned on line 382, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 339, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 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: July 20, 2019 Juniper Networks 6 January 16, 2019 8 Secure Device Install 9 draft-wkumari-opsawg-sdi-03 11 Abstract 13 Deploying a new network device often requires that an employee 14 physically travel to a datacenter to perform the initial install and 15 configuration, even in shared datacenters with "smart-hands" type 16 support. In many cases, this could be avoided if there were a 17 standard, secure way to initially provision the devices. 19 This document extends existing auto-install / Zero-Touch Provisioning 20 to make the process more secure. 22 [ Ed note: Text inside square brackets ([]) is additional background 23 information, answers to frequently asked questions, general musings, 24 etc. They will be removed before publication. This document is 25 being collaborated on in Github at: https://github.com/wkumari/draft- 26 wkumari-opsawg-sdi. The most recent version of the document, open 27 issues, etc should all be available here. The authors (gratefully) 28 accept pull requests. ] 30 [ Ed note: This document introduces concepts and serves as the basic 31 for discussion - because of this, it is conversational, and would 32 need to be firmed up before being published ] 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 20, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 69 2. Overview / Example Scenario . . . . . . . . . . . . . . . . . 4 70 3. Vendor Role / Requirements . . . . . . . . . . . . . . . . . 5 71 3.1. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Certificate Publication Server . . . . . . . . . . . . . 5 73 3.3. Initial Device Boot . . . . . . . . . . . . . . . . . . . 5 74 3.4. Subsequent Boots . . . . . . . . . . . . . . . . . . . . 5 75 4. Operator Role / Responsibilities . . . . . . . . . . . . . . 6 76 4.1. Administrative . . . . . . . . . . . . . . . . . . . . . 6 77 4.2. Technical . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Future enhancements / Discussion . . . . . . . . . . . . . . 6 79 5.1. Key storage . . . . . . . . . . . . . . . . . . . . . . . 6 80 5.2. Key replacement . . . . . . . . . . . . . . . . . . . . . 7 81 5.3. Device reinstall . . . . . . . . . . . . . . . . . . . . 7 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 9.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 89 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 8 90 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 8 91 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 8 92 B.1.2. Step 1.2: Generate the certificate signing request. . 9 93 B.1.3. Step 1.3: Generate the (self signed) certificate 94 itself. . . . . . . . . . . . . . . . . . . . . . . . 9 95 B.2. Step 2: Generating the encrypted config. . . . . . . . . 9 96 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 9 97 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 10 98 B.2.3. Step 2.3: Copy config to the config server. . . . . . 10 99 B.3. Step 3: Decrypting and using the config. . . . . . . . . 10 100 B.3.1. Step 3.1: Fetch encrypted config file from config 101 server. . . . . . . . . . . . . . . . . . . . . . . . 10 102 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 10 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 105 1. Introduction 107 In a growing, global network, significant amounts of time and money 108 are spent simply deploying new devices and "forklift" upgrading 109 existing devices. In many cases, these devices are in shared 110 datacenters (for example, Internet Exchange Points (IXP) or "carrier 111 neutral datacenters"), which have staff on hand that can be 112 contracted to perform tasks including physical installs, device 113 reboots, loading initial configurations, etc. There are also a 114 number of (often vendor proprietary) protocols to perform initial 115 device installs and configurations - for example, many network 116 devices will attempt to use DHCP to get an IP address and 117 configuration server, and then fetch and install a configuration when 118 they are first powered on. 120 Network device configurations contain a significant amount of 121 security related and / or proprietary information (for example, 122 RADIUS or TACACS secrets). Exposing these to a third party to load 123 onto a new device (or using an auto-install techniques which fetch an 124 (unencrypted) config file via something like TFTP) is simply not 125 acceptable to many operators, and so they have to send employees to 126 remote locations to perform the initial configuration work. As well 127 as having a significant monetary cost, it also takes significantly 128 longer to install devices and is generally inefficient. 130 There are some workarounds to this, such as asking the vendor to pre- 131 configure the devices before shipping it; asking the smart-hands to 132 install a terminal server; providing a minimal, unsecured 133 configuration and using that to bootstrap to a complete 134 configuration, etc; but these are often clumsy and have security 135 issues - for example, in the terminal server case, the console port 136 connection could be easily snooped. 138 This document layers security onto existing auto-install solutions to 139 provide a secure method to initially configure new devices. 141 1.1. Requirements notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Overview / Example Scenario 149 Sirius Cybernetics Corp needs another peering router, and so they 150 order another router from Acme Network Widgets, to be drop-shipped to 151 a POP. Acme begins assembling the new device, and tells Sirius what 152 the new device's serial number will be (SN:17894321). During the 153 initial boot / testing, the router generates a public-private 154 keypair, and Acme publishes it on their keyserver (in a certificate, 155 for ease of use). 157 While Acme is shipping the new device, Sirius begins generating the 158 initial device configuration. Once the config is ready, Sirius 159 contacts the Acme keyserver, provides the serial number of the new 160 device and fetches the device's public key. Sirius then encrypts the 161 device configuration and puts this encrypted config on a (local) TFTP 162 server. 164 When the POP receives the new device, they install it in Sirius' 165 rack, and connect the cables as instructed. The new device powers up 166 and discovers that it has not yet been configured. It enters its 167 autoboot state, and begins DHCPing. Sirius' DHCP server provides it 168 with an IP address and the address of the configuration server. The 169 router uses TFTP to fetch a file named according to its serial number 170 (acme_17894321.cfg). It then uses its private key to decrypt this 171 file, and, assuming it validates, installs the new configuration. 173 Only the "correct" device will have the required private key and be 174 able to decrypt and use the config file (See Security 175 Considerations). An attacker would be able to connect to the network 176 and get an IP address. They would also be able to retrieve 177 (encrypted) config files by guessing serial numbers (or perhaps the 178 server would allow directory listing), but without the private keys 179 an attacker will not be able to decrypt the files. 181 [ Ed note: This example uses TFTP because that is what many vendors 182 use in their auto-install / ZTP feature. It could easily instead be 183 HTTP, FTP, etc. ] 185 3. Vendor Role / Requirements 187 This section describes the vendors roles and responsibilities and 188 provides an overview of what the device needs to do. 190 3.1. CA Infrastructure 192 The vendor needs to run some (simple) CA infrastructure to sign and 193 publish certificates. When a device is initially powered on (in the 194 factory) it will generate a public / private keypair and a 195 Certificate Signing Request (CSR), with the commonName being the 196 Serial Number of the device. The device sends this CSR to the CA, 197 which signs the CSR, returns the certificate to the device and also 198 sends it to a certificate publication server. 200 3.2. Certificate Publication Server 202 The certificate publication server contains a database of all signed 203 certificates. Customers (e.g Sirius Cybernetics Corp) query this 204 server with a serial number, and retrieve the associated certificate. 205 It is expected that operators will receive the serial numbers of 206 newly purchased devices when they purchase them, and that some 207 automated system will download and store / cache the certificate. 208 This means that there is not a hard requirement on the uptime / 209 reachability of the certificate publication server. 211 [ Ed: The vendor may not want to expose (for commercial reasons) how 212 many devices it has made. This can be mitigated by using non- 213 contiguous serial numbers, and simply creating "fake devices", etc. ] 215 3.3. Initial Device Boot 217 When the device is powered on for the very first time, it will 218 generate its keypair. It then generates a CSR (including the device 219 serial number) and sends it to the vendor's CA, which signs the 220 certificate. The device receives the signed certificate and stores 221 it. 223 3.4. Subsequent Boots 225 After the initial boot, it the device has no (valid) configuration 226 file, it will perform standard an auto-install type functionality. 227 For example, it will perform DHCP Discovery until it gets a DHCP 228 offer including DHCP option 66 or 150. It will contact the server 229 listed in these DHCP options and download a configuration file named 230 config_.cfg. This is all existing (often vendor 231 proprietary) functionality. 233 After retrieving the config file, Secure Device Install devices will 234 attempt to decrypt the configuration file using its private key. If 235 it is able to decrypt and validate the file it will install the 236 configuration, and start using it. 238 [ Ed note: SDI will also allows additional functionality, like always 239 storing the configs encrypted, having the device store its config 240 encrypted in flash (so that e.g RMAing a routing engine will not leak 241 config, etc. I'm not describing this in detail because: 243 1. I want to keep this document simple and focused and, more 244 importantly 246 2. I left converting this into ID format until the draft cut-off and 247 have run out of time :-) ] 249 4. Operator Role / Responsibilities 251 4.1. Administrative 253 When purchasing a new device, the accounting department will need to 254 get the serial number of the new device and communicate it to the 255 operations group. 257 4.2. Technical 259 The operator will contact the vendor's publication server, and 260 download the certificate (by providing the serial number of the 261 device). They will then encrypt the initial configuration to that 262 key, and place it on the TFTP server, named config_.enc. See 263 Appendix B for examples. 265 5. Future enhancements / Discussion 267 [ Ed note: Ed / RFC Editor to remove this section before publication. 268 ] 270 5.1. Key storage 272 Currently most network devices will store the private key in NV 273 storage (NVRAM / Flash / Disk), but some vendors are already planning 274 on including a TPM module in their devices. Ideally, the keypair 275 would be stored in a TPM on something which is identified as the 276 "router" - for example, the chassis / backplane. This is so that a 277 keypair is bound to what humans think of as the "device", and not, 278 for example, (redundant) routing engines. 280 5.2. Key replacement 282 It is anticipated that some operator may want to replace the (vendor 283 provided) keys after installing the device. This would remove (some) 284 concerns that the vendor may have kept a copy of the private key, or 285 that the device may have been intercepted during shipping and the 286 private key duplicated. This would also allow for the use of 287 certificates signed by the operator's CA (e.g using RFC7030 - 288 Enrollment over Secure Transport) this is a trivial operation, but is 289 not described here (to avoid cluttering up the doc). 291 5.3. Device reinstall 293 Increasingly, operations is moving towards an automated model of 294 device management, whereby portions (or the entire) configuration is 295 programmatically generated. This means that operators may want to 296 generate an entire configuration after the device has been initially 297 installed and ask the device to load and use this new configuration. 298 It is expected (but not defined in this document, as it is too vendor 299 specific) that vendors will allow the operator to e.g scp a new, 300 encrypted config (or part of a config) onto a device and then request 301 that the device decrypt and install it (e.g: 'load replace 302 encrypted)). 304 6. IANA Considerations 306 This document contains no IANA considerations.Template: Fill this in! 308 7. Security Considerations 310 This needs to be completed, including: 312 1. We are trusting the vendor to have not kept a copy of the private 313 key when the device initially generated its keypair. 314 Unfortunately you are already trusting the vendor in many ways - 315 it could have included a backdoor in it's code, etc. 317 2. Devices should be storing their keying information in something 318 like a TPM, to help mitigate the private key being extracted (e.g 319 read off disk) in shipping, when the device is first unpacked by 320 smart-hands, etc). A number of vendors already include a TPM for 321 other security functions. 323 8. Acknowledgements 325 The authors wish to thank some folk, including Benoit Claise, Colin 326 Doyle, Sam Ribeiro, and Sean Turner. 328 9. References 330 9.1. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 9.2. Informative References 339 [I-D.ietf-sidr-iana-objects] 340 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 341 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 342 progress), May 2011. 344 Appendix A. Changes / Author Notes. 346 [RFC Editor: Please remove this section before publication ] 348 From -00 to -01 350 o Nothing changed in the template! 352 Appendix B. Demo / proof of concept 354 This section contains a rough demo / proof of concept of the system. 355 It is only intended for illustration; presumably things like 356 algorithms, key lengths, format / containers will provide much fodder 357 for discussion. 359 It uses OpenSSL from the command line, in production something more 360 automated would be used. In this example, the serial number of the 361 router is SN19842256. 363 B.1. Step 1: Generating the certificate. 365 This step is performed by the router. It generates a key, then a 366 csr, and then a self signed certificate. 368 B.1.1. Step 1.1: Generate the private key. 370 $ openssl genrsa -out key.pem 2048 371 Generating RSA private key, 2048 bit long modulus 372 ................................................. 373 ................................................. 374 ..........................+++ 375 ...................+++ 376 e is 65537 (0x10001) 378 B.1.2. Step 1.2: Generate the certificate signing request. 380 $ openssl req -new -key key.pem -out SN19842256.csr 381 Country Name (2 letter code) [AU]:. 382 State or Province Name (full name) [Some-State]:. 383 Locality Name (eg, city) []:. 384 Organization Name (eg, company) [Internet Widgits Pty Ltd]:. 385 Organizational Unit Name (eg, section) []:. 386 Common Name (e.g. server FQDN or YOUR name) []:SN19842256 387 Email Address []:. 389 Please enter the following 'extra' attributes 390 to be sent with your certificate request 391 A challenge password []: 392 An optional company name []:. 394 B.1.3. Step 1.3: Generate the (self signed) certificate itself. 396 $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out 397 SN19842256.crt 399 The router then sends the key to the vendor's keyserver for 400 publication (not shown). 402 B.2. Step 2: Generating the encrypted config. 404 The operator now wants to deploy the new router. 406 They generate the initial config (using whatever magic tool generates 407 router configs!), fetch the router's certificate and encrypt the 408 config file to that key. This is done by the operator. 410 B.2.1. Step 2.1: Fetch the certificate. 412 $ wget http://keyserv.example.net/certificates/SN19842256.crt 414 B.2.2. Step 2.2: Encrypt the config file. 416 I'm using S/MIME because it is simple to demonstrate. This is almost 417 definitely not the best way to do this. 419 $ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\ 420 -out SN19842256.enc -outform PEM SN19842256.crt 421 $ more SN19842256.enc 422 -----BEGIN PKCS7----- 423 MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV 424 BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3 425 ... 426 LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt 427 -----END PKCS7----- 429 B.2.3. Step 2.3: Copy config to the config server. 431 $ scp SN19842256.enc config.example.com:/tftpboot 433 B.3. Step 3: Decrypting and using the config. 435 When the router connects to the operator's network it will detect 436 that does not have a valid configuration file, and will start the 437 "autoboot" process. This is a well documented process, but the high 438 level overview is that it will use DHCP to obtain an IP address and 439 config server. It will then use TFTP to download a configuration 440 file, based upon its serial number (this document modifies the 441 solution to fetch an encrypted config file (ending in .enc)). It 442 will then then decrypt the config file, and install it. 444 B.3.1. Step 3.1: Fetch encrypted config file from config server. 446 $ tftp 192.0.2.1 -c get SN19842256.enc 448 B.3.2. Step 3.2: Decrypt and use the config. 450 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 451 -out config.cfg -inkey key.pem 453 If an attacker does not have the correct key, they will not be able 454 to decrypt the config: 456 $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\ 457 -out config.cfg -inkey wrongkey.pem 458 Error decrypting PKCS#7 structure 459 140352450692760:error:06065064:digital envelope 460 routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592: 461 $ echo $? 462 4 464 Authors' Addresses 466 Warren Kumari 467 Google 468 1600 Amphitheatre Parkway 469 Mountain View, CA 94043 470 US 472 Email: warren@kumari.net 474 Colin Doyle 475 Juniper Networks 476 1133 Innovation Way 477 Sunnyvale, CA 94089 478 US 480 Email: cdoyle@juniper.net