idnits 2.17.1 draft-ietf-sidr-rtr-keying-04.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 (December 17, 2013) is 3783 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: 'RFC6480' is mentioned on line 86, but not defined == Missing Reference: 'RFC6668' is mentioned on line 101, but not defined == Missing Reference: 'RFC6484' is mentioned on line 160, but not defined == Missing Reference: 'RFC6470' is mentioned on line 223, but not defined == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3' is defined on line 308, 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 (~~), 7 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: June 20, 2014 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 December 17, 2013 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-04 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 transferred to the RPKI CA over the network if the 124 router supports protocols such as FTP and HTTP [RFC2585] using the 125 application/pkcs10 media type [RFC5967] or EST (Enrollment over 126 Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that 127 the router has direct connectivity to the CA. The CA returns a 128 successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki-profiles], 129 which includes the certificate, and uploads the certificate to the 130 global RPKI. The response can be returned using the 131 application/pkcs7-mime media type [RFC5751] if the router supports 132 protocols such as FTP and HTTP. 134 The PKCS#10 request can also be indirectly transferred to the RPKI CA 135 through the operator. The operator off-loads the PKCS#10 and uploads 136 the request to its RPKI software management tools; external network 137 connectivity is not required when the operator acts as the CA. The 138 tools create the certificate and publish the certificate in the 139 global RPKI, and return the PKCS#7 to the router; publication of the 140 certificate in the global RPKI requires external network 141 connectivity. 143 The router SHOULD extract the certificate from the PCKCS#7 and verify 144 that the private key corresponds to the returned public key. The 145 router SHOULD inform the operator that it has successfully received 146 its certificate; this mechanism is out of scope. When the keys do 147 not correspond, the router SHOULD inform the operator; this mechanism 148 is out of scope. The router SHOULD also verify the returned 149 certificate back to a trust anchor, but to perform this verification 150 either the CA's certificate needs to be installed on the router via 151 the CLI or the CA's certificate needs to be returned along with the 152 router's certificate in the PKCS#7. The router SHOULD inform the 153 operator if the signature does not validate to a trust anchor; this 154 notification mechanism is out of scope. After performing these 155 checks, the router need not retain the certificate. 157 Note that even if the operator can not get the private key off the 158 router this signature still provides a linkage between a private key 159 and a router. That is the server can verify the proof of possession 160 (POP), as required by [RFC6484]. 162 3.2. Operator-Generated Keys 164 In the operator-driven method, the operator generates the private key 165 and it is installed over the SSH connection established between the 166 operator and the router. Note that cut/copy and paste operations for 167 keys over a certain sizes is error-prone. 169 The operator uses their RPKI management tools to generate the keys, 170 the PKCS#10 certification request, the certificate, and the PKCS#7 171 certification response as well as publish the certificate for the 172 public key in the global RPKI. The only reason global network 173 connectivity might be needed would be to publish the certificate in 174 the global RPKI. The private key MUST support the algorithm 175 specified in [I-D.ietf-sidr-bgpsec-algs], which for ECDSA is 176 specified in [RFC5915]. The PKCS#10 and PKCS#7 are as specified in 177 [I-D.ietf-sidr-bgpsec-pki-profiles]. 179 Along with the PKCS#7, the operator returns the private key. The 180 private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is 181 further encapsulated in a CMS (Cryptographic Message Syntax) 182 SignedData [RFC5652], and signed by the operator's EE certificate. 184 The router SHOULD verify the signature on the encapsulated PKCS#8 to 185 ensure the returned private key in fact came from the operator, but 186 this requires that the operator also provision via the CLI or include 187 in the SignedData the RPKI CA certificates and operator's EE 188 certificates. The router SHOULD inform the operator if the signature 189 does not validate to a trust anchor; this notification mechanism is 190 out of scope. 192 The router SHOULD extract the certificate for the PKCS#7 and verify 193 that the private key corresponds to the returned public key. The 194 router SHOULD inform the operator that it has successfully received 195 its certificate; this mechanism is out of scope. When the keys do 196 not correspond, the router SHOULD inform the operator; this mechanism 197 is out of scope. The router SHOULD also verify the returned 198 certificate back to a trust anchor, but to perform this verification 199 either the CA's certificate needs to be installed on the router via 200 the CLI or the CA's certificate needs to be returned along with the 201 router's certificate in the PKCS#7. The router SHOULD inform the 202 operator if the signature does not validate to a trust anchor; this 203 notification mechanism is out of scope. After performing these 204 checks, the router need not retain the certificate. 206 4. Key rollover 208 TBD 210 5. Other Use Cases 212 Current router code generates private keys for uses such as SSH, but 213 the private keys may not be seen or off-loaded via CLI or any other 214 means. While this is good security, it creates difficulties when a 215 routing engine or whole router must be replaced in the field and all 216 software which accesses the router must be updated with the new keys. 217 Also, the initial contact with a new routing engine requires trust in 218 the public key presented on first contact. 220 To allow operators to quickly replace routers without requiring 221 update and distribution of the corresponding public keys in the RPKI, 222 routers SHOULD allow the private BGPsec key to be off-loaded via the 223 CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator 224 upload the old private key via the mechanism used for operator- 225 generated keys, see Section 3.2. 227 6. Security Considerations 229 Operator-generated keys could be intercepted in transport and the 230 recipient router would have no way of knowing a substitution had been 231 made or that the key had been disclosed by a monkey in the middle. 232 Hence transport security is strongly RECOMMENDED. As noted in 233 Section 3, the level of security provided by the transport security 234 SHOULD be commensurate with the BGPsec key. Additionally, operators 235 SHOULD ensure the transport security implementation is up to date and 236 addresses all known implementation bugs. 238 All generated key pairs MUST be generated from a good source of non- 239 deterministic random input [RFC4086] and the private key MUST be 240 protected in a secure fashion. Disclosure of the private key leads 241 to masquerade [RFC4949]. The local storage format for the private 242 key is a local matter. 244 Though the CA's certificate is installed on the router and used to 245 verify the returned certificate is in fact signed by the CA, the 246 revocation status of the CA's certificate is not checked. The 247 operator MUST ensure that installed CA certificate is valid. 249 Operators need to manage their SSH keys to ensure only those 250 authorized to access the router can. As employees no longer need 251 access to the router, their keys SHOULD be removed from the router. 253 7. IANA Considerations 255 This document has no IANA Considerations. 257 8. References 259 8.1. Normative References 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 265 "Randomness Requirements for Security", BCP 106, RFC 4086, 266 June 2005. 268 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 269 Transport Layer Protocol", RFC 4253, January 2006. 271 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 272 RFC 5652, September 2009. 274 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 275 Structure", RFC 5915, June 2010. 277 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 278 2010. 280 [I-D.ietf-sidr-bgpsec-algs] 281 Turner, S., "BGP Algorithms, Key Formats, & Signature 282 Formats", draft-ietf-sidr-bgpsec-algs (work in progress), 283 September 2013. 285 [I-D.ietf-sidr-bgpsec-pki-profiles] 286 Reynolds, M., Turner, S., and S. Kent, "A Profile for 287 BGPSEC Router Certificates, Certificate Revocation Lists, 288 and Certification Requests", 289 draft-ietf-sidr-bgpsec-pki-profiles (work in progress), 290 September 2013. 292 8.2. Informative References 294 [I-D.ietf-sidr-bgpsec-overview] 295 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 296 draft-ietf-sidr-bgpsec-overview (work in progress), 297 December 2013. 299 [I-D.ietf-sidr-bgpsec-protocol] 300 Lepinski, M., "BGPSEC Protocol Specification", 301 draft-ietf-sidr-bgpsec-protocol (work in progress), 302 November 2013. 304 [I-D.ietf-pkix-est] 305 Pritikin, M, Yee, P., and D. Harkins "Enrollment over 306 Secure Transport", RFC 7030, October 2013. 308 [IEEE-802.3] 309 ISO/IEC 8802-3 Information technology - 310 Telecommunications and information exchange between 311 systems - Local and metropolitan area networks - 312 Common specifications - Part 3: Carrier Sense 313 Multiple Access with Collision Detection (CSMA/CD) 314 Access Method and Physical Layer Specifications, 2008. 316 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 317 Infrastructure Operational Protocols: FTP and HTTP", 318 RFC 2585, May 1999. 320 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 321 Transport Layer Protocol", RFC 4253, January 2006. 323 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 324 36, RFC 4949, August 2007. 326 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 327 Secure Shell Transport Layer Protocol", RFC 5647, August 328 2009. 330 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 331 Integration in the Secure Shell Transport Layer", 332 RFC 5656, December 2009. 334 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 335 Mail Extensions (S/MIME) Version 3.2 Message 336 Specification", RFC 5751, January 2010. 338 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 339 August 2010. 341 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 342 Shell Authentication", RFC 6187, March 2011. 344 Authors' Addresses 346 Sean Turner 347 IECA, Inc. 348 3057 Nutley Street, Suite 106 349 Fairfax, Virginia 22031 350 US 352 Email: turners@ieca.com 354 Keyur Patel 355 Cisco Systems 356 170 West Tasman Drive 357 San Jose, CA 95134 358 US 360 Email: keyupate@cisco.com 362 Randy Bush 363 Internet Initiative Japan, Inc. 364 5147 Crystal Springs 365 Bainbridge Island, Washington 98110 366 US 368 Phone: +1 206 780 0431 x1 369 Email: randy@psg.com