idnits 2.17.1 draft-ietf-sidr-rtr-keying-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2018) is 2195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ Lab / Dragon Research Lab 4 Intended status: Standards Track S. Turner 5 Expires: October 25, 2018 sn3rd 6 K. Patel 7 Arrcus, Inc. 8 April 23, 2018 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-15 13 Abstract 15 BGPsec-speaking routers are provisioned with private keys in order to 16 sign BGPsec announcements. The corresponding public keys are 17 published in the global Resource Public Key Infrastructure, enabling 18 verification of BGPsec messages. This document describes two methods 19 of generating the public-private key-pairs: router-driven and 20 operator-driven. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 16, 2017. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Management / Router Communication . . . . . . . . . . . . . . 3 66 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 67 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4 69 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 70 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 71 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5 72 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6 73 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6 74 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7 75 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 78 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 79 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 12.1. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Management/Router Channel Security . . . . . . . . . 14 86 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 BGPsec-speaking routers are provisioned with private keys, which 92 allow them to digitally sign BGPsec announcements. To verify the 93 signature, the public key, in the form of a certificate [RFC8209], is 94 published in the Resource Public Key Infrastructure (RPKI). This 95 document describes provisioning of BGPsec-speaking routers with the 96 appropriate public-private key-pairs. There are two sub-methods, 97 router-driven and operator-driven. 99 These two sub-methods differ in where the keys are generated: on the 100 router in the router-driven method, and elsewhere in the operator- 101 driven method. Routers are required to support at least one of the 102 methods in order to work in various deployment environments. Some 103 routers may not allow the private key to be off-loaded while others 104 may. While off-loading private keys would ease swapping of routing 105 engines, exposure of private keys is a well known security risk. 107 In the operator-driven method, the operator generates the private/ 108 public key-pair and sends it to the router. 110 In the router-driven method, the router generates its own public/ 111 private key-pair. 113 The router-driven model mirrors the model used by traditional PKI 114 subscribers; the private key never leaves trusted storage (e.g., 115 Hardware Security Module). This is by design and supports classic 116 PKI Certification Policies for (often human) subscribers which 117 require the private key only ever be controlled by the subscriber to 118 ensure that no one can impersonate the subscriber. For non-humans, 119 this model does not always work. For example, when an operator wants 120 to support hot-swappable routers the same private key needs to be 121 installed in the soon-to-be online router that was used by the the 122 soon-to-be offline router. This motivated the operator-driven model. 124 The remainder of this document describes how operators can use the 125 two methods to provision new and existing routers. The methods 126 described involve the operator configuring the two end points (i.e., 127 the management station and the router) and acting as the 128 intermediary. Section 7 describes a method that requires more 129 capable routers. 131 Useful References: [RFC8205] describes gritty details, [RFC8209] 132 specifies the format for the PKCS#10 certification request, and 133 [RFC8208] specifies the algorithms used to generate the PKCS#10's 134 signature. 136 2. Management / Router Communication 138 Operators are free to use either the router-driven or operator-driven 139 method as supported by the platform. Regardless of the method 140 chosen, operators first establish a protected channel between the 141 management system and the router. How this protected channel is 142 established is router-specific and is beyond scope of this document. 143 Though other configuration mechanisms might be used, e.g. NetConf 144 (see [RFC6470]); for simplicity, in this document, the protected 145 channel between the management platform and the router is assumed to 146 be an SSH-protected CLI. See Appendix A for security considerations 147 for this protected channel. 149 3. Exchange Certificates 151 A number of options exist for the operator management station to 152 exchange PKI-related information with routers and with the RPKI 153 including: 155 - Use application/pkcs10 media type [RFC5967] to extract certificate 156 requests and application/pkcs7-mime [I-D.lamps-rfc5751-bis] to return 157 the issued certificate, 159 - Use FTP or HTTP per [RFC2585], and 161 - Use Enrollment over Secure Transport (EST) protocol per [RFC7030]. 163 4. Set-Up 165 To start, the operator uses the protected channel to install the 166 appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. 167 This will later enable the router to validate the router certificate 168 returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. 170 The operator also configures the Autonomous System (AS) number to be 171 used in the generated router certificate. This may be the sole AS 172 configured on the router, or an operator choice if the router is 173 configured with multiple ASs. A router with multiple ASs can be 174 configured with multiple router certificates by following the process 175 of this document for each desired certificate. 177 The operator configures or extracts from the router the BGP 178 Identifier [RFC4271] to be used in the generated router certificate. 179 In the case where the operator has chosen not to use unique per- 180 router certificates, a BGP Identifier of 0 may be used. 182 5. Generate PKCS#10 184 The private key, and hence the PKCS#10 certification request, which 185 is sometimes referred to as a Certificate Signing Request (CSR), may 186 be generated by the router or by the operator. 188 NOTE: The PKCS#10 certification request does not include the AS 189 number or the BGP Identifier for the router certificate. Therefore, 190 the operator transmits the AS it has chosen or the router and the BGP 191 Identifier as well when it sends the CSR to the CA. 193 5.1. Router-Generated Keys 195 In the router-generated method, once the protected channel is 196 established and the initial Set-Up (Section 4) performed, the 197 operator issues a command or commands for the router to generate the 198 public/private key pair, to generate the PKCS#10 certification 199 request, and to sign the PKCS#10 certification request with the 200 private key. Once generated, the PKCS#10 certification request is 201 returned to the operator over the protected channel. 203 The operator includes the chosen AS number and the BPG Identifier 204 when it sends the CSR to the CA. 206 NOTE: If a router were to communicate directly with a CA to have the 207 CA certify the PKCS#10 certification request, there would be no way 208 for the CA to authenticate the router. As the operator knows the 209 authenticity of the router, the operator mediates the communication 210 with the CA. 212 5.2. Operator-Generated Keys 214 In the operator-generated method, the operator generates the 215 public/private key pair on a management station and installs the 216 private key into the router over the protected channel. Beware that 217 experience has shown that copy and paste from a management station to 218 a router can be unreliable for long texts. 220 The operator then creates and signs the PKCS#10 certification request 221 with the private key; the operator includes the chosen AS number and 222 the BPG Identifier when it sends the CSR to the CA. 224 5.2.1. Using PKCS#8 to Transfer Private Key 226 A private key can be encapsulated in a PKCS#8 Asymmetric Key Package 227 [RFC5958] and should be further encapsulated in Cryptographic Message 228 Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity 229 (EE) private key. 231 The router SHOULD verify the signature of the encapsulated PKCS#8 to 232 ensure the returned private key did in fact come from the operator, 233 but this requires that the operator also provision via the CLI or 234 include in the SignedData the RPKI CA certificate and relevant AS's 235 EE certificate(s). The router should inform the operator whether or 236 not the signature validates to a trust anchor; this notification 237 mechanism is out of scope. 239 6. Send PKCS#10 and Receive PKCS#7 241 The operator uses RPKI management tools to communicate with the 242 global RPKI system to have the appropriate CA validate the PKCS#10 243 certification request, sign the key in the PKCS#10 (i.e., certify it) 244 and generate a PKCS#7 certs-only message, as well as publishing the 245 certificate in the Global RPKI. External network connectivity may be 246 needed if the certificate is to be published in the Global RPKI. 248 After the CA certifies the key, it does two things: 250 1. Publishes the certificate in the Global RPKI. The CA must have 251 connectivity to the relevant publication point, which in turn 252 must have external network connectivity as it is part of the 253 Global RPKI. 255 2. Returns the certificate to the operator's management station, 256 packaged in a PKCS#7 certs-only message, using the corresponding 257 method by which it received the certificate request. It SHOULD 258 include the certificate chain below the TA Certificate so that 259 the router can validate the router certificate. 261 In the operator-generated method, the operator SHOULD extract the 262 certificate from the PKCS#7 certs-only message, and verify that the 263 private key it holds corresponds to the returned public key. 265 In the operator-generated method, the operator has already installed 266 the private key in the router (see Section 5.2). 268 7. Install Certificate 270 The operator provisions the PKCS#7 certs-only message into the router 271 over the protected channel. 273 The router SHOULD extract the certificate from the PKCS#7 certs-ony 274 message and verify that the public key corresponds to the stored 275 private key. The router SHOULD inform the operator whether it 276 successfully received the certificate and whether or not the keys 277 correspond; the mechanism is out of scope. 279 The router SHOULD also verify that the returned certificate validates 280 back to the installed TA Certificate, i.e., the entire chain from the 281 installed TA Certificate through subordinate CAs to the BGPsec 282 certificate validate. To perform this verification the CA 283 certificate chain needs to be returned along with the router's 284 certificate in the PKCS#7 certs-only message. The router SHOULD 285 inform the operator whether or not the signature validates to a trust 286 anchor; this notification mechanism is out of scope. 288 Even if the operator cannot extract the private key from the router, 289 this signature still provides a linkage between a private key and a 290 router. That is the operator can verify the proof of possession 291 (POP), as required by [RFC6484]. 293 NOTE: The signature on the PKCS#8 and Certificate need not be made by 294 the same entity. Signing the PKCS#8, permits more advanced 295 configurations where the entity that generates the keys is not the 296 direct CA. 298 8. Advanced Deployment Scenarios 300 More PKI-capable routers can take advantage of this increased 301 functionality and lighten the operator's burden. Typically, these 302 routers include either pre-installed manufacturer-generated 303 certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed 304 manufacturer-generated Pre-Shared Keys (PSK) as well as PKI- 305 enrollment functionality and transport protocol, e.g., CMC's "Secure 306 Transport" [RFC7030] or the original CMC transport protocol's 307 [RFC5273]. When the operator first establishes a protected channel 308 between the management system and the router, this pre-installed key 309 material is used to authenticate the router. 311 The operator burden shifts here to include: 313 1. Securely communicating the router's authentication material to 314 the CA prior to operator initiating the router's CSR. CAs use 315 authentication material to determine whether the router is 316 eligible to receive a certificate. Authentication material at a 317 minimum includes the router's AS number and BGP Identifier as 318 well as the router's key material, but can also include 319 additional information. Authentication material can be 320 communicated to the CA (i.e., CSRs signed by this key material 321 are issued certificates with this AS and BGP Identifier) or to 322 the router (i.e., the operator uses the vendor-supplied 323 management interface to include the AS number and BGP Identifier 324 in the router-generated CSR). 326 2. Enabling the router to communicate with the CA. While the 327 router-to-CA communications are operator-initiated, the 328 operator's management interface need not be involved in the 329 communications path. Enabling the router-to-CA connectivity MAY 330 require connections to external networks (i.e., through 331 firewalls, NATs, etc.). 333 Once configured, the operator can begin the process of enrolling the 334 router. Because the router is communicating directly with the CA, 335 there is no need for the operator to retrieve the PKCS#10 336 certification request from the router as in Section 5 or return the 337 PKCS#7 certs-only message to the router as in Section 6. Note that 338 the checks performed by the router in Section 7, namely extracting 339 the certificate from the PKCS#7 certs-only message, verifying the 340 public key corresponds to the private key, and that the returned 341 certificate validated back to an installed trust anchor, SHOULD be 342 performed. Likewise, the router SHOULD notify the operator if any of 343 these fail, but this notification mechanism is out of scope. 345 When a router is so configured the communication with the CA SHOULD 346 be automatically re-established by the router at future times to 347 renew or rekey the certificate automatically when necessary (See 348 Section 8). This further reduces the tasks required of the operator. 350 9. Key Management 352 Key management does not only include key generation, key 353 provisioning, certificate issuance, and certificate distribution. It 354 also includes assurance of key validity, key roll-over, and key 355 preservation during router replacement. All of these 356 responsibilities persist for as long as the operator wishes to 357 operate the BGPsec-speaking router. 359 9.1. Key Validity 361 It is critical that a BGPsec speaking router is signing with a valid 362 private key at all times. To this end, the operator needs to ensure 363 the router always has a non-expired certificate. I.e. the key used 364 to sign BGPsec announcements always has an associated certificate 365 whose expiry time is after the current time. 367 Ensuring this is not terribly difficult but requires that either: 369 1. The router has a mechanism to notify the operator that the 370 certificate has an impending expiration, and/or 372 2. The operator notes the expiry time of the certificate and uses a 373 calendaring program to remind them of the expiry time, and/or 375 3. The RPKI CA warns the operator of pending expiration, and/or 377 4. The operator uses some other kind of automated process to search 378 for and track the expiry times of router certificates. 380 It is advisable that expiration warnings happen well in advance of 381 the actual expiry time. 383 Regardless of the technique used to track router certificate expiry 384 times, it is advisable to notify additional operators in the same 385 organization as the expiry time approaches thereby ensuring that the 386 forgetfulness of one operator does not affect the entire 387 organization. 389 Depending on inter-operator relationship, it may be helpful to notify 390 a peer operator that one or more of their certificates are about to 391 expire. 393 9.2. Key Roll-Over 395 Routers that support multiple private keys also greatly increase the 396 chance that routers can continuously speak BGPsec because the new 397 private key and certificate can be obtained and distributed prior to 398 expiration of the operational key. Obviously, the router needs to 399 know when to start using the new key. Once the new key is being 400 used, having the already distributed certificate ensures continuous 401 operation. 403 More information on how to proceed with a Key Roll-Over is described 404 in [I-D.sidrops-bgpsec-rollover]. 406 9.3. Key Revocation 408 Certain unfortunate circumstances may occur causing a need to revoke 409 a router's BGPsec certificate. When this occurs, the operator needs 410 to use the RPKI CA system to revoke the certificate by placing the 411 router's BGPsec certificate on the Certificate Revocation List (CRL) 412 as well as re-keying the router's certificate. 414 When an active router key is to be revoked, the process of requesting 415 the CA to revoke, the process of the CA actually revoking the 416 router's certificate, and then the process of re-keying/renewing the 417 router's certificate, (possibly distributing a new key and 418 certificate to the router), and distributing the status takes time 419 during which the operator must decide how they wish to maintain 420 continuity of operations, with or without the compromised private 421 key, or whether they wish to bring the router offline to address the 422 compromise. 424 Keeping the router operational and BGPsec-speaking is the ideal goal, 425 but if operational practices do not allow this then reconfiguring the 426 router to disable BGPsec is likely preferred to bringing the router 427 offline. 429 Routers which support more than one private key, where one is 430 operational and other(s) are soon-to-be-operational, facilitate 431 revocation events because the operator can configure the router to 432 make a soon-to-be-operational key operational, request revocation of 433 the compromised key, and then make a next generation soon-to-be- 434 operational key, all hopefully without needing to take offline or 435 reboot the router. For routers which support only one operational 436 key, the operators should create or install the new private key, and 437 then request revocation of the certificate corresponding to the 438 compromised private key. 440 9.4. Router Replacement 442 Currently routers often generate private keys for uses such as SSH, 443 and the private keys may not be seen or off-loaded from the router. 444 While this is good security, it creates difficulties when a routing 445 engine or whole router must be replaced in the field and all software 446 which accesses the router must be updated with the new keys. Also, 447 any network based initial contact with a new routing engine requires 448 trust in the public key presented on first contact. 450 To allow operators to quickly replace routers without requiring 451 update and distribution of the corresponding public keys in the RPKI, 452 routers SHOULD allow the private BGPsec key to inserted via a 453 protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This 454 lets the operator escrow the old private key via the mechanism used 455 for operator-generated keys, see Section 5.2, such that it can be re- 456 inserted into a replacement router. The router MAY allow the private 457 key to be to be off-loaded via the protected channel, but this SHOULD 458 be paired with functionality that sets the key into a permanent non- 459 exportable state to ensure that it is not off-loaded at a future time 460 by unauthorized operations. 462 10. Security Considerations 464 The router's manual will describe whether the router supports one, 465 the other, or both of the key generation options discussed in the 466 earlier sections of this draft as well as other important security- 467 related information (e.g., how to SSH to the router). After 468 familiarizing one's self with the capabilities of the router, an 469 operator is encouraged to ensure that the router is patched with the 470 latest software updates available from the manufacturer. 472 This document defines no protocols so in some sense introduces no new 473 security considerations. However, it relies on many others and the 474 security considerations in the referenced documents should be 475 consulted; notably, those document listed in Section 1 should be 476 consulted first. PKI-relying protocols, of which BGPsec is one, have 477 many issues to consider so many in fact entire books have been 478 written to address them; so listing all PKI-related security 479 considerations is neither useful nor helpful; regardless, some boot- 480 strapping-related issues are listed here that are worth repeating: 482 Public-Private key pair generation: Mistakes here are for all 483 practical purposes catastrophic because PKIs rely on the pairing 484 of a difficult to generate public-private key pair with a signer; 485 all key pairs MUST be generated from a good source of non- 486 deterministic random input [RFC4086]. 488 Private key protection at rest: Mistakes here are for all practical 489 purposes catastrophic because disclosure of the private key allows 490 another entity to masquerade as (i.e., impersonate) the signer; 491 all private keys MUST be protected when at rest in a secure 492 fashion. Obviously, how each router protects private keys is 493 implementation specific. Likewise, the local storage format for 494 the private key is just that, a local matter. 496 Private key protection in transit: Mistakes here are for all 497 practical purposes catastrophic because disclosure of the private 498 key allows another entity to masquerade as (i.e., impersonate) the 499 signer; transport security is therefore strongly RECOMMENDED. The 500 level of security provided by the transport layer's security 501 mechanism SHOULD be commensurate with the strength of the BGPsec 502 key; there's no point in spending time and energy to generate an 503 excellent public-private key pair and then transmit the private 504 key in the clear or with a known-to-be-broken algorithm, as it 505 just undermines trust that the private key has been kept private. 506 Additionally, operators SHOULD ensure the transport security 507 mechanism is up to date, in order to addresses all known 508 implementation bugs. 510 SSH key management is known, in some cases, to be lax 511 [I-D.ylonen-sshkeybcp]; employees that no longer need access to a 512 routers SHOULD be removed the router to ensure only those authorized 513 have access to a router. 515 Though the CA's certificate is installed on the router and used to 516 verify that the returned certificate is in fact signed by the CA, the 517 revocation status of the CA's certificate is rarely checked as the 518 router may not have global connectivity or CRL-aware software. The 519 operator MUST ensure that the installed CA certificate is valid. 521 11. IANA Considerations 523 This document has no IANA Considerations. 525 12. References 527 12.1. Normative References 529 [I-D.sidrops-bgpsec-rollover] 530 Weis, B, R. Gagliano, and K. Patel, "BGPsec Router 531 Certificate Rollover", draft-ietf-sidrops-bgpsec- 532 rollover (work in progress), October 2017. 534 [I-D.lamps-rfc5751-bis] 535 Schaad, J., Ramsdell, B, S. Turner, 536 "Secure/Multipurpose Internet Mail Extension (S/MIME) 537 Version 4.0", draft-ietf-lamps-rfc5751- 538 bis (work in progress), April 2013. 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, DOI 542 10.17487/RFC2119, March 1997, . 545 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 546 "Randomness Requirements for Security", BCP 106, RFC 4086, 547 DOI 10.17487/RFC4086, June 2005, . 550 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 551 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 552 January 2006, . 554 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 555 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 556 10.17487/RFC4271, January 2006, . 559 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 560 RFC 5652, DOI 10.17487/RFC5652, September 2009, 561 . 563 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 564 10.17487/RFC5958, August 2010, . 567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 568 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 569 10.17487/RFC8174, May 2017, . 572 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 573 Formats, and Signature Formats", RFC 8208, DOI 574 10.17487/RFC8208, September 2017, . 577 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 578 BGPsec Router Certificates, Certificate Revocation Lists, 579 and Certification Requests", RFC 8209, DOI 580 10.17487/RFC8209, September 2017, . 583 [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and 584 metropolitan area networks - Secure Device Identity", 585 December 2009, 586 . 589 12.1. Informative References 591 [I-D.ylonen-sshkeybcp] 592 Ylonen, T. and G. Kent, "Managing SSH Keys for Automated 593 Access - Current Recommended Practice", draft-ylonen- 594 sshkeybcp (work in progress), April 2013. 596 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 597 Infrastructure Operational Protocols: FTP and HTTP", 598 RFC 2585, DOI 10.17487/RFC2585, May 1999, 599 . 601 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 602 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 603 RFC 3766, DOI 10.17487/RFC3766, April 2004, 604 . 606 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 607 (CMC): Transport Protocols", RFC 5273, DOI 608 10.17487/RFC5273, June 2008, . 611 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 612 "Elliptic Curve Cryptography Subject Public Key 613 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 614 . 616 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 617 Secure Shell Transport Layer Protocol", RFC 5647, DOI 618 10.17487/RFC5647, August 2009, . 621 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 622 Integration in the Secure Shell Transport Layer", 623 RFC 5656, DOI 10.17487/RFC5656, December 2009, 624 . 626 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 627 DOI 10.17487/RFC5967, August 2010, . 630 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 631 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 632 March 2011, . 634 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 635 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 636 February 2012, . 638 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 639 Policy (CP) for the Resource Public Key Infrastructure 640 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 641 2012, . 643 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 644 Verification for the Secure Shell (SSH) Transport Layer 645 Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, 646 . 648 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 649 "Enrollment over Secure Transport", RFC 7030, DOI 650 10.17487/RFC7030, October 2013, . 653 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 654 Specification", RFC 8205, DOI 10.17487/RFC8205, September 655 2017, . 657 [SP800-57] National Institute of Standards and Technology (NIST), 658 Special Publication 800-57: Recommendation for Key 659 Management - Part 1 (Revised), March 2007. 661 Appendix A. Management/Router Channel Security 663 Encryption, integrity, authentication, and key exchange algorithms 664 used by the protected channel SHOULD be of equal or greater strength 665 than the BGPsec keys they protect, which for the algorithm specified 666 in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57] 667 for information about this strength claim as well as [RFC3766] for 668 "how to determine the length of an asymmetric key as a function of a 669 symmetric key strength requirement." In other words, for the 670 encryption algorithm, do not use export grade crypto (40-56 bits of 671 security), do not use Triple DES (112 bits of security). Suggested 672 minimum algorithms would be AES-128: aes128-cbc [RFC4253] and 673 AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or 674 AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 675 [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for 676 key exchange. 678 Some routers support the use of public key certificates and SSH. The 679 certificates used for the SSH session are different than the 680 certificates used for BGPsec. The certificates used with SSH should 681 also enable a level of security commensurate with BGPsec keys; 682 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 683 authentication. 685 The protected channel must provide confidentiality, authentication, 686 and integrity and replay protection. 688 Appendix B. The n00b Guide to BGPsec Key Management 690 This appendix is informative. It attempts to explain all of the PKI 691 technobabble in plainer language. 693 BGPsec speakers send signed BGPsec updates that are verified by other 694 BGPsec speakers. In PKI parlance, the senders are referred to as 695 signers and the receivers are referred to as relying parties. The 696 signers with which we are concerned here are routers signing BGPsec 697 updates. Signers use private keys to sign and relying parties use 698 the corresponding public keys, in the form of X.509 public key 699 certificates, to verify signatures. The third party involved is the 700 entity that issues the X.509 public key certificate, the 701 Certification Authority (CA). Key management is all about making 702 these key pairs and the certificates, as well as ensuring that the 703 relying parties trust that the certified public keys in fact 704 correspond to the signers' private keys. 706 The specifics of key management greatly depend on the routers as well 707 as management interfaces provided by the routers' vendor. Because of 708 these differences, it is hard to write a definitive "how to," but 709 this guide is intended to arm operators with enough information to 710 ask the right questions. The other aspect that makes this guide 711 informative is that the steps for the do-it-yourself (DIY) approach 712 involve arcane commands while the GUI-based vendor-assisted 713 management console approach will likely hide all of those commands 714 behind some button clicks. Regardless, the operator will end up with 715 a BGPsec-enabled router. Initially, we focus on the DIY approach and 716 then follow up with some information about the GUI-based approach. 718 The first step in the DIY approach is to generate a private key; but 719 in fact what you do is create a key pair; one part, the private key, 720 is kept very private and the other part, the public key, is given out 721 to verify whatever is signed. The two models for how to create the 722 key pair are the subject of this document, but it boils down to 723 either doing it on-router (router-driven) or off-router (operator- 724 driven). 726 If you are generating keys on the router (router-driven), then you 727 will need to access the router. Again, how you access the router is 728 router-specific, but generally the DIY approach uses the CLI and 729 accessing the router either directly via the router's craft port or 730 over the network on an administrative interface. If accessing the 731 router over the network be sure to do it securely (i.e., use SSHv2). 732 Once logged into the router, issue a command or a series of commands 733 that will generate the key pair for the algorithms referenced in the 734 main body of this document; consult your router's documentation for 735 the specific commands. The key generation process will yield 736 multiple files: the private key and the public key; the file format 737 varies depending on the arcane command you issued, but generally the 738 files are DER or PEM-encoded. 740 The second step is to generate the certification request, which is 741 often referred to as a certificate signing request (CSR) or PKCS#10 742 certification request, and to send it to the CA to be signed. To 743 generate the CSR, you issue some more arcane commands while logged 744 into the router; using the private key just generated to sign the 745 certification request with the algorithms referenced in the main body 746 of this document; the CSR is signed to prove to the CA that the 747 router has possession of the private key (i.e., the signature is the 748 proof-of-possession). The output of the command is the CSR file; the 749 file format varies depending on the arcane command you issued, but 750 generally the files are DER or PEM-encoded. 752 The third step is to retrieve the signed CSR from the router and send 753 it to the CA. But before sending it, you need to also send the CA 754 the subject name and serial number for the router. The CA needs this 755 information to issue the certificate. How you get the CSR to the CA, 756 is beyond the scope of this document. While you are still connected 757 to the router, install the Trust Anchor (TA) for the root of the PKI. 758 At this point, you no longer need access to the router for BGPsec- 759 related initiation purposes. 761 The fourth step is for the CA to issue the certificate based on the 762 CSR you sent; the certificate will include the subject name, serial 763 number, public key, and other fields as well as being signed by the 764 CA. After the CA issues the certificate, the CA returns the 765 certificate, and posts the certificate to the RPKI repository. Check 766 that the certificate corresponds to the private key by verifying the 767 signature on the CSR sent to the CA; this is just a check to make 768 sure that the CA issued a certificate corresponding to the private 769 key on the router. 771 If generating the keys off-router (operator-driven), then the same 772 steps are used as the on-router key generation, (possibly with the 773 same arcane commands as those used in the on-router approach), but no 774 access to the router is needed the first three steps are done on an 775 administrative workstation: o Step 1: Generate key pair; o Step 2: 776 Create CSR and sign CSR with private key, and; o Step 3: Send CSR 777 file with the subject name and serial number to CA. 779 After the CA has returned the certificate and you have checked the 780 certificate, you need to put the private key and TA in the router. 781 Assuming the DIY approach, you will be using the CLI and accessing 782 the router either directly via the router's craft port or over the 783 network on an admin interface; if accessing the router over the 784 network make doubly sure it is done securely (i.e., use SSHv2) 785 because the private key is being moved over the network. At this 786 point, access to the router is no longer needed for BGPsec-related 787 initiation purposes. 789 NOTE: Regardless of the approach taken, the first three steps could 790 trivially be collapsed by a vendor-provided script to yield the 791 private key and the signed CSR. 793 Given a GUI-based vendor-assisted management console, then all of 794 these steps will likely be hidden behind pointing and clicking the 795 way through BGPsec-enabling the router. 797 The scenarios described above require the operator to access each 798 router, which does not scale well to large networks. An alternative 799 would be to create an image, perform the necessary steps to get the 800 private key and trust anchor on the image, and then install the image 801 via a management protocol. 803 One final word of advice; certificates include a notAfter field that 804 unsurprisingly indicates when relying parties should no longer trust 805 the certificate. To avoid having routers with expired certificates 806 follow the recommendations in the Certification Policy (CP) [RFC6484] 807 and make sure to renew the certificate at least one week prior to the 808 notAfter date. Set a calendar reminder in order not to forget! 810 Authors' Addresses 812 Randy Bush 813 IIJ / Dragon Research Labs 814 5147 Crystal Springs 815 Bainbridge Island, Washington 98110 816 US 818 Email: randy@psg.com 820 Sean Turner 821 sn3rd 823 Email: sean@sn3rd.com 825 Keyur Patel 826 Arrcus, Inc. 828 Email: keyur@arrcus.com