idnits 2.17.00 (12 Aug 2021) /tmp/idnits29394/draft-ietf-sidrops-rtr-keying-04.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 (February 27, 2019) is 1178 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) == Outdated reference: draft-ietf-sidrops-bgpsec-rollover has been published as RFC 8634 == Outdated reference: draft-ietf-lamps-rfc5751-bis has been published as RFC 8551 ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: August 31, 2019 sn3rd 6 K. Patel 7 Arrcus, Inc. 8 February 27, 2019 10 Router Keying for BGPsec 11 draft-ietf-sidrops-rtr-keying-04 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 . . . . . . . . . . . . . . 4 66 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 67 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 70 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6 71 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6 72 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7 73 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7 74 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8 75 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 78 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10 79 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 12.1. Informative References . . . . . . . . . . . . . . . . . 14 85 Appendix A. Management/Router Channel Security . . . . . . . . . 15 86 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 exported while 104 others may. While exporting 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. The operator-driven model is 121 motivated by the extreme importance placed on ensuring the continued 122 operation of the network. In some deployments, the same private key 123 needs to be installed in the soon-to-be online router that was used 124 by the soon-to-be offline router, since this "hot-swapping" behavior 125 can result in minimal downtime, especially compared with the normal 126 RPKI procedures to propagate a new key, which can take a day or 127 longer to converge. 129 For example, when an operator wants to support hot-swappable routers, 130 the same private key needs to be installed in the soon-to-be online 131 router that was used by the soon-to-be offline router. This 132 motivated the operator-driven method. 134 Sections 2 through 7 describe the various steps involved for an 135 operator to use the two methods to provision new and existing 136 routers. The methods described involve the operator configuring the 137 two end points (i.e., the management station and the router) and 138 acting as the intermediary. Section 8 describes another method that 139 requires more capable routers. 141 Useful References: [RFC8205] describes details of BGPsec, [RFC8209] 142 specifies the format for the PKCS#10 certification request, and 143 [RFC8208] specifies the algorithms used to generate the PKCS#10 144 signature. 146 2. Management / Router Communication 148 Operators are free to use either the router-driven or operator-driven 149 method as supported by the platform. Prudent security practice 150 recommends router-generated keying, if the delay in replacing a 151 router (or router engine) is acceptable to the operator. Regardless 152 of the method chosen, operators first establish a protected channel 153 between the management system and the router; this protected channel 154 prevents eavesdropping, tampering, and message forgery as well as 155 provides mutual authentication. How this protected channel is 156 established is router-specific and is beyond scope of this document. 157 Though other configuration mechanisms might be used, e.g. NETCONF 158 (see [RFC6470]), the protected channel used between the management 159 platform and the router is assumed to be an SSH-protected CLI. See 160 Appendix A for security considerations for this protected channel. 162 The previous paragraph assumes the management system-to-router 163 communications are over a network. When the management system has a 164 direct physical connection to the router, e.g., via the craft port, 165 there is no assumption that there is a protected channel between the 166 two. 168 3. Exchange Certificates 170 A number of options exist for the operator management station to 171 exchange PKI-related information with routers and with the RPKI 172 including: 174 - Using application/pkcs10 media type [RFC5967] to extract 175 certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- 176 bis] to return the issued certificate, 178 - Using FTP or HTTP per [RFC2585], and 180 - Using Enrollment over Secure Transport (EST) protocol per 181 [RFC7030]. 183 Despite the fact that Certificates are integrity-protected and do not 184 necessarily need additional protection, transports that also provide 185 integrity protection are RECOMMENDED. 187 4. Set-Up 189 To start, the operator uses the protected channel to install the 190 appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. 191 This will later enable the router to validate the router certificate 192 returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. 194 The operator configures the Autonomous System (AS) number to be used 195 in the generated router certificate. This may be the sole AS 196 configured on the router, or an operator choice if the router is 197 configured with multiple ASs. A router with multiple ASs can be 198 configured with multiple router certificates by following the process 199 of this document for each desired certificate. This configured AS 200 number is also used during verification of keys, if generated by the 201 operator (see Section 5.2), as well as during certificate 202 verification steps (see Sections 6, 7, and 8). 204 The operator configures or extracts from the router the BGP 205 Identifier [RFC6286] to be used in the generated router certificate. 206 In the case where the operator has chosen not to use unique 207 per-router certificates, a BGP Identifier of 0 MAY be used. 209 The operator configures the router's access control mechanism to 210 ensure that only authorized users are able to later access the 211 router's configuration. 213 5. Generate PKCS#10 215 The private key, and hence the PKCS#10 certification request, which 216 is sometimes referred to as a Certificate Signing Request (CSR), may 217 be generated by the router or by the operator. 219 Retaining the CSR allows for verifying that the returned public key 220 in the certificate corresponds to the private key used to generate 221 the signature on the CSR. 223 NOTE: The PKCS#10 certification request does not include the AS 224 number or the BGP Identifier for the router certificate. Therefore, 225 the operator transmits the AS it has chosen on the router and the BGP 226 Identifier as well when it sends the CSR to the CA. 228 5.1. Router-Generated Keys 230 In the router-generated method, once the protected channel is 231 established and the initial Set-Up (Section 4) performed, the 232 operator issues a command or commands for the router to generate the 233 public/private key pair, to generate the PKCS#10 certification 234 request, and to sign the PKCS#10 certification request with the 235 private key. Once the router has generated the PKCS#10 certification 236 request, it returns it to the operator over the protected channel. 238 The operator includes the chosen AS number and the BGP Identifier 239 when it sends the CSR to the CA. 241 Even if the operator cannot extract the private key from the router, 242 this signature still provides a linkage between a private key and a 243 router. That is, the operator can verify the proof of possession 244 (POP), as required by [RFC6484]. 246 NOTE: The CA needs to know that the router-generated CSR is 247 authorized. The easiest way to accomplish this for the operator to 248 mediate the communication with the CA. Other workflows are possible, 249 e.g., where the router sends the CSR to the CA but the operator logs 250 in to the CA independently and is presented with a list of pending 251 requests to approve. See Section 8 for an additional workflow. 253 If a router were to communicate directly with a CA to have the CA 254 certify the PKCS#10 certification request, there would be no way for 255 the CA to authenticate the router. As the operator knows the 256 authenticity of the router, the operator mediates the communication 257 with the CA. 259 5.2. Operator-Generated Keys 261 In the operator-generated method, the operator generates the 262 public/private key pair on a management station and installs the 263 private key into the router over the protected channel. Beware that 264 experience has shown that copy-and-paste from a management station to 265 a router can be unreliable for long texts. 267 The operator then creates and signs the PKCS#10 certification request 268 with the private key; the operator includes the chosen AS number and 269 the BGP Identifier when it sends the CSR to the CA. 271 5.2.1. Using PKCS#8 to Transfer Private Key 273 A private key can be encapsulated in a PKCS#8 Asymmetric Key Package 274 [RFC5958] and SHOULD be further encapsulated in Cryptographic Message 275 Syntax (CMS) SignedData [RFC5652] and signed with the operators's End 276 Entity (EE) private key. 278 The router SHOULD verify the signature of the encapsulated PKCS#8 to 279 ensure the returned private key did in fact come from the operator, 280 but this requires that the operator also provision via the CLI or 281 include in the SignedData the RPKI CA certificate and relevant 282 operator's EE certificate(s). The router SHOULD inform the operator 283 whether or not the signature validates to a trust anchor; this 284 notification mechanism is out of scope. 286 6. Send PKCS#10 and Receive PKCS#7 288 The operator uses RPKI management tools to communicate with the 289 global RPKI system to have the appropriate CA validate the PKCS#10 290 certification request, sign the key in the PKCS#10 (i.e., certify it) 291 and generate a PKCS#7 certs-only message, as well as publishing the 292 certificate in the Global RPKI. External network connectivity may be 293 needed if the certificate is to be published in the Global RPKI. 295 After the CA certifies the key, it does two things: 297 1. Publishes the certificate in the Global RPKI. The CA must have 298 connectivity to the relevant publication point, which in turn 299 must have external network connectivity as it is part of the 300 Global RPKI. 302 2. Returns the certificate to the operator's management station, 303 packaged in a PKCS#7 certs-only message, using the corresponding 304 method by which it received the certificate request. It SHOULD 305 include the certificate chain below the TA Certificate so that 306 the router can validate the router certificate. 308 In the operator-generated method, the operator SHOULD extract the 309 certificate from the PKCS#7 certs-only message, and verify that the 310 public key the operator holds corresponds to the returned public key 311 in the PKCS#7 certs-only message. If the operator saved the PKCS#10 312 it can check this correspondence by comparing the public key in the 313 CSR to the public key in the returned certificate. If the operator 314 has not saved the PKCS#10, it can check this correspondence by 315 regenerating the public key from the private key and then verifying 316 that the regenerated public key matches the public key returned in 317 the certificate. 319 In the operator-generated method, the operator has already installed 320 the private key in the router (see Section 5.2). 322 7. Install Certificate 324 The operator provisions the PKCS#7 certs-only message into the router 325 over the protected channel. 327 The router SHOULD extract the certificate from the PKCS#7 certs-only 328 message and verify that the public key corresponds to the stored 329 private key. If the router stored the PKCS#10, it can check this 330 correspondence by comparing the public key in the CSR to the public 331 key in the returned certificate. If the router did not store the 332 PKCS#10, it can check this correspondence by generating a signature 333 on any data and then verifying the signature using the returned 334 certificate. The router SHOULD inform the operator whether it 335 successfully received the certificate and whether or not the keys 336 correspond; the mechanism is out of scope. 338 The router SHOULD also verify that the returned certificate validates 339 back to the installed TA Certificate, i.e., the entire chain from the 340 installed TA Certificate through subordinate CAs to the BGPsec 341 certificate validate. To perform this verification, the CA 342 certificate chain needs to be returned along with the router's 343 certificate in the PKCS#7 certs-only message. The router SHOULD 344 inform the operator whether or not the signature validates to a trust 345 anchor; this notification mechanism is out of scope. 347 NOTE: The signature on the PKCS#8 and Certificate need not be made by 348 the same entity. Signing the PKCS#8 permits more advanced 349 configurations where the entity that generates the keys is not the 350 direct CA. 352 8. Advanced Deployment Scenarios 354 More PKI-capable routers can take advantage of increased 355 functionality and lighten the operator's burden. Typically, these 356 routers include either pre-installed manufacturer-generated 357 certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed 358 manufacturer-generated Pre-Shared Keys (PSK) as well as 359 PKI-enrollment functionality and transport protocol, e.g., CMC's 360 "Secure Transport" [RFC7030] or the original CMC transport protocol's 361 [RFC5273]. When the operator first establishes a protected channel 362 between the management system and the router, this pre-installed key 363 material is used to authenticate the router. 365 The operator's burden shifts here to include: 367 1. Securely communicating the router's authentication material to 368 the CA prior to operator initiating the router's CSR. CAs use 369 authentication material to determine whether the router is 370 eligible to receive a certificate. Authentication material at a 371 minimum includes the router's AS number and BGP Identifier as 372 well as the router's key material, but can also include 373 additional information. Authentication material can be 374 communicated to the CA (i.e., CSRs signed by this key material 375 are issued certificates with this AS and BGP Identifier) or to 376 the router (i.e., the operator uses the vendor-supplied 377 management interface to include the AS number and BGP Identifier 378 in the router-generated CSR). 380 2. Enabling the router to communicate with the CA. While the 381 router-to-CA communications are operator-initiated, the 382 operator's management interface need not be involved in the 383 communications path. Enabling the router-to-CA connectivity 384 requires connections to external networks (i.e., through 385 firewalls, NATs, etc.). 387 3. Ensuring the cryptographic chain of custody from the 388 manufacturer. For the pre-installed key material, the operator 389 needs guarantees that either no one has accessed the private key 390 or an authenticated log of those who have accessed it has been 391 provided to the operator. 393 Once configured, the operator can begin the process of enrolling the 394 router. Because the router is communicating directly with the CA, 395 there is no need for the operator to retrieve the PKCS#10 396 certification request from the router as in Section 5 or return the 397 PKCS#7 certs-only message to the router as in Section 6. Note that 398 the checks performed by the router in Section 7, namely extracting 399 the certificate from the PKCS#7 certs-only message, verifying the 400 public key corresponds to the private key, and that the returned 401 certificate validated back to an installed trust anchor, SHOULD be 402 performed. Likewise, the router SHOULD notify the operator if any of 403 these fail, but this notification mechanism is out of scope. 405 When a router is so configured, the communication with the CA SHOULD 406 be automatically re-established by the router at future times to 407 renew the certificate automatically when necessary (See Section 9). 408 This further reduces the tasks required of the operator. 410 9. Key Management 412 Key management does not only include key generation, key 413 provisioning, certificate issuance, and certificate distribution. It 414 also includes assurance of key validity, key roll-over, and key 415 preservation during router replacement. All of these 416 responsibilities persist for as long as the operator wishes to 417 operate the BGPsec-speaking router. 419 9.1. Key Validity 421 It is critical that a BGPsec-speaking router is signing with a valid 422 private key at all times. To this end, the operator needs to ensure 423 the router always has a non-expired certificate. I.e. the key used 424 to sign BGPsec announcements always has an associated certificate 425 whose expiry time is after the current time. 427 Ensuring this is not terribly difficult but requires that either: 429 1. The router have a mechanism to notify the operator that the 430 certificate has an impending expiration, and/or 432 2. The operator note the expiry time of the certificate and uses a 433 calendaring program to remind them of the expiry time, and/or 435 3. The RPKI CA warn the operator of pending expiration, and/or 437 4. The operator use some other kind of automated process to search 438 for and track the expiry times of router certificates. 440 It is advisable that expiration warnings happen well in advance of 441 the actual expiry time. 443 Regardless of the technique used to track router certificate expiry 444 times, it is advisable to notify additional operators in the same 445 organization as the expiry time approaches, thereby ensuring that the 446 forgetfulness of one operator does not affect the entire 447 organization. 449 Depending on inter-operator relationship, it may be helpful to notify 450 a peer operator that one or more of their certificates are about to 451 expire. 453 9.2. Key Roll-Over 455 Routers that support multiple private keys also greatly increase the 456 chance that routers can continuously speak BGPsec because the new 457 private key and certificate can be obtained and distributed prior to 458 expiration of the operational key. Obviously, the router needs to 459 know when to start using the new key. Once the new key is being 460 used, having the already distributed certificate ensures continuous 461 operation. 463 More information on how to proceed with a Key Roll-Over is described 464 in [I-D.sidrops-bgpsec-rollover]. 466 9.3. Key Revocation 468 In certain circumstances, a router's BGPsec certificate may need to 469 be revoked. When this occurs, the operator needs to use the RPKI CA 470 system to revoke the certificate by placing the router's BGPsec 471 certificate on the Certificate Revocation List (CRL) as well as 472 re-keying the router's certificate. 474 When an active router key is to be revoked, the process of requesting 475 the CA to revoke, the process of the CA actually revoking the 476 router's certificate, and then the process of re-keying/renewing the 477 router's certificate, (possibly distributing a new key and 478 certificate to the router), and distributing the status, takes time 479 during which the operator must decide how they wish to maintain 480 continuity of operations, with or without the compromised private 481 key, or whether they wish to bring the router offline to address the 482 compromise. 484 Keeping the router operational and BGPsec-speaking is the ideal goal; 485 but, if operational practices do not allow this, then reconfiguring 486 the router to disable BGPsec is likely preferred to bringing the 487 router offline. 489 Routers which support more than one private key, where one is 490 operational and other(s) are soon-to-be-operational, facilitate 491 revocation events because the operator can configure the router to 492 make a soon-to-be-operational key operational, request revocation of 493 the compromised key, and then make a next generation 494 soon-to-be-operational key. Hopefully, all this can be done without 495 needing to take offline or reboot the router. For routers which 496 support only one operational key, the operators should create or 497 install the new private key, and then request revocation of the 498 certificate corresponding to the compromised private key. 500 9.4. Router Replacement 502 Currently routers often generate private keys for uses such as SSH, 503 and the private keys may not be seen or exported from the router. 504 While this is good security, it creates difficulties when a routing 505 engine or whole router must be replaced in the field and all software 506 which accesses the router must be updated with the new keys. Also, 507 any network based initial contact with a new routing engine requires 508 trust in the public key presented on first contact. 510 To allow operators to quickly replace routers without requiring 511 update and distribution of the corresponding public keys in the RPKI, 512 routers SHOULD allow the private BGPsec key to be inserted via a 513 protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This 514 lets the operator escrow the old private key via the mechanism used 515 for operator-generated keys, see Section 5.2, such that it can be re- 516 inserted into a replacement router. The router MAY allow the private 517 key to be to be exported via the protected channel after key 518 generation, but this SHOULD be paired with functionality that sets 519 the newly generated key into a permanent non-exportable state to 520 ensure that it is not exported at a future time by unauthorized 521 operations. 523 10. Security Considerations 525 The router's manual will describe whether the router supports one, 526 the other, or both of the key generation options discussed in the 527 earlier sections of this draft as well as other important security- 528 related information (e.g., how to SSH to the router). After 529 familiarizing one's self with the capabilities of the router, an 530 operator is encouraged to ensure that the router is patched with the 531 latest software updates available from the manufacturer. 533 This document defines no protocols. So, in some sense, it introduces 534 no new security considerations. However, it relies on many others 535 and the security considerations in the referenced documents should be 536 consulted; notably, those document listed in Section 1 should be 537 consulted first. PKI-relying protocols, of which BGPsec is one, have 538 many issues to consider - so many, in fact, entire books have been 539 written to address them; so listing all PKI-related security 540 considerations is neither useful nor helpful. Regardless, some boot- 541 strapping-related issues are listed here that are worth repeating: 543 Public-Private key pair generation: Mistakes here are, for all, 544 practical purposes catastrophic because PKIs rely on the pairing 545 of a difficult to generate public-private key pair with a signer; 546 all key pairs MUST be generated from a good source of non- 547 deterministic random input [RFC4086]. 549 Private key protection at rest: Mistakes here are, for all, practical 550 purposes catastrophic because disclosure of the private key allows 551 another entity to masquerade as (i.e., impersonate) the signer; 552 all private keys MUST be protected when at rest in a secure 553 fashion. Obviously, how each router protects private keys is 554 implementation specific. Likewise, the local storage format for 555 the private key is just that, a local matter. 557 Private key protection in transit: Mistakes here are, for all, 558 practical purposes catastrophic because disclosure of the private 559 key allows another entity to masquerade as (i.e., impersonate) the 560 signer; transport security is therefore strongly RECOMMENDED. The 561 level of security provided by the transport layer's security 562 mechanism SHOULD be at least as good as the strength of the BGPsec 563 key; there's no point in spending time and energy to generate an 564 excellent public-private key pair and then transmit the private 565 key in the clear or with a known-to-be-broken algorithm, as it 566 just undermines trust that the private key has been kept private. 567 Additionally, operators SHOULD ensure the transport security 568 mechanism is up to date, in order to addresses all known 569 implementation bugs. 571 Though the CA's certificate is installed on the router and used to 572 verify that the returned certificate is in fact signed by the CA, the 573 revocation status of the CA's certificate is rarely checked as the 574 router may not have global connectivity or CRL-aware software. The 575 operator MUST ensure that the installed CA certificate is valid. 577 11. IANA Considerations 579 This document has no IANA Considerations. 581 12. References 583 12.1. Normative References 585 [I-D.sidrops-bgpsec-rollover] 586 Weis, B, R. Gagliano, and K. Patel, "BGPsec Router 587 Certificate Rollover", draft-ietf-sidrops-bgpsec- 588 rollover (work in progress), December 2017. 590 [I-D.lamps-rfc5751-bis] 591 Schaad, J., Ramsdell, B, S. Turner, 592 "Secure/Multipurpose Internet Mail Extension (S/MIME) 593 Version 4.0", draft-ietf-lamps-rfc5751- 594 bis (work in progress), July 2018. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, DOI 598 10.17487/RFC2119, March 1997, . 601 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 602 "Randomness Requirements for Security", BCP 106, RFC 4086, 603 DOI 10.17487/RFC4086, June 2005, . 606 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 607 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 608 January 2006, . 610 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 611 RFC 5652, DOI 10.17487/RFC5652, September 2009, 612 . 614 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 615 10.17487/RFC5958, August 2010, . 618 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 619 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 620 June 2011, . 622 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 623 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 624 10.17487/RFC8174, May 2017, . 627 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 628 Formats, and Signature Formats", RFC 8208, DOI 629 10.17487/RFC8208, September 2017, . 632 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 633 BGPsec Router Certificates, Certificate Revocation Lists, 634 and Certification Requests", RFC 8209, DOI 635 10.17487/RFC8209, September 2017, . 638 [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and 639 metropolitan area networks - Secure Device Identity", 640 December 2009, 641 . 644 12.1. Informative References 646 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 647 Infrastructure Operational Protocols: FTP and HTTP", 648 RFC 2585, DOI 10.17487/RFC2585, May 1999, 649 . 651 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 652 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 653 RFC 3766, DOI 10.17487/RFC3766, April 2004, 654 . 656 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 657 (CMC): Transport Protocols", RFC 5273, DOI 658 10.17487/RFC5273, June 2008, . 661 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 662 "Elliptic Curve Cryptography Subject Public Key 663 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 664 . 666 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 667 Secure Shell Transport Layer Protocol", RFC 5647, DOI 668 10.17487/RFC5647, August 2009, . 671 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 672 Integration in the Secure Shell Transport Layer", 673 RFC 5656, DOI 10.17487/RFC5656, December 2009, 674 . 676 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 677 DOI 10.17487/RFC5967, August 2010, . 680 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 681 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 682 March 2011, . 684 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 685 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 686 February 2012, . 688 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 689 Policy (CP) for the Resource Public Key Infrastructure 690 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 691 2012, . 693 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 694 Verification for the Secure Shell (SSH) Transport Layer 695 Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, 696 . 698 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 699 "Enrollment over Secure Transport", RFC 7030, DOI 700 10.17487/RFC7030, October 2013, . 703 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 704 Specification", RFC 8205, DOI 10.17487/RFC8205, September 705 2017, . 707 [SP800-57] National Institute of Standards and Technology (NIST), 708 Special Publication 800-57: Recommendation for Key 709 Management - Part 1 (Revised), March 2007. 711 Appendix A. Management/Router Channel Security 713 Encryption, integrity, authentication, and key exchange algorithms 714 used by the protected channel should be of equal or greater strength 715 than the BGPsec keys they protect, which for the algorithm specified 716 in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57] 717 for information about this strength claim as well as [RFC3766] for 718 "how to determine the length of an asymmetric key as a function of a 719 symmetric key strength requirement." In other words, for the 720 encryption algorithm, do not use export grade crypto (40-56 bits of 721 security), do not use Triple DES (112 bits of security). Suggested 722 minimum algorithms would be AES-128: aes128-cbc [RFC4253] and 723 AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or 724 AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 725 [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for 726 key exchange. 728 Some routers support the use of public key certificates and SSH. The 729 certificates used for the SSH session are different than the 730 certificates used for BGPsec. The certificates used with SSH should 731 also enable a level of security commensurate with BGPsec keys; 732 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 733 authentication. 735 The protected channel must provide confidentiality, authentication, 736 and integrity and replay protection. 738 Appendix B. The n00b Guide to BGPsec Key Management 740 This appendix is informative. It attempts to explain some of the PKI 741 lingo in plainer language. 743 BGPsec speakers send signed BGPsec updates that are verified by other 744 BGPsec speakers. In PKI parlance, the senders are referred to as 745 signers and the receivers are referred to as relying parties. The 746 signers with which we are concerned here are routers signing BGPsec 747 updates. Signers use private keys to sign and relying parties use 748 the corresponding public keys, in the form of X.509 public key 749 certificates, to verify signatures. The third party involved is the 750 entity that issues the X.509 public key certificate, the 751 Certification Authority (CA). Key management is all about making 752 these key pairs and the certificates, as well as ensuring that the 753 relying parties trust that the certified public keys in fact 754 correspond to the signers' private keys. 756 The specifics of key management greatly depend on the routers as well 757 as management interfaces provided by the routers' vendor. Because of 758 these differences, it is hard to write a definitive "how to," but 759 this guide is intended to arm operators with enough information to 760 ask the right questions. The other aspect that makes this guide 761 informative is that the steps for the do-it-yourself (DIY) approach 762 involve arcane commands while the GUI-based vendor-assisted 763 management console approach will likely hide all of those commands 764 behind some button clicks. Regardless, the operator will end up with 765 a BGPsec-enabled router. Initially, we focus on the DIY approach and 766 then follow up with some information about the GUI-based approach. 768 The first step in the DIY approach is to generate a private key; but 769 in fact what you do is create a key pair; one part, the private key, 770 is kept very private and the other part, the public key, is given out 771 to verify whatever is signed. The two methods for how to create the 772 key pair are the subject of this document, but it boils down to 773 either doing it on-router (router-driven) or off-router (operator- 774 driven). 776 If you are generating keys on the router (router-driven), then you 777 will need to access the router. Again, how you access the router is 778 router-specific, but generally the DIY approach uses the CLI and 779 accessing the router either directly via the router's craft port or 780 over the network on an administrative interface. If accessing the 781 router over the network be sure to do it securely (i.e., use SSHv2). 782 Once logged into the router, issue a command or a series of commands 783 that will generate the key pair for the algorithms referenced in the 784 main body of this document; consult your router's documentation for 785 the specific commands. The key generation process will yield one or 786 more files the private key and the public key; the file format varies 787 depending on the arcane command you issued, but generally the files 788 are DER or PEM-encoded. 790 The second step is to generate the certification request, which is 791 often referred to as a certificate signing request (CSR) or PKCS#10 792 certification request, and to send it to the CA to be signed. To 793 generate the CSR, you issue some more arcane commands while logged 794 into the router; using the private key just generated to sign the 795 certification request with the algorithms referenced in the main body 796 of this document; the CSR is signed to prove to the CA that the 797 router has possession of the private key (i.e., the signature is the 798 proof-of-possession). The output of the command is the CSR file; the 799 file format varies depending on the arcane command you issued, but 800 generally the files are DER or PEM-encoded. 802 The third step is to retrieve the signed CSR from the router and send 803 it to the CA. But before sending it, you need to also send the CA 804 the subject name (i.e., "ROUTER-" followed by the AS number) and 805 serial number (i.e., the 32-bit BGP Identifier) for the router. The 806 CA needs this information to issue the certificate. How you get the 807 CSR to the CA, is beyond the scope of this document. While you are 808 still connected to the router, install the Trust Anchor (TA) for the 809 root of the PKI. At this point, you no longer need access to the 810 router for BGPsec-related initiation purposes. 812 The fourth step is for the CA to issue the certificate based on the 813 CSR you sent; the certificate will include the subject name, serial 814 number, public key, and other fields as well as being signed by the 815 CA. After the CA issues the certificate, the CA returns the 816 certificate, and posts the certificate to the RPKI repository. Check 817 that the certificate corresponds to the pubic key contained in the 818 certificate by verifying the signature on the CSR sent to the CA; 819 this is just a check to make sure that the CA issued a certificate 820 that includes a public key that is the pair of the private key (i.e., 821 the math will work when verifying a signature generated by the 822 private with the returned certificate). 824 If generating the keys off-router (operator-driven), then the same 825 steps are used as the on-router key generation, (possibly with the 826 same arcane commands as those used in the on-router approach), but no 827 access to the router is needed the first three steps are done on an 828 administrative workstation: o Step 1: Generate key pair; o Step 2: 829 Create CSR and sign CSR with private key, and; o Step 3: Send CSR 830 file with the subject name and serial number to CA. 832 After the CA has returned the certificate and you have checked the 833 certificate, you need to put the private key and TA in the router. 834 Assuming the DIY approach, you will be using the CLI and accessing 835 the router either directly via the router's craft port or over the 836 network on an admin interface; if accessing the router over the 837 network make doubly sure it is done securely (i.e., use SSHv2) 838 because the private key is being moved over the network. At this 839 point, access to the router is no longer needed for BGPsec-related 840 initiation purposes. 842 NOTE: Regardless of the approach taken, the first three steps could 843 trivially be collapsed by a vendor-provided script to yield the 844 private key and the signed CSR. 846 Given a GUI-based vendor-assisted management console, then all of 847 these steps will likely be hidden behind pointing and clicking the 848 way through BGPsec-enabling the router. 850 The scenarios described above require the operator to access each 851 router, which does not scale well to large networks. An alternative 852 would be to create an image, perform the necessary steps to get the 853 private key and trust anchor on the image, and then install the image 854 via a management protocol. 856 One final word of advice; certificates include a notAfter field that 857 unsurprisingly indicates when relying parties should no longer trust 858 the certificate. To avoid having routers with expired certificates 859 follow the recommendations in the Certification Policy (CP) [RFC6484] 860 and make sure to renew the certificate at least one week prior to the 861 notAfter date. Set a calendar reminder in order not to forget! 863 Authors' Addresses 865 Randy Bush 866 IIJ / Dragon Research Labs 867 5147 Crystal Springs 868 Bainbridge Island, Washington 98110 869 US 871 Email: randy@psg.com 873 Sean Turner 874 sn3rd 876 Email: sean@sn3rd.com 878 Keyur Patel 879 Arrcus, Inc. 881 Email: keyur@arrcus.com