Network Working Group S. Turner Internet-Draft IECA, Inc. Intended status: BCP K. Patel Expires: November 15, 2012 Cisco Systems R. Bush Internet Initiative Japan, Inc. May 14, 2012 Router Keying for BGPsec draft-ietf-sidr-rtr-keying-00 Abstract BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 15, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Turner, et al. Expires November 15, 2012 [Page 1] Internet-Draft Router Keying for BGPsec May 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Router-Generated Keys . . . . . . . . . . . . . . . . . . . . . 4 4. Operator-Generated Keys . . . . . . . . . . . . . . . . . . . . 4 5. Provisioning a New Router . . . . . . . . . . . . . . . . . . . 4 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Turner, et al. Expires November 15, 2012 [Page 2] Internet-Draft Router Keying for BGPsec May 2012 1. Introduction BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global RPKI (Resource Public Key Infrastructure). Note that the public key is published in the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki-profiles]. This document describes two methods for generating the necessary public/private key-pair: router- driven and operator-driven. In the router-driven method, the router generates its own public/ private key-pair, uses the private key to sign a certification request [I-D.ietf-sidr-bgpsec-pki-profiles] (a PKCS#10 - includes the public key), and sends the certification request to the RPKI CA (Certification Authority). The CA returns a PKCS#7, which includes the certified public key in the form of a certificate, to the router and the CA also publishes the certificate in the RPKI. The router-driven model mirrors the model used by most PKI subscribers. In many cases, the private key never leaves trusted storage (e.g., HSM (Hardware Security Model)). This is by design and supports CPs (Certification Policies), often times for human subscribers, that require the private key only ever be controlled by the subscriber to ensure that no one can impersonate the subscriber. For non-humans, this model does not always work. For example, when an operator wants to support hot-swappable routers the same private key needs to be installed in the soon-to-be online router that was installed in the soon-to-be offline router. This motivated the operator-driven model. In the operator-driven model, the operator generates the private/ public key-pair and sends it to the router in a PKCS#8 [RFC5958]. In both cases, the key pair is for algorithms defined in [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on the P-256 curve. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. It is assumed that the reader understands BGPsec, see [I-D.lepinski-bgpsec-overview], [I-D.lepinski-bgpsec-protocol], the RPKI, see [RFC6480], and [I-D.ietf-sidr-bgpsec-pki-profiles]. Turner, et al. Expires November 15, 2012 [Page 3] Internet-Draft Router Keying for BGPsec May 2012 3. Router-Generated Keys For router-generated keys, the public/private keys are made by the router, a PKCS#10 is made by the router, and signed by the private key, and is transferred to the RPKI CA. The CA returns a PKCS#7, the operator transfers the PKCS#7 to the router, and the router picks the certificate out of the PKCS#7. Even if the operator can not get the private key off the router this still provides a linkage between a private key and a router. 4. Operator-Generated Keys For operator-generated keys, the public/private keys are made by the operator with their RPKI management software. The private key pair MUST be as specified in [RFC5915], which supports ECDSA keys. That format MUST then be inserted to a PKCS#8 [RFC5958] along with the certificate. If the operator wants to ship the keys around they can use the .p8 file extension and optional PEM encoding also from [RFC5958]. EDITOR NOTE: One thing we should consider is whether the certificate needs to returned to the router like in the router-generated keys method. PKCS#8 supports including the certificate so it's not a big deal to add it if we do. 5. Provisioning a New Router When commissioning a new router, the operator may use either of the above methods. Using the Router-Generated Keys method, see Section 3, the operator decides on the AS number and the BGP RouterID of the router, logs on to the new router using the craft port, ssh, etc., and requests that the router generate a public/private key-pair and generate and sign (with the private key) a PKCS#10 request. The operator then off- loads the PKCS#10 request and uploads the request to their RPKI software management tools. The tools create and publish the RPKI Router-Key object for the public key, and return the PKCS#7. The operator uploads the PKCS#7 to the router which then extracts its certificate. The router MAY use the PKCS#7 as an indicator that the certificate request was actually processed, and SHOULD verify that the issued certificate actually corresponds to the private key the router holds. Using the Operator-Generated Key method, see Section 4, the operator Turner, et al. Expires November 15, 2012 [Page 4] Internet-Draft Router Keying for BGPsec May 2012 decides on the AS number and the BGP RouterID of the new router and uses their RPKI software management tools to generate the public/ private key-pair and publish the public key in the RPKI. The tools also produce the PKCS#8 object which the operator then uploads into the new router via the craft port, ssh, NetConf, etc. The router installs the PKCS#8 and installs the public/private key-pair. The router SHOULD verify that the issued certificate actually corresponds to the private key in the PKCS#8, i.e. the PKCS#8 is self-consistent. 6. Other Use Cases Current router code generates private keys for uses such as ssh, but the private keys may not be seen or off-loaded via CLI or any other means. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software which accesses the router must be updated with the new keys. Also, the initial contact with a new routing engine requires trust in the public key presented on first contact. To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to be off-loaded via the CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator upload the old private key via the mechanism used for Operator- Generated Keys, see Section 4. 7. Security Considerations Operator-generated keys could be intercepted in transport and the recipient router would have no way of knowing a substitution had been made by a monkey in the middle. Hence transport security is strongly advised. 8. IANA Considerations This document has no IANA Considerations. 9. References Turner, et al. Expires November 15, 2012 [Page 5] Internet-Draft Router Keying for BGPsec May 2012 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key Structure", RFC 5915, June 2010. [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010. 9.2. Informative References [I-D.ietf-sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", draft-ietf-sidr-bgpsec-algs-02 (work in progress), March 2012. [I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles-03 (work in progress), April 2012. [I-D.lepinski-bgpsec-overview] Lepinski, M. and S. Turner, "An Overview of BGPSEC", draft-lepinski-bgpsec-overview-00 (work in progress), March 2011. [I-D.lepinski-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol Specification", draft-lepinski-bgpsec-protocol-00 (work in progress), March 2011. [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) Base Notifications", RFC 6470, February 2012. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. Turner, et al. Expires November 15, 2012 [Page 6] Internet-Draft Router Keying for BGPsec May 2012 Authors' Addresses Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, Virginia 22031 US Email: turners@ieca.com Keyur Patel Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: keyupate@cisco.com Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 Email: randy@psg.com Turner, et al. Expires November 15, 2012 [Page 7]