idnits 2.17.1 draft-ietf-sidrops-rtr-keying-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 : ---------------------------------------------------------------------------- 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 (January 16, 2019) is 1927 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: Best Current Practice S. Turner 5 Expires: July 20, 2019 sn3rd 6 K. Patel 7 Arrcus, Inc. 8 January 16, 2019 10 Router Keying for BGPsec 11 draft-ietf-sidrops-rtr-keying-03 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) 2019 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 . . . . . . . . . . . . . . . . . . . . . 12 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 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 methods, router- 97 driven and operator-driven. 99 These two methods differ in where the keys are generated: on the 100 router in the router-driven method, and elsewhere in the 101 operator-driven method. Routers are required to support at least one 102 of the methods in order to work in various deployment environments. 103 Some routers may not allow the private key to be off-loaded while 104 others may. While off-loading private keys would ease swapping of 105 routing engines, exposure of private keys is a well known security 106 risk. 108 In the operator-driven method, the operator generates the 109 private/public key-pair and sends it to the router. 111 In the router-driven method, the router generates its own 112 public/private key-pair. 114 The router-driven method mirrors the model used by traditional PKI 115 subscribers; the private key never leaves trusted storage (e.g., 116 Hardware Security Module). This is by design and supports classic 117 PKI Certification Policies for (often human) subscribers which 118 require the private key only ever be controlled by the subscriber to 119 ensure that no one can impersonate the subscriber. For non-humans, 120 this method does not always work. For example, when an operator 121 wants to support hot-swappable routers, the same private key needs to 122 be installed in the soon-to-be online router that was used by the the 123 soon-to-be offline router. This motivated the operator-driven 124 method. 126 Sections 2 through 7 describe the various steps involved for an 127 operator to use the two methods to provision new and existing 128 routers. The methods described involve the operator configuring the 129 two end points (i.e., the management station and the router) and 130 acting as the intermediary. Section 8 describes another method that 131 requires more capable routers. 133 Useful References: [RFC8205] describes gritty details, [RFC8209] 134 specifies the format for the PKCS#10 certification request, and 135 [RFC8208] specifies the algorithms used to generate the PKCS#10's 136 signature. 138 2. Management / Router Communication 140 Operators are free to use either the router-driven or operator-driven 141 method as supported by the platform. Regardless of the method 142 chosen, operators first establish a protected channel between the 143 management system and the router. How this protected channel is 144 established is router-specific and is beyond scope of this document. 145 Though other configuration mechanisms might be used, e.g. NetConf 146 (see [RFC6470]), the protected the protected channel between the 147 management platform and the router is assumed to be an SSH-protected 148 CLI. See Appendix A for security considerations for this protected 149 channel. 151 3. Exchange Certificates 153 A number of options exist for the operator management station to 154 exchange PKI-related information with routers and with the RPKI 155 including: 157 - Using application/pkcs10 media type [RFC5967] to extract 158 certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- 159 bis] to return the issued certificate, 161 - Using FTP or HTTP per [RFC2585], and 163 - Using Enrollment over Secure Transport (EST) protocol per 164 [RFC7030]. 166 4. Set-Up 168 To start, the operator uses the protected channel to install the 169 appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. 170 This will later enable the router to validate the router certificate 171 returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. 173 The operator also configures the Autonomous System (AS) number to be 174 used in the generated router certificate. This may be the sole AS 175 configured on the router, or an operator choice if the router is 176 configured with multiple ASs. A router with multiple ASs can be 177 configured with multiple router certificates by following the process 178 of this document for each desired certificate. 180 The operator configures or extracts from the router the BGP 181 Identifier [RFC4271] to be used in the generated router certificate. 182 In the case where the operator has chosen not to use unique 183 per-router certificates, a BGP Identifier of 0 MAY be used. 185 5. Generate PKCS#10 187 The private key, and hence the PKCS#10 certification request, which 188 is sometimes referred to as a Certificate Signing Request (CSR), may 189 be generated by the router or by the operator. 191 The PKCS#10 request SHOULD be saved to enable verifying that the 192 returned public key in the certificate corresponds to the private 193 used to generate the signature on the CSR. 195 NOTE: The PKCS#10 certification request does not include the AS 196 number or the BGP Identifier for the router certificate. Therefore, 197 the operator transmits the AS it has chosen on the router and the BGP 198 Identifier as well when it sends the CSR to the CA. 200 5.1. Router-Generated Keys 202 In the router-generated method, once the protected channel is 203 established and the initial Set-Up (Section 4) performed, the 204 operator issues a command or commands for the router to generate the 205 public/private key pair, to generate the PKCS#10 certification 206 request, and to sign the PKCS#10 certification request with the 207 private key. Once the router has generated the PKCS#10 certification 208 request, it returns it to the operator over the protected channel. 210 The operator includes the chosen AS number and the BGP Identifier 211 when it sends the CSR to the CA. 213 NOTE: If a router were to communicate directly with a CA to have the 214 CA certify the PKCS#10 certification request, there would be no way 215 for the CA to authenticate the router. As the operator knows the 216 authenticity of the router, the operator mediates the communication 217 with the CA. 219 5.2. Operator-Generated Keys 221 In the operator-generated method, the operator generates the 222 public/private key pair on a management station and installs the 223 private key into the router over the protected channel. Beware that 224 experience has shown that copy-and-paste from a management station to 225 a router can be unreliable for long texts. 227 The operator then creates and signs the PKCS#10 certification request 228 with the private key; the operator includes the chosen AS number and 229 the BGP Identifier when it sends the CSR to the CA. 231 Even if the operator cannot extract the private key from the router, 232 this signature still provides a linkage between a private key and a 233 router. That is, the operator can verify the proof of possession 234 (POP), as required by [RFC6484]. 236 5.2.1. Using PKCS#8 to Transfer Private Key 238 A private key can be encapsulated in a PKCS#8 Asymmetric Key Package 240 [RFC5958] and should be further encapsulated in Cryptographic Message 241 Syntax (CMS) SignedData [RFC5652] and signed with the operators's End 242 Entity (EE) private key. 244 The router SHOULD verify the signature of the encapsulated PKCS#8 to 245 ensure the returned private key did in fact come from the operator, 246 but this requires that the operator also provision via the CLI or 247 include in the SignedData the RPKI CA certificate and relevant 248 operator's EE certificate(s). The router should inform the operator 249 whether or not the signature validates to a trust anchor; this 250 notification mechanism is out of scope. 252 6. Send PKCS#10 and Receive PKCS#7 254 The operator uses RPKI management tools to communicate with the 255 global RPKI system to have the appropriate CA validate the PKCS#10 256 certification request, sign the key in the PKCS#10 (i.e., certify it) 257 and generate a PKCS#7 certs-only message, as well as publishing the 258 certificate in the Global RPKI. External network connectivity may be 259 needed if the certificate is to be published in the Global RPKI. 261 After the CA certifies the key, it does two things: 263 1. Publishes the certificate in the Global RPKI. The CA must have 264 connectivity to the relevant publication point, which in turn 265 must have external network connectivity as it is part of the 266 Global RPKI. 268 2. Returns the certificate to the operator's management station, 269 packaged in a PKCS#7 certs-only message, using the corresponding 270 method by which it received the certificate request. It SHOULD 271 include the certificate chain below the TA Certificate so that 272 the router can validate the router certificate. 274 In the operator-generated method, the operator SHOULD extract the 275 certificate from the PKCS#7 certs-only message, and verify that the 276 private key it holds corresponds to the returned public key. If the 277 operator saved the PKCS#10 it can check this correspondence by 278 comparing the public key in the CSR to the public key in the returned 279 certificate. If the operator has not saved the PKCS#10, it can check 280 this correspondence by generating a signature on any data and then 281 verifying the signature using the returned certificate. 283 In the operator-generated method, the operator has already installed 284 the private key in the router (see Section 5.2). 286 7. Install Certificate 287 The operator provisions the PKCS#7 certs-only message into the router 288 over the protected channel. 290 The router SHOULD extract the certificate from the PKCS#7 certs-only 291 message and verify that the public key corresponds to the stored 292 private key. If the router stored the PKCS#10, it can check this 293 correspondence by comparing the public key in the CSR to the public 294 key in the returned certificate. If the router did not store the 295 PKCS#10, it can check this correspondence by generating a signature 296 on any data and then verifying the signature using the returned 297 certificate. The router SHOULD inform the operator whether it 298 successfully received the certificate and whether or not the keys 299 correspond; the mechanism is out of scope. 301 The router SHOULD also verify that the returned certificate validates 302 back to the installed TA Certificate, i.e., the entire chain from the 303 installed TA Certificate through subordinate CAs to the BGPsec 304 certificate validate. To perform this verification, the CA 305 certificate chain needs to be returned along with the router's 306 certificate in the PKCS#7 certs-only message. The router SHOULD 307 inform the operator whether or not the signature validates to a trust 308 anchor; this notification mechanism is out of scope. 310 NOTE: The signature on the PKCS#8 and Certificate need not be made by 311 the same entity. Signing the PKCS#8 permits more advanced 312 configurations where the entity that generates the keys is not the 313 direct CA. 315 8. Advanced Deployment Scenarios 317 More PKI-capable routers can take advantage of this increased 318 functionality and lighten the operator's burden. Typically, these 319 routers include either pre-installed manufacturer-generated 320 certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed 321 manufacturer-generated Pre-Shared Keys (PSK) as well as 322 PKI-enrollment functionality and transport protocol, e.g., CMC's 323 "Secure Transport" [RFC7030] or the original CMC transport protocol's 324 [RFC5273]. When the operator first establishes a protected channel 325 between the management system and the router, this pre-installed key 326 material is used to authenticate the router. 328 The operator's burden shifts here to include: 330 1. Securely communicating the router's authentication material to 331 the CA prior to operator initiating the router's CSR. CAs use 332 authentication material to determine whether the router is 333 eligible to receive a certificate. Authentication material at a 334 minimum includes the router's AS number and BGP Identifier as 335 well as the router's key material, but can also include 336 additional information. Authentication material can be 337 communicated to the CA (i.e., CSRs signed by this key material 338 are issued certificates with this AS and BGP Identifier) or to 339 the router (i.e., the operator uses the vendor-supplied 340 management interface to include the AS number and BGP Identifier 341 in the router-generated CSR). 343 2. Enabling the router to communicate with the CA. While the 344 router-to-CA communications are operator-initiated, the 345 operator's management interface need not be involved in the 346 communications path. Enabling the router-to-CA connectivity MAY 347 require connections to external networks (i.e., through 348 firewalls, NATs, etc.). 350 Once configured, the operator can begin the process of enrolling the 351 router. Because the router is communicating directly with the CA, 352 there is no need for the operator to retrieve the PKCS#10 353 certification request from the router as in Section 5 or return the 354 PKCS#7 certs-only message to the router as in Section 6. Note that 355 the checks performed by the router in Section 7, namely extracting 356 the certificate from the PKCS#7 certs-only message, verifying the 357 public key corresponds to the private key, and that the returned 358 certificate validated back to an installed trust anchor, SHOULD be 359 performed. Likewise, the router SHOULD notify the operator if any of 360 these fail, but this notification mechanism is out of scope. 362 When a router is so configured, the communication with the CA SHOULD 363 be automatically re-established by the router at future times to 364 renew or rekey the certificate automatically when necessary (See 365 Section 9). This further reduces the tasks required of the operator. 367 9. Key Management 369 Key management does not only include key generation, key 370 provisioning, certificate issuance, and certificate distribution. It 371 also includes assurance of key validity, key roll-over, and key 372 preservation during router replacement. All of these 373 responsibilities persist for as long as the operator wishes to 374 operate the BGPsec-speaking router. 376 9.1. Key Validity 378 It is critical that a BGPsec-speaking router is signing with a valid 379 private key at all times. To this end, the operator needs to ensure 380 the router always has a non-expired certificate. I.e. the key used 381 to sign BGPsec announcements always has an associated certificate 382 whose expiry time is after the current time. 384 Ensuring this is not terribly difficult but requires that either: 386 1. The router have a mechanism to notify the operator that the 387 certificate has an impending expiration, and/or 389 2. The operator note the expiry time of the certificate and uses a 390 calendaring program to remind them of the expiry time, and/or 392 3. The RPKI CA warn the operator of pending expiration, and/or 394 4. The operator use some other kind of automated process to search 395 for and track the expiry times of router certificates. 397 It is advisable that expiration warnings happen well in advance of 398 the actual expiry time. 400 Regardless of the technique used to track router certificate expiry 401 times, it is advisable to notify additional operators in the same 402 organization as the expiry time approaches, thereby ensuring that the 403 forgetfulness of one operator does not affect the entire 404 organization. 406 Depending on inter-operator relationship, it may be helpful to notify 407 a peer operator that one or more of their certificates are about to 408 expire. 410 9.2. Key Roll-Over 412 Routers that support multiple private keys also greatly increase the 413 chance that routers can continuously speak BGPsec because the new 414 private key and certificate can be obtained and distributed prior to 415 expiration of the operational key. Obviously, the router needs to 416 know when to start using the new key. Once the new key is being 417 used, having the already distributed certificate ensures continuous 418 operation. 420 More information on how to proceed with a Key Roll-Over is described 421 in [I-D.sidrops-bgpsec-rollover]. 423 9.3. Key Revocation 425 In certain circumstances, a router's BGPsec certificate may need to 426 be revoked. When this occurs, the operator needs to use the RPKI CA 427 system to revoke the certificate by placing the router's BGPsec 428 certificate on the Certificate Revocation List (CRL) as well as 429 re-keying the router's certificate. 431 When an active router key is to be revoked, the process of requesting 432 the CA to revoke, the process of the CA actually revoking the 433 router's certificate, and then the process of re-keying/renewing the 434 router's certificate, (possibly distributing a new key and 435 certificate to the router), and distributing the status, takes time 436 during which the operator must decide how they wish to maintain 437 continuity of operations, with or without the compromised private 438 key, or whether they wish to bring the router offline to address the 439 compromise. 441 Keeping the router operational and BGPsec-speaking is the ideal goal; 442 but, if operational practices do not allow this, then reconfiguring 443 the router to disable BGPsec is likely preferred to bringing the 444 router offline. 446 Routers which support more than one private key, where one is 447 operational and other(s) are soon-to-be-operational, facilitate 448 revocation events because the operator can configure the router to 449 make a soon-to-be-operational key operational, request revocation of 450 the compromised key, and then make a next generation 451 soon-to-be-operational key. Hopefully, all this can be done without 452 needing to take offline or reboot the router. For routers which 453 support only one operational key, the operators should create or 454 install the new private key, and then request revocation of the 455 certificate corresponding to the compromised private key. 457 9.4. Router Replacement 459 Currently routers often generate private keys for uses such as SSH, 460 and the private keys may not be seen or off-loaded from the router. 461 While this is good security, it creates difficulties when a routing 462 engine or whole router must be replaced in the field and all software 463 which accesses the router must be updated with the new keys. Also, 464 any network based initial contact with a new routing engine requires 465 trust in the public key presented on first contact. 467 To allow operators to quickly replace routers without requiring 468 update and distribution of the corresponding public keys in the RPKI, 469 routers SHOULD allow the private BGPsec key to be inserted via a 470 protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This 471 lets the operator escrow the old private key via the mechanism used 472 for operator-generated keys, see Section 5.2, such that it can be re- 473 inserted into a replacement router. The router MAY allow the private 474 key to be to be off-loaded via the protected channel, but this SHOULD 475 be paired with functionality that sets the key into a permanent non- 476 exportable state to ensure that it is not off-loaded at a future time 477 by unauthorized operations. 479 10. Security Considerations 480 The router's manual will describe whether the router supports one, 481 the other, or both of the key generation options discussed in the 482 earlier sections of this draft as well as other important security- 483 related information (e.g., how to SSH to the router). After 484 familiarizing one's self with the capabilities of the router, an 485 operator is encouraged to ensure that the router is patched with the 486 latest software updates available from the manufacturer. 488 This document defines no protocols. So, in some sense, it introduces 489 no new security considerations. However, it relies on many others 490 and the security considerations in the referenced documents should be 491 consulted; notably, those document listed in Section 1 should be 492 consulted first. PKI-relying protocols, of which BGPsec is one, have 493 many issues to consider - so many, in fact, entire books have been 494 written to address them; so listing all PKI-related security 495 considerations is neither useful nor helpful. Regardless, some boot- 496 strapping-related issues are listed here that are worth repeating: 498 Public-Private key pair generation: Mistakes here are, for all, 499 practical purposes catastrophic because PKIs rely on the pairing 500 of a difficult to generate public-private key pair with a signer; 501 all key pairs MUST be generated from a good source of non- 502 deterministic random input [RFC4086]. 504 Private key protection at rest: Mistakes here are, for all, practical 505 purposes catastrophic because disclosure of the private key allows 506 another entity to masquerade as (i.e., impersonate) the signer; 507 all private keys MUST be protected when at rest in a secure 508 fashion. Obviously, how each router protects private keys is 509 implementation specific. Likewise, the local storage format for 510 the private key is just that, a local matter. 512 Private key protection in transit: Mistakes here are, for all, 513 practical purposes catastrophic because disclosure of the private 514 key allows another entity to masquerade as (i.e., impersonate) the 515 signer; transport security is therefore strongly RECOMMENDED. The 516 level of security provided by the transport layer's security 517 mechanism SHOULD be commensurate with the strength of the BGPsec 518 key; there's no point in spending time and energy to generate an 519 excellent public-private key pair and then transmit the private 520 key in the clear or with a known-to-be-broken algorithm, as it 521 just undermines trust that the private key has been kept private. 522 Additionally, operators SHOULD ensure the transport security 523 mechanism is up to date, in order to addresses all known 524 implementation bugs. 526 Though the CA's certificate is installed on the router and used to 527 verify that the returned certificate is in fact signed by the CA, the 528 revocation status of the CA's certificate is rarely checked as the 529 router may not have global connectivity or CRL-aware software. The 530 operator MUST ensure that the installed CA certificate is valid. 532 11. IANA Considerations 534 This document has no IANA Considerations. 536 12. References 538 12.1. Normative References 540 [I-D.sidrops-bgpsec-rollover] 541 Weis, B, R. Gagliano, and K. Patel, "BGPsec Router 542 Certificate Rollover", draft-ietf-sidrops-bgpsec- 543 rollover (work in progress), December 2017. 545 [I-D.lamps-rfc5751-bis] 546 Schaad, J., Ramsdell, B, S. Turner, 547 "Secure/Multipurpose Internet Mail Extension (S/MIME) 548 Version 4.0", draft-ietf-lamps-rfc5751- 549 bis (work in progress), July 2018. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, DOI 553 10.17487/RFC2119, March 1997, . 556 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 557 "Randomness Requirements for Security", BCP 106, RFC 4086, 558 DOI 10.17487/RFC4086, June 2005, . 561 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 562 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 563 January 2006, . 565 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 566 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 567 10.17487/RFC4271, January 2006, . 570 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 571 RFC 5652, DOI 10.17487/RFC5652, September 2009, 572 . 574 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 575 10.17487/RFC5958, August 2010, . 578 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 579 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 580 10.17487/RFC8174, May 2017, . 583 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 584 Formats, and Signature Formats", RFC 8208, DOI 585 10.17487/RFC8208, September 2017, . 588 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 589 BGPsec Router Certificates, Certificate Revocation Lists, 590 and Certification Requests", RFC 8209, DOI 591 10.17487/RFC8209, September 2017, . 594 [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and 595 metropolitan area networks - Secure Device Identity", 596 December 2009, 597 . 600 12.1. Informative References 602 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 603 Infrastructure Operational Protocols: FTP and HTTP", 604 RFC 2585, DOI 10.17487/RFC2585, May 1999, 605 . 607 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 608 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 609 RFC 3766, DOI 10.17487/RFC3766, April 2004, 610 . 612 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 613 (CMC): Transport Protocols", RFC 5273, DOI 614 10.17487/RFC5273, June 2008, . 617 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 618 "Elliptic Curve Cryptography Subject Public Key 619 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 620 . 622 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 623 Secure Shell Transport Layer Protocol", RFC 5647, DOI 624 10.17487/RFC5647, August 2009, . 627 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 628 Integration in the Secure Shell Transport Layer", 629 RFC 5656, DOI 10.17487/RFC5656, December 2009, 630 . 632 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 633 DOI 10.17487/RFC5967, August 2010, . 636 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 637 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 638 March 2011, . 640 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 641 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 642 February 2012, . 644 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 645 Policy (CP) for the Resource Public Key Infrastructure 646 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 647 2012, . 649 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 650 Verification for the Secure Shell (SSH) Transport Layer 651 Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, 652 . 654 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 655 "Enrollment over Secure Transport", RFC 7030, DOI 656 10.17487/RFC7030, October 2013, . 659 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 660 Specification", RFC 8205, DOI 10.17487/RFC8205, September 661 2017, . 663 [SP800-57] National Institute of Standards and Technology (NIST), 664 Special Publication 800-57: Recommendation for Key 665 Management - Part 1 (Revised), March 2007. 667 Appendix A. Management/Router Channel Security 669 Encryption, integrity, authentication, and key exchange algorithms 670 used by the protected channel SHOULD be of equal or greater strength 671 than the BGPsec keys they protect, which for the algorithm specified 672 in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57] 673 for information about this strength claim as well as [RFC3766] for 674 "how to determine the length of an asymmetric key as a function of a 675 symmetric key strength requirement." In other words, for the 676 encryption algorithm, do not use export grade crypto (40-56 bits of 677 security), do not use Triple DES (112 bits of security). Suggested 678 minimum algorithms would be AES-128: aes128-cbc [RFC4253] and 679 AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or 680 AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 681 [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for 682 key exchange. 684 Some routers support the use of public key certificates and SSH. The 685 certificates used for the SSH session are different than the 686 certificates used for BGPsec. The certificates used with SSH should 687 also enable a level of security commensurate with BGPsec keys; 688 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 689 authentication. 691 The protected channel must provide confidentiality, authentication, 692 and integrity and replay protection. 694 Appendix B. The n00b Guide to BGPsec Key Management 696 This appendix is informative. It attempts to explain all of the PKI 697 technobabble in plainer language. 699 BGPsec speakers send signed BGPsec updates that are verified by other 700 BGPsec speakers. In PKI parlance, the senders are referred to as 701 signers and the receivers are referred to as relying parties. The 702 signers with which we are concerned here are routers signing BGPsec 703 updates. Signers use private keys to sign and relying parties use 704 the corresponding public keys, in the form of X.509 public key 705 certificates, to verify signatures. The third party involved is the 706 entity that issues the X.509 public key certificate, the 707 Certification Authority (CA). Key management is all about making 708 these key pairs and the certificates, as well as ensuring that the 709 relying parties trust that the certified public keys in fact 710 correspond to the signers' private keys. 712 The specifics of key management greatly depend on the routers as well 713 as management interfaces provided by the routers' vendor. Because of 714 these differences, it is hard to write a definitive "how to," but 715 this guide is intended to arm operators with enough information to 716 ask the right questions. The other aspect that makes this guide 717 informative is that the steps for the do-it-yourself (DIY) approach 718 involve arcane commands while the GUI-based vendor-assisted 719 management console approach will likely hide all of those commands 720 behind some button clicks. Regardless, the operator will end up with 721 a BGPsec-enabled router. Initially, we focus on the DIY approach and 722 then follow up with some information about the GUI-based approach. 724 The first step in the DIY approach is to generate a private key; but 725 in fact what you do is create a key pair; one part, the private key, 726 is kept very private and the other part, the public key, is given out 727 to verify whatever is signed. The two methods for how to create the 728 key pair are the subject of this document, but it boils down to 729 either doing it on-router (router-driven) or off-router (operator- 730 driven). 732 If you are generating keys on the router (router-driven), then you 733 will need to access the router. Again, how you access the router is 734 router-specific, but generally the DIY approach uses the CLI and 735 accessing the router either directly via the router's craft port or 736 over the network on an administrative interface. If accessing the 737 router over the network be sure to do it securely (i.e., use SSHv2). 738 Once logged into the router, issue a command or a series of commands 739 that will generate the key pair for the algorithms referenced in the 740 main body of this document; consult your router's documentation for 741 the specific commands. The key generation process will yield 742 multiple files: the private key and the public key; the file format 743 varies depending on the arcane command you issued, but generally the 744 files are DER or PEM-encoded. 746 The second step is to generate the certification request, which is 747 often referred to as a certificate signing request (CSR) or PKCS#10 748 certification request, and to send it to the CA to be signed. To 749 generate the CSR, you issue some more arcane commands while logged 750 into the router; using the private key just generated to sign the 751 certification request with the algorithms referenced in the main body 752 of this document; the CSR is signed to prove to the CA that the 753 router has possession of the private key (i.e., the signature is the 754 proof-of-possession). The output of the command is the CSR file; the 755 file format varies depending on the arcane command you issued, but 756 generally the files are DER or PEM-encoded. 758 The third step is to retrieve the signed CSR from the router and send 759 it to the CA. But before sending it, you need to also send the CA 760 the subject name (i.e., "ROUTER-" followed by the AS number) and 761 serial number (i.e., the 32-bit BGP Identifier) for the router. The 762 CA needs this information to issue the certificate. How you get the 763 CSR to the CA, is beyond the scope of this document. While you are 764 still connected to the router, install the Trust Anchor (TA) for the 765 root of the PKI. At this point, you no longer need access to the 766 router for BGPsec-related initiation purposes. 768 The fourth step is for the CA to issue the certificate based on the 769 CSR you sent; the certificate will include the subject name, serial 770 number, public key, and other fields as well as being signed by the 771 CA. After the CA issues the certificate, the CA returns the 772 certificate, and posts the certificate to the RPKI repository. Check 773 that the certificate corresponds to the private key by verifying the 774 signature on the CSR sent to the CA; this is just a check to make 775 sure that the CA issued a certificate that includes a public key that 776 is the pair of the private key (i.e., the math will work when 777 verifying a signature generated by the private with the returned 778 certificate). 780 If generating the keys off-router (operator-driven), then the same 781 steps are used as the on-router key generation, (possibly with the 782 same arcane commands as those used in the on-router approach), but no 783 access to the router is needed the first three steps are done on an 784 administrative workstation: o Step 1: Generate key pair; o Step 2: 785 Create CSR and sign CSR with private key, and; o Step 3: Send CSR 786 file with the subject name and serial number to CA. 788 After the CA has returned the certificate and you have checked the 789 certificate, you need to put the private key and TA in the router. 790 Assuming the DIY approach, you will be using the CLI and accessing 791 the router either directly via the router's craft port or over the 792 network on an admin interface; if accessing the router over the 793 network make doubly sure it is done securely (i.e., use SSHv2) 794 because the private key is being moved over the network. At this 795 point, access to the router is no longer needed for BGPsec-related 796 initiation purposes. 798 NOTE: Regardless of the approach taken, the first three steps could 799 trivially be collapsed by a vendor-provided script to yield the 800 private key and the signed CSR. 802 Given a GUI-based vendor-assisted management console, then all of 803 these steps will likely be hidden behind pointing and clicking the 804 way through BGPsec-enabling the router. 806 The scenarios described above require the operator to access each 807 router, which does not scale well to large networks. An alternative 808 would be to create an image, perform the necessary steps to get the 809 private key and trust anchor on the image, and then install the image 810 via a management protocol. 812 One final word of advice; certificates include a notAfter field that 813 unsurprisingly indicates when relying parties should no longer trust 814 the certificate. To avoid having routers with expired certificates 815 follow the recommendations in the Certification Policy (CP) [RFC6484] 816 and make sure to renew the certificate at least one week prior to the 817 notAfter date. Set a calendar reminder in order not to forget! 819 Authors' Addresses 821 Randy Bush 822 IIJ / Dragon Research Labs 823 5147 Crystal Springs 824 Bainbridge Island, Washington 98110 825 US 827 Email: randy@psg.com 829 Sean Turner 830 sn3rd 832 Email: sean@sn3rd.com 834 Keyur Patel 835 Arrcus, Inc. 837 Email: keyur@arrcus.com