idnits 2.17.1 draft-ietf-sidr-rtr-keying-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2013) is 3879 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: 'RFC6484' is mentioned on line 156, but not defined == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3' is defined on line 299, 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 (~~), 4 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: March 16, 2014 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 September 12, 2013 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-02 13 Abstract 15 BGPsec-speaking routers must be provisioned with private keys and the 16 corresponding public key must be published in the global RPKI 17 (Resource Public Key Infrastructure). This document describes two 18 ways of provisioning public/private keys, router-driven and operator- 19 driven. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 27, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 BGPsec-speaking routers must be provisioned with private keys and the 56 corresponding public key must be published in the global RPKI 57 (Resource Public Key Infrastructure). The public key is published in 58 the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki- 59 profiles]. This document describes two methods for generating the 60 necessary public/private key-pair: router-driven 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 model. Different equipment necessitates the two 65 methods. Some equipment doesn't allow the private key to be off- 66 loaded while other equipment does. Off-loading private keys supports 67 hot-swappable routers that need to have the same private key needs 68 installed in the soon-to-be online router that was installed in the 69 soon-to-be offline router. 71 The remainder of this document describes how operators can use the 72 two methods to provision new and existing routers. 74 Note that in both models, the key pair is for algorithms defined in 75 [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on 76 the P-256 curve. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in RFC 83 2119 [RFC2119]. 85 It is assumed that the reader understands BGPsec [I-D.ietf-sidr- 86 bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480], 87 and [I-D.ietf-sidr-bgpsec-pki-profiles]. 89 3. Provisioning a New Router 91 When commissioning a new router, operators may use either the router- 92 driven or operator-drive methods. Regardless of the method chosen, 93 the operator first needs to establish a secure communication channel 94 with the router. Operators use the router-specific procedures to 95 enable them to connect to the router via an SSH session. 97 The SSH encryption, integrity, authentication, and key exchange 98 mechanisms used by the router and operator SHOULD be of comparable 99 strength to BGPSEC key, which is 128-bit strength, e.g., for 100 encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for 101 integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647], 102 for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key 103 exchange: ecdh-sha2-nistp256 [RFC5656]. 105 Note that if the router supports public key certificates at this 106 point, which would have had to have been provided by the operator at 107 this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 108 authentication. The SSH certificate, profiled in [RFC6187], would be 109 different than the BGPSEC certificate. 111 3.1. Router-Generated Keys 113 In the router-driven method, once an SSH session is established 114 between the operator and the router the operator issues a command, or 115 commands, to generate the public/private key pair on the router, to 116 generate the PKCS#10 request that includes the router number and 117 public key, and to sign the PKCS#10 with the private key. [I-D.ietf- 118 sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10 119 request and the algorithm used to generate the signature is specified 120 in [I-D.ietf-sidr-bgpsec-algs]. 122 The PKCS#10 request, which includes the public key the router wants 123 certified, can be directly transferred to the RPKI CA over the 124 Ethernet port if the router supports protocols such as FTP and HTTP 125 [RFC2585] using the application/pkcs10 media type [RFC5967] or EST 126 (Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA 127 returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki- 128 profiles], which includes the certificate, and uploads the 129 certificate to the global RPKI. The response can be returned using 130 the application/pkcs7-mime media type [RFC5751] if the router 131 supports protocols such as FTP and HTTP. 133 The PKCS#10 request can also be indirectly transferred to the RPKI CA 134 through the operator. The operator off-loads the PKCS#10 and uploads 135 the request to their RPKI software management tools. The tools 136 create and publish the certificate for the public key, and return the 137 PKCS#7 to the router. 139 The router SHOULD extract the certificate from the PCKCS#7 and verify 140 that the private key corresponds to the returned public key. The 141 router SHOULD inform the operator that it has successfully received 142 its certificate; this mechanism is out of scope. When the keys do 143 not correspond, the router SHOULD inform the operator; this mechanism 144 is out of scope. The router SHOULD also verify the returned 145 certificate back to a trust anchor, but to perform this verification 146 either the CA's certificate needs to be installed on the router via 147 the CLI or the CA's certificate needs to be returned along with the 148 router's certificate in the PKCS#7. The router SHOULD inform the 149 operator if the signature does not validate to a trust anchor; this 150 notification mechanism is out of scope. After performing these 151 checks, the router need not retain the certificate. 153 Note that even if the operator can not get the private key off the 154 router this signature still provides a linkage between a private key 155 and a router. That is the server can verify the proof of possession 156 (POP), as required by [RFC6484]. 158 3.2. Operator-Generated Keys 160 In the operator-driven method, the operator generates the private key 161 and it is installed over the SSH connection established between the 162 operator and the router. Note that cut/copy and paste operations for 163 keys over a certain sizes is error-prone. 165 The operator uses their RPKI management tools to generate the keys, 166 the PKCS#10 certification request, the certificate, and the PKCS#7 167 certification response as well as publish the certificate for the 168 public key in the global RPKI. The private key MUST support the 169 algorithm specified in [I-D.ietf-sidr-bgpsec-algs], which for ECDSA 170 is specified in [RFC5915]. The PKCS#10 and PKCS#7 are as specified 171 in [I-D.ietf-sidr-bgpsec-pki-profiles]. 173 Along with the PKCS#7, the operator returns the private key. The 174 private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is 175 further encapsulated in a CMS (Cryptographic Message Syntax) 176 SignedData [RFC5652], and signed by the operator's EE certificate. 178 The router SHOULD verify the signature on the encapsulated PKCS#8 to 179 ensure the returned private key in fact came from the operator, but 180 this requires that the operator also provision via the CLI or include 181 in the SignedData the RPKI CA certificates and operator's EE 182 certificates. The router SHOULD inform the operator if the signature 183 does not validate to a trust anchor; this notification mechanism is 184 out of scope. 186 The router SHOULD extract the certificate for the PKCS#7 and verify 187 that the private key corresponds to the returned public key. The 188 router SHOULD inform the operator that it has successfully received 189 its certificate; this mechanism is out of scope. When the keys do 190 not correspond, the router SHOULD inform the operator; this mechanism 191 is out of scope. The router SHOULD also verify the returned 192 certificate back to a trust anchor, but to perform this verification 193 either the CA's certificate needs to be installed on the router via 194 the CLI or the CA's certificate needs to be returned along with the 195 router's certificate in the PKCS#7. The router SHOULD inform the 196 operator if the signature does not validate to a trust anchor; this 197 notification mechanism is out of scope. After performing these 198 checks, the router need not retain the certificate. 200 5. Other Use Cases 202 Current router code generates private keys for uses such as SSH, but 203 the private keys may not be seen or off-loaded via CLI or any other 204 means. While this is good security, it creates difficulties when a 205 routing engine or whole router must be replaced in the field and all 206 software which accesses the router must be updated with the new keys. 207 Also, the initial contact with a new routing engine requires trust in 208 the public key presented on first contact. 210 To allow operators to quickly replace routers without requiring 211 update and distribution of the corresponding public keys in the RPKI, 212 routers SHOULD allow the private BGPsec key to be off-loaded via the 213 CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator 214 upload the old private key via the mechanism used for operator- 215 generated keys, see Section 3.2. 217 6. Security Considerations 219 Operator-generated keys could be intercepted in transport and the 220 recipient router would have no way of knowing a substitution had been 221 made or that the key had been disclosed by a monkey in the middle. 222 Hence transport security is strongly RECOMMENDED. As noted in 223 Section 3, the level of security provided by the transport security 224 SHOULD be commensurate with the BGPsec key. Additionally, operators 225 SHOULD ensure the transport security implementation is up to date and 226 addresses all known implementation bugs. 228 All generated key pairs MUST be generated from a good source of non- 229 deterministic random input [RFC4086] and the private key MUST be 230 protected in a secure fashion. Disclosure of the private key leads 231 to masquerade [RFC4949]. The local storage format for the private 232 key is a local matter. 234 Though the CA's certificate is installed on the router and used to 235 verify the returned certificate is in fact signed by the CA, the 236 revocation status of the CA's certificate is not checked. The 237 operator MUST ensure that installed CA certificate is valid. 239 Operators need to manage their SSH keys to ensure only those 240 authorized to access the router can. As employees no longer need 241 access to the router, their keys SHOULD be removed from the router. 243 7. IANA Considerations 245 This document has no IANA Considerations. 247 8. References 249 8.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 255 "Randomness Requirements for Security", BCP 106, RFC 4086, 256 June 2005. 258 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 259 Transport Layer Protocol", RFC 4253, January 2006. 261 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 262 RFC 5652, September 2009. 264 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 265 Structure", RFC 5915, June 2010. 267 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 268 2010. 270 [I-D.ietf-sidr-bgpsec-algs] 271 Turner, S., "BGP Algorithms, Key Formats, & Signature 272 Formats", draft-ietf-sidr-bgpsec-algs (work in progress), 273 March 2013. 275 [I-D.ietf-sidr-bgpsec-pki-profiles] 276 Reynolds, M., Turner, S., and S. Kent, "A Profile for 277 BGPSEC Router Certificates, Certificate Revocation Lists, 278 and Certification Requests", 279 draft-ietf-sidr-bgpsec-pki-profiles (work in progress), 280 April 2013. 282 8.2. Informative References 284 [I-D.ietf-sidr-bgpsec-overview] 285 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 286 draft-ietf-sidr-bgpsec-overview (work in progress), 287 July 2013. 289 [I-D.ietf-sidr-bgpsec-protocol] 290 Lepinski, M., "BGPSEC Protocol Specification", 291 draft-ietf-sidr-bgpsec-protocol (work in progress), 292 February 2013. 294 [I-D.ietf-pkix-est] 295 Pritikin, M, Yee, P., and D. Harkins "Enrollment over 296 Secure Transport", draft-ietf-pkix-est (work in progress), 297 August 2013. 299 [IEEE-802.3] 300 ISO/IEC 8802-3 Information technology - 301 Telecommunications and information exchange between 302 systems - Local and metropolitan area networks - 303 Common specifications - Part 3: Carrier Sense 304 Multiple Access with Collision Detection (CSMA/CD) 305 Access Method and Physical Layer Specifications, 2008. 307 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 308 Infrastructure Operational Protocols: FTP and HTTP", 309 RFC 2585, May 1999. 311 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 312 Transport Layer Protocol", RFC 4253, January 2006. 314 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 315 36, RFC 4949, August 2007. 317 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 318 Secure Shell Transport Layer Protocol", RFC 5647, August 319 2009. 321 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 322 Integration in the Secure Shell Transport Layer", 323 RFC 5656, December 2009. 325 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 326 Mail Extensions (S/MIME) Version 3.2 Message 327 Specification", RFC 5751, January 2010. 329 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 330 August 2010. 332 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 333 Shell Authentication", RFC 6187, March 2011. 335 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 336 Base Notifications", RFC 6470, February 2012. 338 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 339 Secure Internet Routing", RFC 6480, February 2012. 341 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 342 Verification for the Secure Shell (SSH) Transport Layer 343 Protocol", RFC 6668, July 2012. 345 Authors' Addresses 347 Sean Turner 348 IECA, Inc. 349 3057 Nutley Street, Suite 106 350 Fairfax, Virginia 22031 351 US 353 Email: turners@ieca.com 355 Keyur Patel 356 Cisco Systems 357 170 West Tasman Drive 358 San Jose, CA 95134 359 US 361 Email: keyupate@cisco.com 363 Randy Bush 364 Internet Initiative Japan, Inc. 365 5147 Crystal Springs 366 Bainbridge Island, Washington 98110 367 US 369 Phone: +1 206 780 0431 x1 370 Email: randy@psg.com