idnits 2.17.1 draft-ietf-sidr-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 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 29, 2014) is 3650 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) == Missing Reference: 'I-D.ietf-pkix-est' is mentioned on line 167, but not defined == Missing Reference: 'RFC6484' is mentioned on line 190, but not defined == Unused Reference: 'RFC5915' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 439, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5915 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 8 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: October 31, 2014 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 April 29, 2014 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-05 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-drive 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) [I-D.ietf-pkix-est]. 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 is 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 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 5. Other Use Cases 303 Current router code generates private keys for uses such as SSH, but 304 the private keys may not be seen or off-loaded via the SSH-protected 305 CLI session or any other means. While this is good security, it 306 creates difficulties when a routing engine or whole router must be 307 replaced in the field and all software which accesses the router must 308 be updated with the new keys. Also, any network based initial contact 309 with a new routing engine requires trust in the public key presented 310 on first contact. 312 To allow operators to quickly replace routers without requiring 313 update and distribution of the corresponding public keys in the RPKI, 314 routers SHOULD allow the private BGPsec key to be off-loaded via the 315 SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the 316 operator upload the old private key via the mechanism used for 317 operator-generated keys, see Section 3.2. 319 6. Security Considerations 321 Operator-generated keys could be intercepted in transport and the 322 recipient router would have no way of knowing a substitution had been 323 made or that the key had been disclosed by a monkey in the middle. 324 Hence transport security is strongly RECOMMENDED. As noted in 325 Section 3, the level of security provided by the transport security 326 SHOULD be commensurate with the BGPsec key. Additionally, operators 327 SHOULD ensure the transport security implementation is up to date and 328 addresses all known implementation bugs. 330 All generated key pairs MUST be generated from a good source of non- 331 deterministic random input [RFC4086] and the private key MUST be 332 protected in a secure fashion. Disclosure of the private key leads 333 to masquerade [RFC4949]. The local storage format for the private 334 key is a local matter. 336 Though the CA's certificate is installed on the router and used to 337 verify the returned certificate is in fact signed by the CA, the 338 revocation status of the CA's certificate is not checked. The 339 operator MUST ensure that installed CA certificate is valid. 341 Operators need to manage their SSH keys to ensure only those 342 authorized to access the router may do so. As employees no longer 343 need access to the router, their keys SHOULD be removed from the 344 router. 346 7. IANA Considerations 348 This document has no IANA Considerations. 350 8. References 352 8.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 358 "Randomness Requirements for Security", BCP 106, RFC 4086, 359 June 2005. 361 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 362 Transport Layer Protocol", RFC 4253, January 2006. 364 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 365 RFC 5652, September 2009. 367 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 368 Structure", RFC 5915, June 2010. 370 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 371 2010. 373 [I-D.ietf-sidr-bgpsec-algs] 374 Turner, S., "BGP Algorithms, Key Formats, & Signature 375 Formats", draft-ietf-sidr-bgpsec-algs (work in progress). 377 [I-D.ietf-sidr-bgpsec-pki-profiles] 378 Reynolds, M., Turner, S., and S. Kent, "A Profile for 379 BGPSEC Router Certificates, Certificate Revocation Lists, 380 and Certification Requests", 381 draft-ietf-sidr-bgpsec-pki-profiles (work in progress). 383 8.2. Informative References 385 [I-D.ietf-sidr-bgpsec-overview] 386 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 387 draft-ietf-sidr-bgpsec-overview (work in progress). 389 [I-D.ietf-sidr-bgpsec-protocol] 390 Lepinski, M., "BGPSEC Protocol Specification", 391 draft-ietf-sidr-bgpsec-protocol (work in progress). 393 [IEEE-802.3] 394 ISO/IEC 8802-3 Information technology - 395 Telecommunications and information exchange between 396 systems - Local and metropolitan area networks - 397 Common specifications - Part 3: Carrier Sense 398 Multiple Access with Collision Detection (CSMA/CD) 399 Access Method and Physical Layer Specifications, 2008. 401 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 402 Infrastructure Operational Protocols: FTP and HTTP", 403 RFC 2585, May 1999. 405 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 406 Transport Layer Protocol", RFC 4253, January 2006. 408 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 409 36, RFC 4949, August 2007. 411 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 412 Secure Shell Transport Layer Protocol", RFC 5647, August 413 2009. 415 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 416 Integration in the Secure Shell Transport Layer", 417 RFC 5656, December 2009. 419 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 420 Mail Extensions (S/MIME) Version 3.2 Message 421 Specification", RFC 5751, January 2010. 423 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 424 August 2010. 426 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 427 Shell Authentication", RFC 6187, March 2011. 429 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 430 Base Notifications", RFC 6470, February 2012. 432 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 433 Secure Internet Routing", RFC 6480, February 2012. 435 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 436 Verification for the Secure Shell (SSH) Transport Layer 437 Protocol", RFC 6668, July 2012. 439 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 440 "Enrollment over Secure Transport", RFC 7030, October 441 2013. 443 Authors' Addresses 445 Sean Turner 446 IECA, Inc. 447 3057 Nutley Street, Suite 106 448 Fairfax, Virginia 22031 449 US 451 Email: turners@ieca.com 453 Keyur Patel 454 Cisco Systems 455 170 West Tasman Drive 456 San Jose, CA 95134 457 US 459 Email: keyupate@cisco.com 461 Randy Bush 462 Internet Initiative Japan, Inc. 463 5147 Crystal Springs 464 Bainbridge Island, Washington 98110 465 US 467 Phone: +1 206 780 0431 x1 468 Email: randy@psg.com