idnits 2.17.1 draft-ietf-sidr-rtr-keying-01.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 (February 23, 2013) is 4072 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 323, 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 (~~), 2 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: August 27, 2013 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 February 23, 2013 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-01 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 models is where the keys are 63 generated. Keys are generated on the router in the router-drive 64 method but elsewhere by the operator in the operator-drive model. 65 The router-driven model is most familiar to PKI subscribers because 66 its design supports CPs (Certification Policies), often times for 67 human subscribers, that require the private key only ever be 68 controlled by the subscriber to ensure that no one can impersonate 69 the subscriber. For non-humans, this model does not always work in 70 particular when an operator wants to support hot-swappable routers 71 the same private key needs to be installed in the soon-to-be online 72 router that was installed in the soon-to-be offline router. 74 The remainder of this document describes how operators can use the 75 two methods to provision new and existing routers. 77 Note that in both models, the key pair is for algorithms defined in 78 [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on 79 the P-256 curve. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in RFC 86 2119 [RFC2119]. 88 It is assumed that the reader understands BGPsec [I-D.ietf-sidr- 89 bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480], 90 and [I-D.ietf-sidr-bgpsec-pki-profiles]. 92 3. Provisioning a New Router 94 When commissioning a new router, operators may use either the router- 95 driven or operator-drive methods. Regardless of the method chosen, 96 the operator first needs to establish a secure communication channel 97 with the router. Today, this is done via a proprietary management 98 box directly connected to the router on the serial/craft port {spt: 99 is serial/craft port the correct terminology?}. After the management 100 box has been physically connected to the router, the operator 101 authenticates to the management box, via a proprietary mechanism 102 {spt: is this really proprietary or it is leap-of-faith?}, and uses 103 the CLI (command line interface) to generate the router's SSH (Secure 104 Shell) key [RFC4253], retrieve the router's SSH public key, install 105 the operator's SSH key(s), configures the Ethernet port [IEEE-802.3], 106 BGPSEC-router number {spt: assume this is where the BGPSEC-router # 107 will get "installed" for the router-driven case to know what to put 108 in the PKCS#10}, etc. {spt: did I miss anything?}. 110 {spt: i added CA certificate in the above for the router to verify 111 that the CA actually signed the certificate. overkill?} 113 {spt: this could go here or in the security considerations. i am 114 ambivalent about where it ends up, but i think we should have this 115 data in here somewhere. i'd like to think if we're provisioning 116 these routers with ECDSA keys that we're going to be using algorithms 117 at least as good!? the one that gives me heartburn is hmac-sha2-256 118 seems like there ought to be a 128-bit truncated version to match 119 with the others.} 121 The SSH encryption, integrity, authentication, and key exchange 122 mechanisms used by the router and operator SHOULD be of comparable 123 strength to BGPSEC key, which is 128-bit strength, e.g., for 124 encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for 125 integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647], 126 for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key 127 exchange: ecdh-sha2-nistp256 [RFC5656]. 129 {spt: i'm unsure whether the following is being done, but it could be 130 done so i think it's worth mentioning it.} 132 Note that if the router supports public key certificates at this 133 point, which would have had to have been provided by the operator at 134 this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used 135 instead for authentication. The SSH certificate, profiled in 136 [RFC6187], would be different than the BGPSEC certificate. 138 {spt: do the commands to generate/deposit a key need to come over the 139 ethernet port or if they can come over the management port?} 141 Once generated, the operator establishes an SSH connection with the 142 router and the management box is no longer needed. At this point, 143 the choice of router-driven or operator-driven is vendor specific. 145 3.1. Router-Generated Keys 147 In the router-driven method, once an SSH connection is established 148 between the operator and the router the operator issues a command, or 149 commands, to generate the public/private key pair on the router, to 150 generate the PKCS#10 that includes the router number and public key, 151 and sign the PKCS#10 with the private key. [I-D.ietf-sidr-bgpsec- 152 pki-profiles] specifies the format for the PKCS #10 and the algorithm 153 used to generate the signature is specified in [I-D.ietf-sidr-bgpsec- 154 algs]. 156 {spt: Not sure if the distinction I made here between direct and 157 indirect makes any sense.} 159 The PKCS#10 request can be directly transferred to the RPKI CA over 160 the Ethernet port if the router supports protocols such as FTP and 161 HTTP [RFC2585] using the application/pkcs10 media type [RFC5967] or 162 EST (Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA 163 returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki- 164 profiles], which includes the certificate, and uploads the 165 certificate to the global RPKI. The response can be returned using 166 the application/pkcs7-mime media type [RFC5751] if the router 167 supports protocols such as FTP and HTTP. 169 The PKCS#10 request can also be indirectly transferred to the RPKI CA 170 through the operator. The operator off-loads the PKCS#10 and uploads 171 the request to their RPKI software management tools. The tools 172 create and publish the certificate for the public key, and return the 173 PKCS#7 to the router. 175 {spt: the bit about checking the returned certificate is new, but i 176 think a good idea. but, does the CA's certificate get returned in 177 the PKCS#7 - I couldn't find that in the cert profile?} 179 The router SHOULD extract the certificate from the PCKCS#7 and verify 180 that the private key corresponds to the returned public key. The 181 router SHOULD inform the operator that it has successfully received 182 its certificate; this mechanism is out of scope. When the keys do 183 not correspond, the router SHOULD inform the operator; this mechanism 184 is out of scope. The router SHOULD also verify the returned 185 certificate back to a trust anchor, but to perform this verification 186 either the CA's certificate needs to be installed on the router via 187 the CLI or the CA's certificate needs to be returned along with the 188 router's certificate in the PKCS#7. The router SHOULD inform the 189 operator if the signature does not validate to a trust anchor; this 190 notification mechanism is out of scope. After performing these 191 checks, the router need not retain the certificate. 193 Note that even if the operator can not get the private key off the 194 router this still provides a linkage between a private key and a 195 router. 197 3.2. Operator-Generated Keys 199 In the operator-driven method, the operator generates the private key 200 and it is installed over the SSH connection established between the 201 operator and the router. The operator uses their RPKI management 202 tools to generate the keys, the PKCS#10 certification request, the 203 certificate, and the PKCS#7 certification response as well as publish 204 the certificate for the public key in the global RPKI. The private 205 key MUST support the algorithm specified in [I-D.ietf-sidr-bgpsec- 206 algs], which for ECDSA is specified in [RFC5915]. The PKCS#10 and 207 PKCS#7 are as specified in [I-D.ietf-sidr-bgpsec-pki-profiles]. 209 {spt: i figured maybe we could sign the PKCS#8, but that would have 210 to be done with a key other than the CA's key. It would have to be 211 the operator's EE key.} 213 Along with the PKCS#7, the operator returns the private key. The 214 private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is 215 further encapsulated in a CMS (Cryptographic Message Syntax) 216 SignedData [RFC5652], and signed by the operator's EE certificate. 218 The router SHOULD verify the signature on the encapsulated PKCS#8 to 219 ensure the returned private key in fact came from the operator, but 220 this requires that the operator also provision via the CLI or include 221 in the SignedData the RPKI CA certificates and operator's EE 222 certificates. The router SHOULD inform the operator if the signature 223 does not validate to a trust anchor; this notification mechanism is 224 out of scope. 226 The router SHOULD extract the certificate for the PKCS#7 and verify 227 that the private key corresponds to the returned public key. The 228 router SHOULD inform the operator that it has successfully received 229 its certificate; this mechanism is out of scope. When the keys do 230 not correspond, the router SHOULD inform the operator; this mechanism 231 is out of scope. The router SHOULD also verify the returned 232 certificate back to a trust anchor, but to perform this verification 233 either the CA's certificate needs to be installed on the router via 234 the CLI or the CA's certificate needs to be returned along with the 235 router's certificate in the PKCS#7. The router SHOULD inform the 236 operator if the signature does not validate to a trust anchor; this 237 notification mechanism is out of scope. After performing these 238 checks, the router need not retain the certificate. 240 5. Other Use Cases 241 Current router code generates private keys for uses such as SSH, but 242 the private keys may not be seen or off-loaded via CLI or any other 243 means. While this is good security, it creates difficulties when a 244 routing engine or whole router must be replaced in the field and all 245 software which accesses the router must be updated with the new keys. 246 Also, the initial contact with a new routing engine requires trust in 247 the public key presented on first contact. 249 To allow operators to quickly replace routers without requiring 250 update and distribution of the corresponding public keys in the RPKI, 251 routers SHOULD allow the private BGPsec key to be off-loaded via the 252 CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator 253 upload the old private key via the mechanism used for operator- 254 generated keys, see Section 3.2. 256 6. Security Considerations 258 Operator-generated keys could be intercepted in transport and the 259 recipient router would have no way of knowing a substitution had been 260 made or that the key had been disclosed by a monkey in the middle. 261 Hence transport security is strongly RECOMMENDED. As noted in 262 Section 3, the level of security provided by the transport security 263 SHOULD be commensurate with the BGPsec key. Additionally, operators 264 SHOULD ensure the transport security implementation is up to date and 265 addresses all known implementation bugs. 267 All generated key pairs MUST be generated from a good source of non- 268 deterministic random input [RFC4086] and the private key MUST be 269 protected in a secure fashion. Disclosure of the private key leads 270 to masquerade [RFC4949]. The local storage format for the private 271 key is a local matter. 273 Though the CA's certificate is installed on the router and used to 274 verify the returned certificate is in fact signed by the CA, the 275 revocation status of the CA's certificate is not checked. The 276 operator MUST ensure that installed CA certificate is valid. 278 Operators need to manage their SSH keys to ensure only those 279 authorized to access the router can. As employees no longer need 280 access to the router, their keys SHOULD be removed from the router. 282 7. IANA Considerations 284 This document has no IANA Considerations. 286 8. References 288 8.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 294 "Randomness Requirements for Security", BCP 106, RFC 4086, 295 June 2005. 297 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 298 Transport Layer Protocol", RFC 4253, January 2006. 300 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 301 RFC 5652, September 2009. 303 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 304 Structure", RFC 5915, June 2010. 306 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 307 2010. 309 [I-D.ietf-sidr-bgpsec-algs] 310 Turner, S., "BGP Algorithms, Key Formats, & Signature 311 Formats", draft-ietf-sidr-bgpsec-algs (work in progress), 312 September 2012. 314 [I-D.ietf-sidr-bgpsec-pki-profiles] 315 Reynolds, M., Turner, S., and S. Kent, "A Profile for 316 BGPSEC Router Certificates, Certificate Revocation Lists, 317 and Certification Requests", 318 draft-ietf-sidr-bgpsec-pki-profiles (work in progress), 319 October 2012. 321 8.2. Informative References 323 [I-D.ietf-sidr-bgpsec-overview] 324 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 325 draft-ietf-sidr-bgpsec-overview (work in progress), 326 December 2012. 328 [I-D.ietf-sidr-bgpsec-protocol] 329 Lepinski, M., "BGPSEC Protocol Specification", 330 draft-ietf-sidr-bgpsec-protocol (work in progress), 331 October 2012. 333 [I-D.ietf-pkix-est] 334 Pritikin, M, Yee, P., and D. Harkins "Enrollment over 335 Secure Transport", draft-ietf-pkix-est (work in progress), 336 February 2013. 338 [IEEE-802.3] 339 ISO/IEC 8802-3 Information technology - 340 Telecommunications and information exchange between 341 systems - Local and metropolitan area networks - 342 Common specifications - Part 3: Carrier Sense 343 Multiple Access with Collision Detection (CSMA/CD) 344 Access Method and Physical Layer Specifications, 2008. 346 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 347 Infrastructure Operational Protocols: FTP and HTTP", 348 RFC 2585, May 1999. 350 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 351 Transport Layer Protocol", RFC 4253, January 2006. 353 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 354 36, RFC 4949, August 2007. 356 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 357 Secure Shell Transport Layer Protocol", RFC 5647, August 358 2009. 360 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 361 Integration in the Secure Shell Transport Layer", 362 RFC 5656, December 2009. 364 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 365 Mail Extensions (S/MIME) Version 3.2 Message 366 Specification", RFC 5751, January 2010. 368 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 369 August 2010. 371 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 372 Shell Authentication", RFC 6187, March 2011. 374 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 375 Base Notifications", RFC 6470, February 2012. 377 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 378 Secure Internet Routing", RFC 6480, February 2012. 380 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 381 Verification for the Secure Shell (SSH) Transport Layer 382 Protocol", RFC 6668, July 2012. 384 Authors' Addresses 386 Sean Turner 387 IECA, Inc. 388 3057 Nutley Street, Suite 106 389 Fairfax, Virginia 22031 390 US 392 Email: turners@ieca.com 394 Keyur Patel 395 Cisco Systems 396 170 West Tasman Drive 397 San Jose, CA 95134 398 US 400 Email: keyupate@cisco.com 402 Randy Bush 403 Internet Initiative Japan, Inc. 404 5147 Crystal Springs 405 Bainbridge Island, Washington 98110 406 US 408 Phone: +1 206 780 0431 x1 409 Email: randy@psg.com