idnits 2.17.1 draft-ietf-sidr-rtr-keying-07.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 (May 23, 2014) is 3619 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 407, 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: November 24, 2014 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 May 23, 2014 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-07 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 This Internet-Draft will expire on August 27, 2013. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 BGPsec-speaking routers are provisioned with private keys, which 57 allow them to digitally sign BGP messages. To verify the signature, 58 the public key, in the form of a certificate [I-D.ietf-sidr-bgpsec- 59 pki-profiles], is published in the RPKI (Resource Public Key 60 Infrastructure). This document describes two methods for 61 provisioning the necessary public-private key-pairs: router-driven 62 and operator-driven. 64 The difference between the two methods is where the keys are 65 generated: on the router in the router-driven method and elsewhere in 66 the operator-driven method. Routers are expected to support either 67 one, the other, or both methods to work in various deployment 68 environments. Some routers may not allow the private key to be off- 69 loaded while other routers may. Off-loading of private keys would 70 support swapping of routing engines which could then have the same 71 private key installed in the soon-to-be online engine that had 72 previously been installed in the soon-to-be removed card. 74 The remainder of this document describes how operators can use the 75 two methods to provision new and existing routers. 77 Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for 78 the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies the 79 algorithms used to generate the signature. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 85 be interpreted as described in RFC 2119 [RFC2119] only when they 86 appear in all upper case. They may also appear in lower or mixed 87 case as English words, without normative meaning. 89 Readers are assumed to be familiar with the BGPsec protocol [I- 90 D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the 91 RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key 92 Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I- 93 D.ietf-sidr-bgpsec-algs]. 95 3. Provisioning a New Router 96 Depending on the options supported by the new router, operators are 97 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 194 In the operator-driven method, the operator generates the 195 public/private key pair and installs the private key into the router 196 over the SSH-protected CLI session. Note that cut/copy and paste 197 operations for keys over a certain sizes are error-prone. 199 The operator uses RPKI management tools to generate the keys, the 200 PKCS#10 certification request, the certificate, and the PKCS#7 201 certification response, as well as publishing the certificate in the 202 Global RPKI. External network connectivity may be needed if the 203 certificate is to be published in the Global RPKI. 205 Along with the PKCS#7, the operator returns the private key. The 206 private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is 207 further encapsulated in CMS (Cryptographic Message Syntax) SignedData 208 [RFC5652], and signed by the AS's EE (End Entity) certificate. 210 The router SHOULD verify the signature of the encapsulated PKCS#8 to 211 ensure the returned private key did in fact come from the operator, 212 but this requires that the operator also provision via the CLI or 213 include in the SignedData the RPKI CA certificate and relevant AS's 214 EE certificate(s). The router should inform the operator whether or 215 not the signature validates to a trust anchor; this notification 216 mechanism is out of scope. 218 The router SHOULD extract the certificate from the PKCS#7 and verify 219 that the private key corresponds to the returned public key. The 220 router SHOULD inform the operator whether it successfully received 221 the certificate; this mechanism is out of scope. The router should 222 inform the operator whether or not the keys correspond; this 223 mechanism is out of scope. The router SHOULD also verify the 224 returned certificate back to a trust anchor, but to perform this 225 verification either the CA's certificate needs to be installed on the 226 router via the CLI or the CA's certificate needs to be returned along 227 with the router's certificate in the PKCS#7. The router SHOULD 228 inform the operator whether or not the signature validates to a trust 229 anchor; this notification mechanism is out of scope. After 230 performing these checks, the router need not retain the CA 231 certificate. 233 Note: The signature on the PKCS#8 and Certificate need not be made by 234 the same entity. Signing the PKCS#8, permits more advanced 235 configurations where the entity that generates the keys is not CA. 237 4. Key Management 239 An operator's responsibilities do not end after key generation, key 240 provisioning, certificate issuance, and certificate distribution. 241 They persist for as long as the operator wishes to operate the 242 BGPsec-speaking router. 244 Paramount to maintaining a router that can be a continuous BPGsec 245 speaker is ensuring that the router has a valid certificate at all 246 times. To ensure this, the operator needs to ensure the router 247 always has a non-expired certificate. That is the key used when BGP- 248 speaking always has an associated certificate whose expiry time is 249 after the current time. 251 Ensuring this is not terribly difficult but requires that either: 253 o The router has a mechanism to notify the operator that the 254 certificate has an impending expiration, and/or 256 o The operator notes the expiry time of the certificate and uses a 257 calendaring program to remind them of the expiry time. It is 258 advisable that the expiration warning happen well in advance of 259 the actual expiry time, and/or 261 o The RPKI CA warns the operaor of pending expiration, and/or 263 o Use some other kind of automated process to search for and track 264 the expiry times of router certificates. 266 Regardless of the technique used to track router certificate expiry 267 times, it is advisable to notify additional operators in the same 268 organization as the expiry time approaches thereby ensuring that the 269 forgetfulness of one operator does not affect the entire 270 organization. 272 Depending on inter-operator relationship, it may be appropriate to 273 notify a peer operator that one or more of their certificates are 274 about to expire. 276 Routers that support multiple private keys also greatly increase the 277 chance that routers can continuously speak BGPsec because the new 278 private key and certificate can be obtained prior to expiration of 279 the operational key. Obviously, the router needs to know when to 280 start using the new key. Once the new key is being used, having the 281 already distributed certificate ensures continuous operation. 283 Whether the certificate is rekeyed (i.e., different key in the 284 certificate with a new expiry time) or renewed (i.e., the same key in 285 the certificate with a new expiry time) depends on the key's lifetime 286 and operational use. Arguably, rekeying the router's BGPsec 287 certificate every time the certificate expires is more secure than 288 renewal because it limits the private key's exposure. However, if 289 the key is not compromised the certificate could be renewed as many 290 times as allowed by the operator's security policy. Routers that 291 support only one key can use renewal to ensure continuous operation, 292 assuming the certificate is renewed and distributed prior to the 293 operational's certificate expiry time. 295 Certain unfortunate circumstances exist when the operator will need 296 to revoke the router's BGPsec certificate. When this occurs, the 297 operator needs to use the RPKI CA system to revoke the certificate by 298 placing the router's BGPsec certificate on the CRL (Certificate 299 Revocation List) as well as rekeying the router's certificate. 301 When it is decided that an active router key is to be revoked, the 302 process of requesting the CA to revoke, the process of the CA 303 actually revoking the router's certificate, and then the process of 304 rekeying/renewing the router's certificate, (possibly distributing a 305 new key and certificate to the router), and distributing the status 306 takes time during which the operator must decide how they wish to 307 maintain continuity of operations, with or without the compromised 308 private key, or whether they wish to bring the router offline to 309 address the compromise. 311 Keeping the router operational and BGPsec-speaking is the ideal goal, 312 but if operational practices do not allow this then reconfiguring the 313 router to disabling BGPsec is likely preferred to bringing the router 314 offline. 316 Routers which support more than one private key, where one is 317 operational and the other(s) are soon-to-be-opertional, facilitate 318 revocation events because the operator can configure the router to 319 make a soon-to-be-operational key operational, request revocation of 320 the compromised key, and then make a new soon-to-be-operational key, 321 all hopefully without needing to take offline or reboot the router. 322 For routers which support only one operational key, the operators 323 should create or install the new private key, and then request 324 revocation of the compromised private key. 326 5. Other Use Cases 328 Current router code generates private keys for uses such as SSH, but 329 the private keys may not be seen or off-loaded via the SSH-protected 330 CLI session or any other means. While this is good security, it 331 creates difficulties when a routing engine or whole router must be 332 replaced in the field and all software which accesses the router must 333 be updated with the new keys. Also, any network based initial contact 334 with a new routing engine requires trust in the public key presented 335 on first contact. 337 To allow operators to quickly replace routers without requiring 338 update and distribution of the corresponding public keys in the RPKI, 339 routers SHOULD allow the private BGPsec key to be off-loaded via the 340 SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the 341 operator upload the old private key via the mechanism used for 342 operator-generated keys, see Section 3.2. 344 6. Security Considerations 346 Operator-generated keys could be intercepted in transport and the 347 recipient router would have no way of knowing a substitution had been 348 made or that the key had been disclosed by a monkey in the middle. 349 Hence transport security is strongly RECOMMENDED. As noted in 350 Section 3, the level of security provided by the transport security 351 SHOULD be commensurate with the BGPsec key. Additionally, operators 352 SHOULD ensure the transport security implementation is up to date and 353 addresses all known implementation bugs. 355 All generated key pairs MUST be generated from a good source of non- 356 deterministic random input [RFC4086] and the private key MUST be 357 protected in a secure fashion. Disclosure of the private key leads 358 to masquerade [RFC4949]. The local storage format for the private 359 key is a local matter. 361 Though the CA's certificate is installed on the router and used to 362 verify the returned certificate is in fact signed by the CA, the 363 revocation status of the CA's certificate is not checked. The 364 operator MUST ensure that installed CA certificate is valid. 366 Operators need to manage their SSH keys to ensure only those 367 authorized to access the router may do so. As employees no longer 368 need access to the router, their keys SHOULD be removed from the 369 router. 371 7. IANA Considerations 373 This document has no IANA Considerations. 375 8. References 377 8.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 383 "Randomness Requirements for Security", BCP 106, RFC 4086, 384 June 2005. 386 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 387 Transport Layer Protocol", RFC 4253, January 2006. 389 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 390 RFC 5652, September 2009. 392 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 393 2010. 395 [I-D.ietf-sidr-bgpsec-algs] 396 Turner, S., "BGP Algorithms, Key Formats, & Signature 397 Formats", draft-ietf-sidr-bgpsec-algs (work in progress). 399 [I-D.ietf-sidr-bgpsec-pki-profiles] 400 Reynolds, M., Turner, S., and S. Kent, "A Profile for 401 BGPSEC Router Certificates, Certificate Revocation Lists, 402 and Certification Requests", 403 draft-ietf-sidr-bgpsec-pki-profiles (work in progress). 405 8.2. Informative References 407 [I-D.ietf-sidr-bgpsec-overview] 408 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 409 draft-ietf-sidr-bgpsec-overview (work in progress). 411 [I-D.ietf-sidr-bgpsec-protocol] 412 Lepinski, M., "BGPSEC Protocol Specification", 413 draft-ietf-sidr-bgpsec-protocol (work in progress). 415 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 416 Infrastructure Operational Protocols: FTP and HTTP", 417 RFC 2585, May 1999. 419 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 420 Transport Layer Protocol", RFC 4253, January 2006. 422 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 423 36, RFC 4949, August 2007. 425 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 426 Secure Shell Transport Layer Protocol", RFC 5647, August 427 2009. 429 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 430 Integration in the Secure Shell Transport Layer", 431 RFC 5656, December 2009. 433 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 434 Mail Extensions (S/MIME) Version 3.2 Message 435 Specification", RFC 5751, January 2010. 437 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 438 August 2010. 440 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 441 Shell Authentication", RFC 6187, March 2011. 443 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 444 Base Notifications", RFC 6470, February 2012. 446 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 447 Secure Internet Routing", RFC 6480, February 2012. 449 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 450 Policy (CP) for the Resource Public Key Infrastructure 451 (RPKI)", BCP 173, RFC 6484, February 2012. 453 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 454 Verification for the Secure Shell (SSH) Transport Layer 455 Protocol", RFC 6668, July 2012. 457 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 458 "Enrollment over Secure Transport", RFC 7030, October 459 2013. 461 Authors' Addresses 463 Sean Turner 464 IECA, Inc. 465 3057 Nutley Street, Suite 106 466 Fairfax, Virginia 22031 467 US 469 Email: turners@ieca.com 471 Keyur Patel 472 Cisco Systems 473 170 West Tasman Drive 474 San Jose, CA 95134 475 US 477 Email: keyupate@cisco.com 479 Randy Bush 480 Internet Initiative Japan, Inc. 481 5147 Crystal Springs 482 Bainbridge Island, Washington 98110 483 US 485 Phone: +1 206 780 0431 x1 486 Email: randy@psg.com