idnits 2.17.1 draft-ietf-sidr-rtr-keying-09.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 (July 20, 2015) is 3175 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) == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 406, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Working Group S. Turner 3 Internet-Draft IECA, Inc. 4 Intended status: BCP K. Patel 5 Expires: January 21, 2016 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 July 20, 2015 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-09 13 Abstract 15 BGPsec-speaking routers are provisioned with private keys to sign BGP 16 messages; the corresponding public keys are published in the global 17 RPKI (Resource Public Key Infrastructure) thereby enabling 18 verification of BGPsec messages. This document describes two ways of 19 provisioning the public-private key-pairs: router-driven and 20 operator-driven. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 BGPsec-speaking routers are provisioned with private keys, which 55 allow them to digitally sign BGP messages. To verify the signature, 56 the public key, in the form of a certificate [I-D.ietf-sidr-bgpsec- 57 pki-profiles], is published in the RPKI (Resource Public Key 58 Infrastructure). This document describes two methods for 59 provisioning the necessary public-private key-pairs: router-driven 60 and operator-driven. 62 The difference between the two methods is where the keys are 63 generated: on the router in the router-driven method and elsewhere in 64 the operator-driven method. Routers are expected to support either 65 one, the other, or both methods to work in various deployment 66 environments. Some routers may not allow the private key to be off- 67 loaded while other routers may. Off-loading of private keys would 68 support swapping of routing engines which could then have the same 69 private key installed in the soon-to-be online engine that had 70 previously been installed in the soon-to-be removed card. 72 The remainder of this document describes how operators can use the 73 two methods to provision new and existing routers. 75 Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for 76 the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies the 77 algorithms used to generate the signature. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 83 be interpreted as described in RFC 2119 [RFC2119] only when they 84 appear in all upper case. They may also appear in lower or mixed 85 case as English words, without normative meaning. 87 Readers are assumed to be familiar with the BGPsec protocol [I- 88 D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the 89 RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key 90 Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I- 91 D.ietf-sidr-bgpsec-algs]. 93 3. Provisioning a New Router 95 Depending on the options supported by the new router, operators are 96 free to use either the router-driven or operator-driven methods. 98 Regardless of the method chosen, operators first establish a secure 99 communication channel (e.g., via SSH (Secure Shell)) between the 100 operator's management platform and the router to allow the operator 101 to securely use the Command Line Interface (CLI). How this channel 102 is established is router-specific and is not in scope of this 103 document. Though other configuration mechanisms might be used, e.g. 104 NetConf (see [RFC6470]), in the remainder of this document, the 105 secure communication channel between the server and the router is 106 assumed to be an SSH-protected CLI. 108 Encryption, integrity, authentication, and key exchange algorithms 109 used by the secure communication channel SHOULD be of comparable 110 strength to BGPsec keys, which currently is 128-bit, or stronger than 111 BGPsec keys. In other words for the encryption algorithm, do not use 112 export grade crypto (40-56 bits of security), do not use Triple DES 113 (112 bits of security), do use something like or better than AES-128: 114 aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647]; for integrity 115 use something like hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM 116 [RFC5647]; for authentication use something like ecdsa-sha2-nistp256 117 [RFC5656], and; for key exchange use something like ecdh-sha2- 118 nistp256 [RFC5656]. 120 Note that some routers support the use of public key certificates and 121 SSH. The certificates used for the SSH session are different than 122 the certificates used for BGPsec. The certificates used with SSH 123 should also enable a level of security commensurate with BGPsec keys; 124 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 125 authentication. 127 3.1. Router-Generated Keys 129 In the router-driven method, once the SSH-protected CLI session is 130 established between the operator and the router, the operator issues 131 a command, or commands, for the router to generate the public/private 132 key pair, to generate the PKCS#10 request, and to sign the PKCS#10 133 with the private key. Once generated, the PKCS#10, which includes 134 the public key the router wants certified, is transmitted to the RPKI 135 CA for the CA to certify. This can be via a number of means, two of 136 which might be as follows: 138 o Through the SSH-protected CLI session with the operator's RPKI 139 management platform: The operator off-loads the PKCS#10 and 140 uploads the request to the CA. If the CA is operated by an 141 external entity, external network connectivity likely is 142 required. 144 o Between the router and the CA: The operator, through a command or 145 commands, prompts the router to send/transfer the PKCS#10 request 146 to the CA over the network. Obviously for this to work, the 147 router requires network connectivity with the CA and if the CA is 148 operated by an external entity external network connectivity may 149 be required. 151 After the CA certifies the key, it does two things: 153 o Publishes the certificate in the Global RPKI. The CA must have 154 connectivity to the relevant publication point, which in turn 155 must have external network connectivity as it is part of the 156 Global RPKI. 158 o Returns the certificate to the operator's management station or 159 to the router, normally packaged in a PKCS#7, using the 160 corresponding method by which it received the certificate 161 request. 163 With network connectivity, the router and CA can exchange the 164 certificate request and the certificate using the application/pkcs10 165 media type [RFC5967] and application/pkcs7-mime [RFC5751], 166 respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST 167 (Enrollment over Secure Transport) [RFC7030]. 169 The router SHOULD extract the certificate from the PCKCS#7 and verify 170 that the private key it holds corresponds to the returned public key. 171 The router SHOULD inform the operator that the certificate was 172 received; by some mechanism which is out of scope of this document. 173 The router SHOULD inform the operator whether or not the keys 174 correspond, again by a mechanism which is out of scope for this 175 document. 177 The router SHOULD also verify that the returned certificate validates 178 back to a trust anchor. To perform this verification either the CA's 179 certificate needs to be installed on the router via the CLI or the 180 CA's certificate needs to be returned along with the router's 181 certificate in the PKCS#7. The router SHOULD inform the operator 182 whether or not the signature validates to a trust anchor; this 183 notification mechanism is out of scope. After performing these 184 checks, the router need not retain the CA's certificate because the 185 certificate is not transmitted as part of BGPsec messages. 187 Note that even if the operator cannot extract the private key from 188 the router, this signature still provides a linkage between a private 189 key and a router. That is the server can verify the proof of 190 possession (POP), as required by [RFC6484]. 192 3.2. Operator-Generated Keys 193 In the operator-driven method, the operator generates the 194 public/private key pair and installs the private key into the router 195 over the SSH-protected CLI session. Note that cut/copy and paste 196 operations for keys over a certain sizes are error-prone. 198 The operator uses RPKI management tools to generate the keys, the 199 PKCS#10 certification request, the certificate, and the PKCS#7 200 certification response, as well as publishing the certificate in the 201 Global RPKI. External network connectivity may be needed if the 202 certificate is to be published in the Global RPKI. 204 Along with the PKCS#7, the operator returns the private key. The 205 private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is 206 further encapsulated in CMS (Cryptographic Message Syntax) SignedData 207 [RFC5652], and signed by the AS's EE (End Entity) certificate. 209 The router SHOULD verify the signature of the encapsulated PKCS#8 to 210 ensure the returned private key did in fact come from the operator, 211 but this requires that the operator also provision via the CLI or 212 include in the SignedData the RPKI CA certificate and relevant AS's 213 EE certificate(s). The router should inform the operator whether or 214 not the signature validates to a trust anchor; this notification 215 mechanism is out of scope. 217 The router SHOULD extract the certificate from the PKCS#7 and verify 218 that the private key corresponds to the returned public key. The 219 router SHOULD inform the operator whether it successfully received 220 the certificate; this mechanism is out of scope. The router should 221 inform the operator whether or not the keys correspond; this 222 mechanism is out of scope. The router SHOULD also verify the 223 returned certificate back to a trust anchor, but to perform this 224 verification either the CA's certificate needs to be installed on the 225 router via the CLI or the CA's certificate needs to be returned along 226 with the router's certificate in the PKCS#7. The router SHOULD 227 inform the operator whether or not the signature validates to a trust 228 anchor; this notification mechanism is out of scope. After 229 performing these checks, the router need not retain the CA 230 certificate. 232 Note: The signature on the PKCS#8 and Certificate need not be made by 233 the same entity. Signing the PKCS#8, permits more advanced 234 configurations where the entity that generates the keys is not CA. 236 4. Key Management 238 An operator's responsibilities do not end after key generation, key 239 provisioning, certificate issuance, and certificate distribution. 240 They persist for as long as the operator wishes to operate the 241 BGPsec-speaking router. 243 Paramount to maintaining a router that can be a continuous BPGsec 244 speaker is ensuring that the router has a valid certificate at all 245 times. To ensure this, the operator needs to ensure the router 246 always has a non-expired certificate. That is the key used when BGP- 247 speaking always has an associated certificate whose expiry time is 248 after the current time. 250 Ensuring this is not terribly difficult but requires that either: 252 o The router has a mechanism to notify the operator that the 253 certificate has an impending expiration, and/or 255 o The operator notes the expiry time of the certificate and uses a 256 calendaring program to remind them of the expiry time. It is 257 advisable that the expiration warning happen well in advance of 258 the actual expiry time, and/or 260 o The RPKI CA warns the operaor of pending expiration, and/or 262 o Use some other kind of automated process to search for and track 263 the expiry times of router certificates. 265 Regardless of the technique used to track router certificate expiry 266 times, it is advisable to notify additional operators in the same 267 organization as the expiry time approaches thereby ensuring that the 268 forgetfulness of one operator does not affect the entire 269 organization. 271 Depending on inter-operator relationship, it may be appropriate to 272 notify a peer operator that one or more of their certificates are 273 about to expire. 275 Routers that support multiple private keys also greatly increase the 276 chance that routers can continuously speak BGPsec because the new 277 private key and certificate can be obtained prior to expiration of 278 the operational key. Obviously, the router needs to know when to 279 start using the new key. Once the new key is being used, having the 280 already distributed certificate ensures continuous operation. 282 Whether the certificate is rekeyed (i.e., different key in the 283 certificate with a new expiry time) or renewed (i.e., the same key in 284 the certificate with a new expiry time) depends on the key's lifetime 285 and operational use. Arguably, rekeying the router's BGPsec 286 certificate every time the certificate expires is more secure than 287 renewal because it limits the private key's exposure. However, if 288 the key is not compromised the certificate could be renewed as many 289 times as allowed by the operator's security policy. Routers that 290 support only one key can use renewal to ensure continuous operation, 291 assuming the certificate is renewed and distributed prior to the 292 operational's certificate expiry time. 294 Certain unfortunate circumstances exist when the operator will need 295 to revoke the router's BGPsec certificate. When this occurs, the 296 operator needs to use the RPKI CA system to revoke the certificate by 297 placing the router's BGPsec certificate on the CRL (Certificate 298 Revocation List) as well as rekeying the router's certificate. 300 When it is decided that an active router key is to be revoked, the 301 process of requesting the CA to revoke, the process of the CA 302 actually revoking the router's certificate, and then the process of 303 rekeying/renewing the router's certificate, (possibly distributing a 304 new key and certificate to the router), and distributing the status 305 takes time during which the operator must decide how they wish to 306 maintain continuity of operations, with or without the compromised 307 private key, or whether they wish to bring the router offline to 308 address the compromise. 310 Keeping the router operational and BGPsec-speaking is the ideal goal, 311 but if operational practices do not allow this then reconfiguring the 312 router to disabling BGPsec is likely preferred to bringing the router 313 offline. 315 Routers which support more than one private key, where one is 316 operational and the other(s) are soon-to-be-opertional, facilitate 317 revocation events because the operator can configure the router to 318 make a soon-to-be-operational key operational, request revocation of 319 the compromised key, and then make a new soon-to-be-operational key, 320 all hopefully without needing to take offline or reboot the router. 321 For routers which support only one operational key, the operators 322 should create or install the new private key, and then request 323 revocation of the compromised private key. 325 5. Other Use Cases 327 Current router code generates private keys for uses such as SSH, but 328 the private keys may not be seen or off-loaded via the SSH-protected 329 CLI session or any other means. While this is good security, it 330 creates difficulties when a routing engine or whole router must be 331 replaced in the field and all software which accesses the router must 332 be updated with the new keys. Also, any network based initial contact 333 with a new routing engine requires trust in the public key presented 334 on first contact. 336 To allow operators to quickly replace routers without requiring 337 update and distribution of the corresponding public keys in the RPKI, 338 routers SHOULD allow the private BGPsec key to be off-loaded via the 339 SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the 340 operator upload the old private key via the mechanism used for 341 operator-generated keys, see Section 3.2. 343 6. Security Considerations 345 Operator-generated keys could be intercepted in transport and the 346 recipient router would have no way of knowing a substitution had been 347 made or that the key had been disclosed by a monkey in the middle. 348 Hence transport security is strongly RECOMMENDED. As noted in 349 Section 3, the level of security provided by the transport security 350 SHOULD be commensurate with the BGPsec key. Additionally, operators 351 SHOULD ensure the transport security implementation is up to date and 352 addresses all known implementation bugs. 354 All generated key pairs MUST be generated from a good source of non- 355 deterministic random input [RFC4086] and the private key MUST be 356 protected in a secure fashion. Disclosure of the private key leads 357 to masquerade [RFC4949]. The local storage format for the private 358 key is a local matter. 360 Though the CA's certificate is installed on the router and used to 361 verify the returned certificate is in fact signed by the CA, the 362 revocation status of the CA's certificate is not checked. The 363 operator MUST ensure that installed CA certificate is valid. 365 Operators need to manage their SSH keys to ensure only those 366 authorized to access the router may do so. As employees no longer 367 need access to the router, their keys SHOULD be removed from the 368 router. 370 7. IANA Considerations 372 This document has no IANA Considerations. 374 8. References 376 8.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 382 "Randomness Requirements for Security", BCP 106, RFC 4086, 383 June 2005. 385 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 386 Transport Layer Protocol", RFC 4253, January 2006. 388 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 389 RFC 5652, September 2009. 391 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 392 2010. 394 [I-D.ietf-sidr-bgpsec-algs] 395 Turner, S., "BGP Algorithms, Key Formats, & Signature 396 Formats", draft-ietf-sidr-bgpsec-algs (work in progress). 398 [I-D.ietf-sidr-bgpsec-pki-profiles] 399 Reynolds, M., Turner, S., and S. Kent, "A Profile for 400 BGPSEC Router Certificates, Certificate Revocation Lists, 401 and Certification Requests", 402 draft-ietf-sidr-bgpsec-pki-profiles (work in progress). 404 8.2. Informative References 406 [I-D.ietf-sidr-bgpsec-overview] 407 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 408 draft-ietf-sidr-bgpsec-overview (work in progress). 410 [I-D.ietf-sidr-bgpsec-protocol] 411 Lepinski, M., "BGPSEC Protocol Specification", 412 draft-ietf-sidr-bgpsec-protocol (work in progress). 414 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 415 Infrastructure Operational Protocols: FTP and HTTP", 416 RFC 2585, May 1999. 418 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 419 Transport Layer Protocol", RFC 4253, January 2006. 421 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 422 36, RFC 4949, August 2007. 424 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 425 Secure Shell Transport Layer Protocol", RFC 5647, August 426 2009. 428 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 429 Integration in the Secure Shell Transport Layer", 430 RFC 5656, December 2009. 432 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 433 Mail Extensions (S/MIME) Version 3.2 Message 434 Specification", RFC 5751, January 2010. 436 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 437 August 2010. 439 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 440 Shell Authentication", RFC 6187, March 2011. 442 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 443 Base Notifications", RFC 6470, February 2012. 445 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 446 Secure Internet Routing", RFC 6480, February 2012. 448 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 449 Policy (CP) for the Resource Public Key Infrastructure 450 (RPKI)", BCP 173, RFC 6484, February 2012. 452 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 453 Verification for the Secure Shell (SSH) Transport Layer 454 Protocol", RFC 6668, July 2012. 456 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 457 "Enrollment over Secure Transport", RFC 7030, October 458 2013. 460 Authors' Addresses 462 Sean Turner 463 IECA, Inc. 464 3057 Nutley Street, Suite 106 465 Fairfax, Virginia 22031 466 US 468 Email: turners@ieca.com 470 Keyur Patel 471 Cisco Systems 472 170 West Tasman Drive 473 San Jose, CA 95134 474 US 476 Email: keyupate@cisco.com 478 Randy Bush 479 Internet Initiative Japan, Inc. 480 5147 Crystal Springs 481 Bainbridge Island, Washington 98110 482 US 484 Phone: +1 206 780 0431 x1 485 Email: randy@psg.com