idnits 2.17.1 draft-ietf-sidr-rtr-keying-13.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 5, 2017) is 2578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ Lab / Dragon Research Lab 4 Intended status: Standards Track S. Turner 5 Expires: October 7, 2017 sn3rd 6 K. Patel 7 Arrcus, Inc. 8 April 5, 2017 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-13 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", "MAY", and "OPTIONAL" are to 26 be interpreted as described in RFC 2119 [RFC2119] only when they 27 appear in all upper case. They may also appear in lower or mixed 28 case as English words, without normative meaning. 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) 2017 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. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 4 67 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. PKCS#10 Generation . . . . . . . . . . . . . . . . . . . . . . 4 69 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 4 70 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 71 6. Installing Certified Keys . . . . . . . . . . . . . . . . . . 5 72 7. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 6 73 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 8 76 7.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 77 8.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 9 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 11.1. Informative References . . . . . . . . . . . . . . . . . 12 83 Appendix A. Management/Router Channel Security . . . . . . . . . 14 84 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 BGPsec-speaking routers are provisioned with private keys, which 90 allow them to digitally sign BGPsec announcements. To verify the 91 signature, the public key, in the form of a certificate [I-D.ietf- 92 sidr-bgpsec-pki-profiles], is published in the Resource Public Key 93 Infrastructure (RPKI). This document describes provisioning of 94 BGPsec-speaking routers with the appropriate public-private key- 95 pairs. There are two sub-methods, router-driven and operator-driven. 97 These two sub-methods differ in where the keys are generated: on the 98 router in the router-driven method, and elsewhere in the operator- 99 driven method. Routers are required to support at least one of the 100 methods in order to work in various deployment environments. Some 101 routers may not allow the private key to be off-loaded while others 102 may. While off-loading private keys would ease swapping of routing 103 engines, exposure of private keys is a well known security risk. 105 In the operator-driven method, the operator generates the private/ 106 public key-pair and sends it to the router, perhaps in a PKCS#8 107 package [RFC5958]. 109 In the router-driven method, the router generates its own public/ 110 private key-pair, uses the private key to sign a PKCS#10 111 certification request [I-D.ietf-sidr-bgpsec-pki-profiles], which 112 includes the public key), and returns the certification request to 113 the operator to be forwarded to the RPKI Certification Authority 114 (CA). The CA returns a PKCS#7, which includes the certified public 115 key in the form of a certificate, to the operator for loading into 116 the router; and the CA also publishes the certificate in the RPKI. 118 The router-driven model mirrors the model used by traditional PKI 119 subscribers; the private key never leaves trusted storage (e.g., 120 Hardware Security Module). This is by design and supports classic 121 PKI Certification Policies for (often human) subscribers which 122 require the private key only ever be controlled by the subscriber to 123 ensure that no one can impersonate the subscriber. For non-humans, 124 this model does not always work. For example, when an operator wants 125 to support hot-swappable routers the same private key needs to be 126 installed in the soon-to-be online router that was used by the the 127 soon-to-be offline router. This motivated the operator-driven model. 129 The remainder of this document describes how operators can use the 130 two methods to provision new and existing routers. The methods 131 described involve the operator configuring the two end points and 132 acting as the intermediary. Section 7 describes a method that 133 requires more capable routers. 135 Useful References: [I-D.ietf-sidr-bgpsec-protocol] describes gritty 136 details, [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for 137 the PKCS #10 request, and [I-D.ietf-sidr-bgpsec-algs] specifies the 138 algorithms used to generate the 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. Regardless of the method 143 chosen, operators first establish a secure communication channel 144 between the management system and the router. How this channel is 145 established is router-specific and is beyond scope of this document. 146 Though other configuration mechanisms might be used, e.g. NetConf 147 (see [RFC6470]); for simplicity, in this document, the communication 148 channel between the management platform and the router is assumed to 149 be an SSH-protected CLI. See Appendix A for security considerations 150 for this channel. 152 3. Exchanging Certificates 154 The operator management station can exchange certificate requests and 155 certificates with routers and with the RPKI CA infrastructure using 156 the application/pkcs10 media type [RFC5967] and application/ 157 pkcs7-mime [RFC5751], respectively, and may use FTP or HTTP per 158 [RFC2585], or the Enrollment over Secure Transport (EST) [RFC7030]. 160 4. Set-Up 162 To start, the operator uses the communication channel to install the 163 appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. 164 This will later enable the router to validate the router certificate 165 returned in the PKCS#7. 167 The operator also configures the Autonomous System (AS) number to be 168 used in the generated router certificate. This may be the sole AS 169 configured on the router, or an operator choice if the router is 170 configured with multiple ASs. 172 The operator configures or extracts from the router the BGP RouterID 173 to be used in the generated certificate. In the case where the 174 operator has chosen not to use unique per-router certificates, a 175 RouterID of 0 may be used. 177 5. PKCS#10 Generation 179 The private key, and hence the PKCS#10 request, which is sometimes 180 referred to as a Certificate Signing Request (CSR), may be generated 181 by the router or by the operator. 183 5.1. Router-Generated Keys 185 In the router-generated method, once the protected session is 186 established and the initial Set-Up (Section 4) performed, the 187 operator issues a command or commands for the router to generate the 188 public/private key pair, to generate the PKCS#10 request, and to sign 189 the PKCS#10 with the private key. Once generated, the PKCS#10 is 190 returned to the operator over the protected channel. 192 If a router was to communicate directly with a CA to have the CA 193 certify the PKCS#10, there would be no way for the CA to authenticate 194 the router. As the operator knows the authenticity of the router, 195 the operator mediates the communication with the CA. 197 The operator adds the chosen AS number and the RouterID to send to 198 the RPKI CA for the CA to certify. 200 5.2. Operator-Generated Keys 202 In the operator-generated method, the operator generates the 203 public/private key pair on a management station and installs the 204 private key into the router over the protected channel. Beware that 205 experience has shown that copy and paste from a management station to 206 a router can be unreliable for long texts. 208 Alternatively, the private key may be encapsulated in a PKCS #8 209 [RFC5958], the PKCS#8 is further encapsulated in Cryptographic 210 Message Syntax (CMS) SignedData [RFC5652], and signed by the AS's End 211 Entity (EE) certificate. 213 The router SHOULD verify the signature of the encapsulated PKCS#8 to 214 ensure the returned private key did in fact come from the operator, 215 but this requires that the operator also provision via the CLI or 216 include in the SignedData the RPKI CA certificate and relevant AS's 217 EE certificate(s). The router should inform the operator whether or 218 not the signature validates to a trust anchor; this notification 219 mechanism is out of scope. 221 The operator then creates and signs the PKCS#10 with the private key, 222 and adds the chosen AS number and RouterID to be sent to the RPKI CA 223 for the CA to certify. 225 6. Installing Certified Keys 227 The operator uses RPKI management tools to communicate with the 228 global RPKI system to have the appropriate CA validate the PKCS#10 229 request, sign the key in the PKCS#10 (i.e., certify it) and generated 230 PKCS#7 response, as well as publishing the certificate in the Global 231 RPKI. External network connectivity may be needed if the certificate 232 is to be published in the Global RPKI. 234 After the CA certifies the key, it does two things: 236 1. Publishes the certificate in the Global RPKI. The CA must have 237 connectivity to the relevant publication point, which in turn 238 must have external network connectivity as it is part of the 239 Global RPKI. 241 2. Returns the certificate to the operator's management station, 242 packaged in a PKCS#7, using the corresponding method by which it 243 received the certificate request. It SHOULD include the 244 certificate chain below the TA Certificate so that the router can 245 validate the router certificate. 247 In the operator-generated method, the operator SHOULD extract the 248 certificate from the PKCS#7, and verify that the private key it holds 249 corresponds to the returned public key. 251 In the operator-generated method, the operator has already installed 252 the private key in the router (see Section 5.2). 254 The operator provisions the PKCS#7 into the router over the secure 255 channel. 257 The router SHOULD extract the certificate from the PKCS#7 and verify 258 that the private key corresponds to the returned public key. The 259 router SHOULD inform the operator whether it successfully received 260 the certificate and whether or not the keys correspond; the mechanism 261 is out of scope. 263 The router SHOULD also verify that the returned certificate validates 264 back to the installed TA Certificate, i.e., the entire chain from the 265 installed TA Certificate through subordinate CAs to the BGPsec 266 certificate validate. To perform this verification the CA 267 certificate chain needs to be returned along with the router's 268 certificate in the PKCS#7. The router SHOULD inform the operator 269 whether or not the signature validates to a trust anchor; this 270 notification mechanism is out of scope. 272 Note: The signature on the PKCS#8 and Certificate need not be made by 273 the same entity. Signing the PKCS#8, permits more advanced 274 configurations where the entity that generates the keys is not the 275 direct CA. 277 Even if the operator cannot extract the private key from the router, 278 this signature still provides a linkage between a private key and a 279 router. That is the server can verify the proof of possession (POP), 280 as required by [RFC6484]. 282 7. Advanced Deployment Scenarios 284 More PKI-capable routers can take advantage of this increased 285 functionality and lighten the operator's burden. Typically, these 286 routers include either pre-installed manufacturer-generated 287 certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed 288 manufacturer-generated Pre-Shared Keys (PSK) as well as PKI- 289 enrollment functionality and transport protocol, e.g., CMC's "Secure 290 Transport" [RFC7030] or the original CMC transport protocol's 291 [RFC5273]. When the operator first establishes a secure 292 communication channel between the management system and the router, 293 this pre-installed key material is used to authenticate the router. 295 The operator burden shifts here to include: 297 1. Securely communicating the router's authentication material to 298 the CA prior to operator initiating the server's CSR. CAs use 299 authentication material to determine whether the router is 300 eligible to receive a certificate. Authentication material at a 301 minimum includes the router's AS number and RouterID as well as 302 the router's key material, but can also include additional 303 information. Authentication material can can be communicated to 304 the CA (i.e., CSRs signed by this key material are issued 305 certificates with this AS and RouterID) or to the router (i.e., 306 the operator uses the vendor-supplied management interface to 307 include the AS number and routerID in the router-generated CSR). 309 2. Enabling the router to communicate with the CA. While the 310 router-to-CA communications are operator-initiated, the 311 operator's management interface need not be involved in the 312 communications path. Enabling the router-to-CA connectivity MAY 313 require connections to external networks (i.e., through 314 firewalls, NATs, etc.). 316 Once configured, the operator can begin the process of enrolling the 317 router. Because the router is communicating directly with the CA, 318 there is no need for the operator to retrieve the PKCS#10 from the 319 router or return the PKCS#7 to the router as in Section 6. Note that 320 the checks performed by the router, namely extracting the certificate 321 from the PKCS#7, verifying the private key corresponds to the 322 returned public key, and that the returned certificate validated back 323 to an installed trust anchor, SHOULD be performed. Likewise, the 324 router SHOULD notify the operator if any of these fail, but this 325 notification mechanism is out of scope. 327 When a router is so configured the communication with the CA SHOULD 328 be automatically re-established by the router at future times to 329 renew or rekey the certificate automatically when necessary (See 330 Section 8). This further reduces the tasks required of the operator. 332 8. Key Management 333 An operator's responsibilities do not end after key generation, key 334 provisioning, certificate issuance, and certificate distribution. 335 They persist for as long as the operator wishes to operate the 336 BGPsec-speaking router. 338 8.1. Key Validity 340 It is critical that a BGPsec speaking router ensures that it is 341 signing with a valid private key at all times. To this end, the 342 operator needs to ensure the router always has a non-expired 343 certificate. I.e. the key used to sign BGPsec announcements always 344 has an associated certificate whose expiry time is after the current 345 time. 347 Ensuring this is not terribly difficult but requires that either: 349 1. The router has a mechanism to notify the operator that the 350 certificate has an impending expiration, and/or 352 2. The operator notes the expiry time of the certificate and uses a 353 calendaring program to remind them of the expiry time, and/or 355 3. The RPKI CA warns the operator of pending expiration, and/or 357 4. Use some other kind of automated process to search for and track 358 the expiry times of router certificates. 360 It is advisable that expiration warnings happen well in advance of 361 the actual expiry time. 363 Regardless of the technique used to track router certificate expiry 364 times, it is advisable to notify additional operators in the same 365 organization as the expiry time approaches thereby ensuring that the 366 forgetfulness of one operator does not affect the entire 367 organization. 369 Depending on inter-operator relationship, it may be helpful to notify 370 a peer operator that one or more of their certificates are about to 371 expire. 373 8.2. Key Roll-Over 375 Routers that support multiple private keys also greatly increase the 376 chance that routers can continuously speak BGPsec because the new 377 private key and certificate can be obtained and distributed prior to 378 expiration of the operational key. Obviously, the router needs to 379 know when to start using the new key. Once the new key is being 380 used, having the already distributed certificate ensures continuous 381 operation. 383 Whether the certificate is re-keyed (i.e., different key in the 384 certificate with a new expiry time) or renewed (i.e., the same key in 385 the certificate with a new expiry time) depends on the key's lifetime 386 and operational use. Arguably, re-keying the router's BGPsec 387 certificate every time the certificate expires is more secure than 388 renewal because it limits the private key's exposure. However, if 389 the key is not compromised the certificate could be renewed as many 390 times as allowed by the operator's security policy. Routers that 391 support only one key can use renewal to ensure continuous operation, 392 assuming the certificate is renewed and distributed well in advance 393 of the operational certificate's expiry time. 395 7.3. Key Revocation 397 Certain unfortunate circumstances may occur causing a need to revoke 398 a router's BGPsec certificate. When this occurs, the operator needs 399 to use the RPKI CA system to revoke the certificate by placing the 400 router's BGPsec certificate on the Certificate Revocation List (CRL) 401 as well as re-keying the router's certificate. 403 When an active router key is to be revoked, the process of requesting 404 the CA to revoke, the process of the CA actually revoking the 405 router's certificate, and then the process of re-keying/renewing the 406 router's certificate, (possibly distributing a new key and 407 certificate to the router), and distributing the status takes time 408 during which the operator must decide how they wish to maintain 409 continuity of operations, with or without the compromised private 410 key, or whether they wish to bring the router offline to address the 411 compromise. 413 Keeping the router operational and BGPsec-speaking is the ideal goal, 414 but if operational practices do not allow this then reconfiguring the 415 router to disabling BGPsec is likely preferred to bringing the router 416 offline. 418 Routers which support more than one private key, where one is 419 operational and other(s) are soon-to-be-operational, facilitate 420 revocation events because the operator can configure the router to 421 make a soon-to-be-operational key operational, request revocation of 422 the compromised key, and then make a next generation soon-to-be- 423 operational key, all hopefully without needing to take offline or 424 reboot the router. For routers which support only one operational 425 key, the operators should create or install the new private key, and 426 then request revocation of the compromised private key. 428 8.4. Router Replacement 429 Currently routers often generate private keys for uses such as SSH, 430 and the private keys may not be seen or off-loaded from the router. 431 While this is good security, it creates difficulties when a routing 432 engine or whole router must be replaced in the field and all software 433 which accesses the router must be updated with the new keys. Also, 434 any network based initial contact with a new routing engine requires 435 trust in the public key presented on first contact. 437 To allow operators to quickly replace routers without requiring 438 update and distribution of the corresponding public keys in the RPKI, 439 routers SHOULD allow the private BGPsec key to inserted via a 440 protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This 441 lets the operator escrow the old private key via the mechanism used 442 for operator-generated keys, see Section 5.2, such that it can be re- 443 inserted into a replacement router. The router MAY allow the private 444 key to be to be off-loaded via the protected session, but this SHOULD 445 be paired with functionality that sets the key into a permanent non- 446 exportable state to ensure that it is not off-loaded at a future time 447 by unauthorized operations. 449 9. Security Considerations 451 The router's manual will describe whether the router supports one, 452 the other, or both of the key generation options discussed in the 453 earlier sections of this draft as well as other important security- 454 related information (e.g., how to SSH to the router). After 455 familiarizing one's self with the capabilities of the router, 456 operators are encouraged to ensure that the router is patched with 457 the latest software updates available from the manufacturer. 459 This document defines no protocols so in some sense introduces no new 460 security considerations. However, it relies on many others and the 461 security considerations in the referenced documents should be 462 consulted; notably, those document listed in Section 1 should be 463 consulted first. PKI-relying protocols, of which BGPsec is one, have 464 many issues to consider so many in fact entire books have been 465 written to address them; so listing all PKI-related security 466 considerations is neither useful nor helpful; regardless, some boot- 467 strapping-related issues are listed here that are worth repeating: 469 Public-Private key pair generation: Mistakes here are for all 470 practical purposes catastrophic because PKIs rely on the pairing 471 of a difficult to generate public-private key pair with a signer; 472 all key pairs MUST be generated from a good source of non- 473 deterministic random input [RFC4086]. 475 Private key protection at rest: Mistakes here are for all practical 476 purposes catastrophic because disclosure of the private key allows 477 another entity to masquerade as (i.e., impersonate) the signer; 478 all private keys MUST be protected when at rest in a secure 479 fashion. Obviously, how each router protects private keys is 480 implementation specific. Likewise, the local storage format for 481 the private key is just that, a local matter. 483 Private key protection in transit: Mistakes here are for all 484 practical purposes catastrophic because disclosure of the private 485 key allows another entity to masquerade as (i.e., impersonate) the 486 signer; transport security is therefore strongly RECOMMENDED. The 487 level of security provided by the transport layer's security 488 mechanism SHOULD be commensurate with the strength of the BGPsec 489 key; there's no point in spending time and energy to generate an 490 excellent public-private key pair and then transmit the private 491 key in the clear or with a known-to-be-broken algorithm, as it 492 just undermines trust that the private key has been kept private. 493 Additionally, operators SHOULD ensure the transport security 494 mechanism is up to date, in order to addresses all known 495 implementation bugs. 497 SSH key management is known, in some cases, to be lax 498 [I-D.ylonen-sshkeybcp]; employees that no longer need access to 499 routers SHOULD be removed the router to ensure only those authorized 500 have access to a router. 502 Though the CA's certificate is installed on the router and used to 503 verify that the returned certificate is in fact signed by the CA, the 504 revocation status of the CA's certificate is rarely checked as the 505 router may not have global connectivity or CRL-aware software. The 506 operator MUST ensure that installed CA certificate is valid. 508 10. IANA Considerations 510 This document has no IANA Considerations. 512 11. References 514 11.1. Normative References 516 [I-D.ietf-sidr-bgpsec-algs] 517 Turner, S., "BGP Algorithms, Key Formats, & Signature 518 Formats", draft-ietf-sidr-bgpsec-algs (work in 519 progress), March 2013. 521 [I-D.ietf-sidr-bgpsec-pki-profiles] 522 Reynolds, M., Turner, S., and S. Kent, "A Profile for 523 BGPSEC Router Certificates, Certificate Revocation Lists, 524 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 525 profiles (work in progress), October 2012. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, DOI 529 10.17487/RFC2119, March 1997, . 532 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 533 "Randomness Requirements for Security", BCP 106, RFC 4086, 534 DOI 10.17487/RFC4086, June 2005, . 537 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 538 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 539 January 2006, . 541 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 542 RFC 5652, DOI 10.17487/RFC5652, September 2009, 543 . 545 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 546 10.17487/RFC5958, August 2010, . 549 [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and 550 metropolitan area networks - Secure Device Identity", 551 December 2009, 552 . 555 11.1. Informative References 557 [I-D.ietf-sidr-bgpsec-protocol] 558 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 559 sidr-bgpsec-protocol (work in progress), February 2013. 561 [I-D.ylonen-sshkeybcp] 562 Ylonen, T. and G. Kent, "Managing SSH Keys for Automated 563 Access - Current Recommended Practice", draft-ylonen- 564 sshkeybcp (work in progress), April 2013. 566 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 567 Infrastructure Operational Protocols: FTP and HTTP", 568 RFC 2585, DOI 10.17487/RFC2585, May 1999, . 571 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 572 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 573 RFC 3766, DOI 10.17487/RFC3766, April 2004, 574 . 576 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 577 (CMC): Transport Protocols", RFC 5273, DOI 578 10.17487/RFC5273, June 2008, . 581 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 582 "Elliptic Curve Cryptography Subject Public Key 583 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 584 . 586 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 587 Secure Shell Transport Layer Protocol", RFC 5647, DOI 588 10.17487/RFC5647, August 2009, . 591 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 592 Integration in the Secure Shell Transport Layer", 593 RFC 5656, DOI 10.17487/RFC5656, December 2009, 594 . 596 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 597 Mail Extensions (S/MIME) Version 3.2 Message 598 Specification", RFC 5751, DOI 10.17487/RFC5751, January 599 2010, . 601 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 602 DOI 10.17487/RFC5967, August 2010, . 605 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 606 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 607 March 2011, . 609 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 610 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 611 February 2012, . 613 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 614 Policy (CP) for the Resource Public Key Infrastructure 615 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 616 2012, . 618 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 619 Verification for the Secure Shell (SSH) Transport Layer 620 Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, 621 . 623 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 624 "Enrollment over Secure Transport", RFC 7030, DOI 625 10.17487/RFC7030, October 2013, . 628 [SP800-57] National Institute of Standards and Technology (NIST), 629 Special Publication 800-57: Recommendation for Key 630 Management - Part 1 (Revised), March 2007. 632 Appendix A. Management/Router Channel Security 634 Encryption, integrity, authentication, and key exchange algorithms 635 used by the secure communication channel SHOULD be of equal or 636 greater strength than the BGPsec keys they protect, which for the 637 algorithm specified in [I-D.ietf-sidr-bgpsec-algs] is 128-bit; see 638 [RFC5480] and by reference [SP800-57] for information about this 639 strength claim as well as [RFC3766] for "how to determine the length 640 of an asymmetric key as a function of a symmetric key strength 641 requirement." In other words, for the encryption algorithm, do not 642 use export grade crypto (40-56 bits of security), do not use Triple 643 DES (112 bits of security). Suggested minimum algorithms would be 644 AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for 645 encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] 646 for integrity, ecdsa-sha2-nistp256 [RFC5656] for authentication, and 647 ecdh-sha2-nistp256 [RFC5656] for key exchange. 649 Some routers support the use of public key certificates and SSH. The 650 certificates used for the SSH session are different than the 651 certificates used for BGPsec. The certificates used with SSH should 652 also enable a level of security commensurate with BGPsec keys; 653 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 654 authentication. 656 Appendix B. The n00b Guide to BGPsec Key Management 658 This appendix is informative. It attempts to explain all of the PKI 659 technobabble in plainer language. 661 BGPsec speakers send signed BGPsec updates that are verified by other 662 BGPsec speakers. In PKI parlance, the senders are referred to as 663 signers and the receivers are referred to as relying parties. The 664 signers with which we are concerned here are routers signing BGPsec 665 updates. Signers use private keys to sign and relying parties use 666 the corresponding public keys, in the form of X.509 public key 667 certificates, to verify signatures. The third party involved is the 668 entity that issues the X.509 public key certificate, the 669 Certification Authority (CA). Key management is all about making 670 these key pairs and the certificates, as well as ensuring that the 671 relying parties trust that the certified public keys in fact 672 correspond to the signers' private keys. 674 The specifics of key management greatly depend on the routers as well 675 as management interfaces provided by the routers' vendor. Because of 676 these differences, it is hard to write a definitive "how to," but 677 this guide is intended to arm operators with enough information to 678 ask the right questions. The other aspect that makes this guide 679 informative is that the steps for the do-it-yourself (DIY) approach 680 involve arcane commands while the GUI-based vendor-assisted 681 management console approach will likely hide all of those commands 682 behind some button clicks. Regardless, the operator will end up with 683 a BGPsec-enabled router. Initially, we focus on the DIY approach and 684 then follow up with some information about the GUI-based approach. 686 The first step in the DIY approach is to generate a private key; but 687 in fact what you do is create a key pair; one part, the private key, 688 is kept very private and the other part, the public key, is given out 689 to verify whatever is signed. The two models for how to create the 690 key pair are the subject of this document, but it boils down to 691 either doing it on-router (router-driven) or off-router (operator- 692 driven). 694 If you are generating keys on the router (router-driven), then you 695 will need to access the router. Again, how you access the router is 696 router-specific, but generally the DIY approach uses the CLI and 697 accessing the router either directly via the router's craft port or 698 over the network on an administrative interface. If accessing the 699 router over the network be sure to do it securely (i.e., use SSHv2). 700 Once logged into the router, issue a command or a series of commands 701 that will generate the key pair for the algorithms noted in the main 702 body of this document; consult your router's documentation for the 703 specific commands. The key generation process will yield multiple 704 files: the private key and the public key; the file format varies 705 depending on the arcane command you issued, but generally the files 706 are DER or PEM-encoded. 708 The second step is to generate the certification request, which is 709 often referred to as a certificate signing request (CSR) or PKCS#10, 710 and to send it to the CA to be signed. To generate the CSR, you 711 issue some more arcane commands while logged into the router; using 712 the private key just generated to sign the certification request with 713 the algorithms specified in the main body of this document; the CSR 714 is signed to prove to the CA that the router has possession of the 715 private key (i.e., the signature is the proof-of-possession). The 716 output of the command is the CSR file; the file format varies 717 depending on the arcane command you issued, but generally the files 718 are DER or PEM-encoded. 720 The third step is to retrieve the signed CSR from the router and send 721 it to the CA. But before sending it, you need to also send the CA 722 the subject name and serial number for the router. The CA needs this 723 information to issue the certificate. How you get the CSR to the CA, 724 is beyond the scope of this document. While you are still connected 725 to the router, install the Trust Anchor (TA) for the root of the PKI. 726 At this point, you no longer need access to the router for BGPsec- 727 related initiation purposes. 729 The fourth step is for the CA to issue the certificate based on the 730 CSR you sent; the certificate will include the subject name, serial 731 number, public key, and other fields as well as being signed by the 732 CA. After the CA issues the certificate, the CA returns the 733 certificate, and posts the certificate to the RPKI repository. Check 734 that the certificate corresponds to the private key by verifying the 735 signature on the CSR sent to the CA; this is just a check to make 736 sure that the CA issued a certificate corresponding to the private 737 key on the router. 739 If generating the keys off-router (operator-driven), then the same 740 steps are used as the on-router key generation, (possibly with the 741 same arcane commands as those used in the on-router approach), but no 742 access to the router is needed the first three steps are done on an 743 administrative workstation: o Step 1: Generate key pair; o Step 2: 744 Create CSR and sign CSR with private key, and; o Step 3: Send CSR 745 file with the subject name and serial number to CA. 747 After the CA has returned the certificate and you have checked the 748 certificate, you need to put the private key and TA in the router. 749 Assuming the DIY approach, you will be using the CLI and accessing 750 the router either directly via the router's craft port or over the 751 network on an admin interface; if accessing the router over the 752 network make doubly sure it is done securely (i.e., use SSHv2) 753 because the private key is being moved over the network. At this 754 point, access to the router is no longer needed for BGPsec-related 755 initiation purposes. 757 NOTE: Regardless of the approach taken, the first three steps could 758 trivially be collapsed by a vendor-provided script to yield the 759 private key and the signed CSR. 761 Given a GUI-based vendor-assisted management console, then all of 762 these steps will likely be hidden behind pointing and clicking the 763 way through GPsec-enabling the router. 765 The scenarios described above require the operator to access each 766 router, which does not scale well to large networks. An alternative 767 would be to create an image, perform the necessary steps to get the 768 private key and trust anchor on the image, and then install the image 769 via a management protocol. 771 One final word of advice; certificates include a notAfter field that 772 unsurprisingly indicates when relying parties should no longer trust 773 the certificate. To avoid having routers with expired certificates 774 follow the recommendations in the Certification Policy (CP) [RFC6484] 775 and make sure to renew the certificate at least one week prior to the 776 notAfter date. Set a calendar reminder in order not to forget! 778 Authors' Addresses 780 Randy Bush 781 IIJ / Dragon Research Labs 782 5147 Crystal Springs 783 Bainbridge Island, Washington 98110 784 US 786 Email: randy@psg.com 788 Sean Turner 789 sn3rd 791 Email: sean@sn3rd.com 793 Keyur Patel 794 Arrcus, Inc. 796 Email: keyur@arrcus.com