idnits 2.17.1 draft-ietf-sidr-rtr-keying-00.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 (May 14, 2012) is 4363 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) ** Downref: Normative reference to an Informational RFC: RFC 5915 == Outdated reference: A later version (-18) exists of draft-ietf-sidr-bgpsec-algs-02 == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: November 15, 2012 Cisco Systems 6 R. Bush 7 Internet Initiative Japan, Inc. 8 May 14, 2012 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-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. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 15, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Router-Generated Keys . . . . . . . . . . . . . . . . . . . . . 4 57 4. Operator-Generated Keys . . . . . . . . . . . . . . . . . . . . 4 58 5. Provisioning a New Router . . . . . . . . . . . . . . . . . . . 4 59 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 BGPsec-speaking routers must be provisioned with private keys and the 70 corresponding public key must be published in the global RPKI 71 (Resource Public Key Infrastructure). Note that the public key is 72 published in the RPKI in the form of a certificate 73 [I-D.ietf-sidr-bgpsec-pki-profiles]. This document describes two 74 methods for generating the necessary public/private key-pair: router- 75 driven and operator-driven. 77 In the router-driven method, the router generates its own public/ 78 private key-pair, uses the private key to sign a certification 79 request [I-D.ietf-sidr-bgpsec-pki-profiles] (a PKCS#10 - includes the 80 public key), and sends the certification request to the RPKI CA 81 (Certification Authority). The CA returns a PKCS#7, which includes 82 the certified public key in the form of a certificate, to the router 83 and the CA also publishes the certificate in the RPKI. 85 The router-driven model mirrors the model used by most PKI 86 subscribers. In many cases, the private key never leaves trusted 87 storage (e.g., HSM (Hardware Security Model)). This is by design and 88 supports CPs (Certification Policies), often times for human 89 subscribers, that require the private key only ever be controlled by 90 the subscriber to ensure that no one can impersonate the subscriber. 91 For non-humans, this model does not always work. For example, when 92 an operator wants to support hot-swappable routers the same private 93 key needs to be installed in the soon-to-be online router that was 94 installed in the soon-to-be offline router. This motivated the 95 operator-driven model. 97 In the operator-driven model, the operator generates the private/ 98 public key-pair and sends it to the router in a PKCS#8 [RFC5958]. 100 In both cases, the key pair is for algorithms defined in 101 [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on 102 the P-256 curve. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 It is assumed that the reader understands BGPsec, see 111 [I-D.lepinski-bgpsec-overview], [I-D.lepinski-bgpsec-protocol], the 112 RPKI, see [RFC6480], and [I-D.ietf-sidr-bgpsec-pki-profiles]. 114 3. Router-Generated Keys 116 For router-generated keys, the public/private keys are made by the 117 router, a PKCS#10 is made by the router, and signed by the private 118 key, and is transferred to the RPKI CA. The CA returns a PKCS#7, the 119 operator transfers the PKCS#7 to the router, and the router picks the 120 certificate out of the PKCS#7. Even if the operator can not get the 121 private key off the router this still provides a linkage between a 122 private key and a router. 124 4. Operator-Generated Keys 126 For operator-generated keys, the public/private keys are made by the 127 operator with their RPKI management software. The private key pair 128 MUST be as specified in [RFC5915], which supports ECDSA keys. That 129 format MUST then be inserted to a PKCS#8 [RFC5958] along with the 130 certificate. If the operator wants to ship the keys around they can 131 use the .p8 file extension and optional PEM encoding also from 132 [RFC5958]. 134 EDITOR NOTE: One thing we should consider is whether the certificate 135 needs to returned to the router like in the router-generated keys 136 method. PKCS#8 supports including the certificate so it's not a big 137 deal to add it if we do. 139 5. Provisioning a New Router 141 When commissioning a new router, the operator may use either of the 142 above methods. 144 Using the Router-Generated Keys method, see Section 3, the operator 145 decides on the AS number and the BGP RouterID of the router, logs on 146 to the new router using the craft port, ssh, etc., and requests that 147 the router generate a public/private key-pair and generate and sign 148 (with the private key) a PKCS#10 request. The operator then off- 149 loads the PKCS#10 request and uploads the request to their RPKI 150 software management tools. The tools create and publish the RPKI 151 Router-Key object for the public key, and return the PKCS#7. The 152 operator uploads the PKCS#7 to the router which then extracts its 153 certificate. 155 The router MAY use the PKCS#7 as an indicator that the certificate 156 request was actually processed, and SHOULD verify that the issued 157 certificate actually corresponds to the private key the router holds. 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 public/ 162 private key-pair and publish the public key in the RPKI. The tools 163 also produce the PKCS#8 object which the operator then uploads into 164 the new router via the craft port, ssh, NetConf, etc. The router 165 installs the PKCS#8 and installs the public/private key-pair. 167 The router SHOULD verify that the issued certificate actually 168 corresponds to the private key in the PKCS#8, i.e. the PKCS#8 is 169 self-consistent. 171 6. Other Use Cases 173 Current router code generates private keys for uses such as ssh, but 174 the private keys may not be seen or off-loaded via CLI or any other 175 means. While this is good security, it creates difficulties when a 176 routing engine or whole router must be replaced in the field and all 177 software which accesses the router must be updated with the new keys. 178 Also, the initial contact with a new routing engine requires trust in 179 the public key presented on first contact. 181 To allow operators to quickly replace routers without requiring 182 update and distribution of the corresponding public keys in the RPKI, 183 routers SHOULD allow the private BGPsec key to be off-loaded via the 184 CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator 185 upload the old private key via the mechanism used for Operator- 186 Generated Keys, see Section 4. 188 7. Security Considerations 190 Operator-generated keys could be intercepted in transport and the 191 recipient router would have no way of knowing a substitution had been 192 made by a monkey in the middle. Hence transport security is strongly 193 advised. 195 8. IANA Considerations 197 This document has no IANA Considerations. 199 9. References 200 9.1. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 206 Structure", RFC 5915, June 2010. 208 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 209 August 2010. 211 9.2. Informative References 213 [I-D.ietf-sidr-bgpsec-algs] 214 Turner, S., "BGP Algorithms, Key Formats, & Signature 215 Formats", draft-ietf-sidr-bgpsec-algs-02 (work in 216 progress), March 2012. 218 [I-D.ietf-sidr-bgpsec-pki-profiles] 219 Reynolds, M., Turner, S., and S. Kent, "A Profile for 220 BGPSEC Router Certificates, Certificate Revocation Lists, 221 and Certification Requests", 222 draft-ietf-sidr-bgpsec-pki-profiles-03 (work in progress), 223 April 2012. 225 [I-D.lepinski-bgpsec-overview] 226 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 227 draft-lepinski-bgpsec-overview-00 (work in progress), 228 March 2011. 230 [I-D.lepinski-bgpsec-protocol] 231 Lepinski, M., "BGPSEC Protocol Specification", 232 draft-lepinski-bgpsec-protocol-00 (work in progress), 233 March 2011. 235 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 236 Base Notifications", RFC 6470, February 2012. 238 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 239 Secure Internet Routing", RFC 6480, February 2012. 241 Authors' Addresses 243 Sean Turner 244 IECA, Inc. 245 3057 Nutley Street, Suite 106 246 Fairfax, Virginia 22031 247 US 249 Email: turners@ieca.com 251 Keyur Patel 252 Cisco Systems 253 170 West Tasman Drive 254 San Jose, CA 95134 255 US 257 Email: keyupate@cisco.com 259 Randy Bush 260 Internet Initiative Japan, Inc. 261 5147 Crystal Springs 262 Bainbridge Island, Washington 98110 263 US 265 Phone: +1 206 780 0431 x1 266 Email: randy@psg.com