idnits 2.17.1 draft-ymbk-bgpsec-rtr-rekeying-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (March 5, 2012) is 4435 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.lepinski-bgpsec-protocol' is mentioned on line 116, but not defined == Missing Reference: 'RFC6480' is mentioned on line 117, but not defined == Unused Reference: 'I-D.sidr-bgpsec-overview' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-protocol' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-bgpsec-algs' is defined on line 230, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5915 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-01 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-01 == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-01 == Outdated reference: A later version (-18) exists of draft-ietf-sidr-bgpsec-algs-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Turner 3 Internet-Draft IECA, Inc. 4 Intended status: BCP K. Patel 5 Expires: September 2, 2012 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 March 5, 2012 10 Router Keying for BGPsec 11 draft-ymbk-bgpsec-rtr-rekeying-00 13 Abstract 15 BGPsec-speaking routers must be provisioned with private keys and the 16 corresponding public key must be published in the global Resource 17 PKI. This document describes two ways of doing so, router-driven and 18 operator-driven. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 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 September 6, 2012. 39 Copyright Notice 41 Copyright (c) 2012 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 Table of Contents 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Router-Generated Keys . . . . . . . . . . . . . . . . . . . . 3 61 4. Operator-Generated Keys . . . . . . . . . . . . . . . . . . . 3 62 5. Provisioning a New Router . . . . . . . . . . . . . . . . . . 4 63 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 BGPsec-speaking routers must be provisioned with private keys and the 75 corresponding public key must be published in the global RPKI 76 (Resource Public Key Infrastructure). Note that the public key is 77 published in the RPKI in the form of a certificate [I-D.sidr-bgpsec- 78 pki-profiles]. This document describes two methods for generating the 79 necessary public/private key-pair: router-driven and operator-driven. 81 In the router-driven method, the router generates its own 82 public/private key-pair, uses the private key to sign a certification 83 request [I-D.sidr-bgpsec-pki-profiles] (a PKCS#10 - includes the 84 public key), and sends the certification request to the RPKI CA 85 (Certification Authority). The CA returns a PKCS#7, which includes 86 the certified public key in the form of a certificate, to the router 87 and the CA also publishes the certificate in the RPKI. 89 The router-driven model mirrors the model used by most PKI 90 subscribers. In many cases, the private key never leaves trusted 91 storage (e.g., HSM (Hardware Security Model)). This is by design and 92 supports CPs (Certification Policies), often times for human 93 subscribers, that require the private key only ever be controlled by 94 the subscriber to ensure that no one can impersonate the subscriber. 96 For non-humans, this model does not always work. For example, when 97 an operator wants to support hot-swappable routers the same private 98 key needs to be installed in the soon-to-be online router that was 99 installed in the soon-to-be offline router. This motivated the 100 operator-driven model. 102 In the operator-driven model, the operator generates the 103 private/public key-pair and sends them to the router in a PKCS#8 104 [RFC5958]. 106 In both cases, the key pair is for algorithms defined in [I-D.sidr- 107 bgpsec-algs]. The first version specifies ECDSA on the P-256 curve. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 It is assumed that the reader understands BGPsec, see [I-D.lepinski- 116 bgpsec-overview] and [I-D.lepinski-bgpsec-protocol], and the RPKI, 117 see [RFC6480] and [I-D.sidr-bgpsec-pki-profiles]. 119 3. Router-Generated Keys 121 For router-generated keys, the public/private keys are made by the 122 router, a PKCS#10 is made by the router, the PKCS#10 is signed by the 123 private key. The CA returns a PKCS#7 and the router picks the 124 certificate out of the PKCS#7. Even if the operator can not get the 125 private key off the router this still provides a linkage between a 126 private key and a router. 128 4. Operator-Generated Keys 130 For operator-generated keys, the public/private keys are made by the 131 operator with their RPKI management software. The private key pair 132 MUST be as specified in [RFC5915], which supports ECDSA keys. That 133 format MUST then be inserted to a PKCS#8 [RFC5958] along with the 134 certificate. If the operator wants to ship the keys around they can 135 use the .p8 file extension and optional PEM encoding also from 136 [RFC5958]. 138 EDITOR NOTE: One thing we should consider is whether the certificate 139 needs to returned to the router like in the router-generated keys 140 method. PKCS#8 supports including the certificate so it's not a big 141 deal to add it if we do. 143 5. Provisioning a New Router 145 When commissioning a new router, the operator may use either of the 146 above methods. 148 Using the Router-Generated Keys method, see Section 3, the operator 149 decides on the AS number and the BGP RouterID of the router, logs on 150 to the new router using the craft port, ssh, etc., and requests that 151 the router generate a public/private key-pair and generate and sign 152 (with the private key) a PKCS#10 request. The operator then off- 153 loads the PKCS#10 request and uploads the request to their RPKI 154 software management tools. The tools create and publish the RPKI 155 Router-Key object for the public key, and return the PKCS#7. The 156 operator uploads the PKCS#7 to the router which then extracts its 157 certificate. 159 Using the Operator-Generated Key method, see Section 4, the operator 160 decides on the AS number and the BGP RouterID of the new router and 161 uses their RPKI software management tools to generate the 162 public/private key-pair and publish the public key in the RPKI. The 163 tools also produce the PKCS#8 object which the operator then uploads 164 into the new router via the craft port, ssh, NetConf, etc. The 165 router installs the PKS#8 and installs the public/private key- 166 pair. 168 6. Other Use Cases 170 Current router code generates private keys for uses such as ssh, but 171 the private keys may not be seen or off-loaded via CLI or any other 172 means. While this is good security, it creates difficulties when a 173 routing engine or whole router must be replaced in the field and all 174 software which accesses the router must be updated with the new keys. 175 Also, the initial contact with a new routing engine requires trust 176 in the public key presented on first contact. 178 To allow operators to quickly replace routers without requiring 179 update and distribution of the corresponding public keys in the RPKI, 180 routers SHOULD allow the private BGPsec key to be off-loaded via the 181 CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator 182 upload the old private key via the mechanism used for Operator- 183 Generated Keys, see Section 5. 185 7. Security Considerations 186 Keys could be intercepted in transport and the recipient, RPKI or 187 router, would have no way of knowing a substitution had been made by 188 a monkey in the middle. Hence transport security is strongly 189 advised. 191 8. IANA Considerations 193 This document has no IANA Considerations. 195 9. References 197 9.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 203 Structure", RFC 5915, June 2010. 205 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 206 2010. 208 9.2. Informative References 210 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 211 Base Notifications", RFC 6470, February 2012. 213 [I-D.sidr-bgpsec-overview] 214 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 215 draft-ietf-sidr-bgpsec-overview-01 (work in progress), 216 October 2011. 218 [I-D.sidr-bgpsec-protocol] 219 Lepinski, M., "BGPSEC Protocol Specification", 220 draft-ietf-sidr-bgpsec-protocol-01 (work in progress), 221 October 2011. 223 [I-D.sidr-bgpsec-pki-profiles] 224 Reynolds, M., Turner, S., and S. Kent, "A Profile for 225 BGPSEC Router Certificates, Certificate Revocation Lists, 226 and Certification Requests", 227 draft-ietf-sidr-bgpsec-pki-profiles-01 (work in progress), 228 December 2011. 230 [I-D.sidr-bgpsec-algs] 231 Turner, S., "BGP Algorithms, Key Formats, & Signature 232 Formats", draft-ietf-sidr-bgpsec-algs-01 (work in 233 progress), December 2011. 235 Appendix A. Examples 237 The examples provided in this appendix were generated using OpenSSL 238 0.9.8.r. 240 Appendix A.1. Operator-Generated Keys 242 To generate the EC public and private keys: 244 openssl ecparam -genkey -name secp256v1 -noout -out ecKey.pem 246 The result is (note this ought not be reproducible because each 247 key better be unique, but you ought to get the same format): 249 -----BEGIN EC PRIVATE KEY----- 250 MHcCAQEEIEzFLfqklXUpodvaqGuivapVRzRxiITh4UdlJ/JTAgKxoAoGCCqGSM49 251 AwEHoUQDQgAEM4VgV/qUB06BZ9bzqYyXIfacC5NDr9yavwxfbZnGejIaeXXt2OO/ 252 qkmQQq3E7m/GEJ+XFyciLv2da9waZMTVQg== 253 -----END EC PRIVATE KEY----- 255 To convert the result to PKCS#8, issue the following command: 257 openssl pkcs8 -topk8 -inform PEM -outform PEM -in ecKey.pem -out 258 ecKey-p8.pem -nocrypt 260 -----BEGIN PRIVATE KEY----- 261 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgTMUt+qSVdSmh29qo 262 a6K9qlVHNHGIhOHhR2Un8lMCArGhRANCAAQzhWBX+pQHToFn1vOpjJch9pwLk0Ov 263 3Jq/DF9tmcZ6Mhp5de3Y47+qSZBCrcTub8YQn5cXJyIu/Z1r3BpkxNVC 264 -----END PRIVATE KEY----- 266 Appendix A.1. Router-Generated Keys 268 TBD 270 Authors' Addresses 272 Sean Turner 273 IECA, Inc. 274 3057 Nutley Street, Suite 106 275 Fairfax, Virginia 22031 276 US 277 Email: turners@ieca.com 279 Keyur Patel 280 Cisco Systems 281 170 West Tasman Drive 282 San Jose, CA 95134 283 US 285 Email: keyupate@cisco.com 287 Randy Bush 288 Internet Initiative Japan, Inc. 289 5147 Crystal Springs 290 Bainbridge Island, Washington 98110 291 US 293 Phone: +1 206 780 0431 x1 294 Email: randy@psg.com