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