S. Kent Internet-Draft M. Lepinski Intended status: Standards Track M. Reynolds Expires: December 4, 2011 BBN June 2, 2011 A Profile for BGPSEC Router Certificates draft-reynolds-bgpsec-rtrcerts-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 4, 2011. Copyright and License Notice Copyright (c) 2011 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 included Simplified BSD License text as described in Section 4.e of the Legal Trust Provisions and are provided without warranty as described in the BSD License. Kent, et al Expires December 4, 2011 [Page 1] Internet-Draft BGPSEC Router Certificate Profile June 2011 Abstract This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource PKI (RPKI) CA certificates, containing the RFC 3779 AS number extension, to routers within the autonomous system. The certificate asserts that the router(s) holding the public key are authorized to send out secure route advertisements on behalf of the specified autonomous system. Note that since these certificates extend the RPKI [ID.sidr-arch], this profile is based on the profile for RPKI resource certificates [ID.res-cert-prof]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 3. BGPSEC Router Certificate Fields . . . . . . . . . . . . . . . 6 3.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Serial Number . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Signature Algorithm . . . . . . . . . . . . . . . . . . . . 6 3.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7 Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.8 Subject Public Key Info . . . . . . . . . . . . . . . . . . 7 3.9 BGPSEC Router Certificate Version 3 Extension Fields . . . 7 3.9.1 Basic Constraints . . . . . . . . . . . . . . . . . . 7 3.9.2 Subject Key Identifier . . . . . . . . . . . . . . . . 7 3.9.3 Authority Key Identifier . . . . . . . . . . . . . . . 7 3.9.4 Key Usage . . . . . . . . . . . . . . . . . . . . . . 7 3.9.5 Extended Key Usage . . . . . . . . . . . . . . . . . . 8 3.9.6 CRL Distribution Points . . . . . . . . . . . . . . . 8 3.9.7 Authority Information Access . . . . . . . . . . . . . 8 3.9.8 Subject Information Access . . . . . . . . . . . . . . 8 3.9.9 Certificate Policies . . . . . . . . . . . . . . . . . 8 3.9.10 IP Resources . . . . . . . . . . . . . . . . . . . . 8 3.9.11 AS Resources . . . . . . . . . . . . . . . . . . . . 8 4. BGPSEC Router Certificate Revocation List Profile . . . . . . . 9 5. BGPSEC Router Certificate Request Profile . . . . . . . . . . 10 6. BGPSEC Router Certificate Validation . . . . . . . . . . . . 11 Kent, et al Expires December 4, 2011 [Page 2] Internet-Draft BGPSEC Router Certificate Profile June 2011 7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 10.2 Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A: Example BGPSEC Router Certificate . . . . . . . . . . 16 Appendix B: Example Certificate Revocation List . . . . . . . . . 16 Kent, et al Expires December 4, 2011 [Page 3] Internet-Draft BGPSEC Router Certificate Profile June 2011 1. Introduction This document defines a profile for X.509 end entity (EE) certificates [X.509] for use in the context of certification of AS paths in the BGPSEC protocol. Such certificates are termed "BGPSEC Router certificates". The holder of the private key associated with a BGPSEC router certificate is authorized to send secure route advertisements (BGPSEC UPDATEs) on behalf of the AS named in the certificate. That is, a router holding the private key may send to its BGP peers, route advertisements that contain the specified AS number as the last item in the AS PATH attribute. A key property that BGPSEC will provide is that every autonomous system along the AS PATH can verify that the other ASes along the path have authorized the advertisement of the given route (to the next AS along the AS PATH). This document is a profile of [ID.res-cert-prof], which is a profile of RFC 5280. It establishes requirements imposed on a Resource certificate that is used as a BGPSEC Router certificate, i.e., it defines constraints for certificate fields and extensions for the certificate to be valid in this context. A relying party processing what purports to be a BGPSEC Router certificate MUST verify that the certificate conforms to this profile. 1.1 Terminology It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Capability Advertisement with BGP-4" [RFC 5492], "Considerations in Validating the Path in BGP" [RFC 5123], "BGP Security Vulnerabilities Analysis" [RFC 4272], and "A Border Gateway Protocol 4 (BGP-4)" [RFC 4271]. 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. Kent, et al Expires December 4, 2011 [Page 4] Internet-Draft BGPSEC Router Certificate Profile June 2011 2. Describing Resources in Certificates The framework for describing an association between the subject of a certificate and the AS resources currently under the subject's control is described in RFC 3779. There are two aspects of this resource extension that are noted in this profile. First, RFC 3779 notes that a resource extension SHOULD be a CRITICAL extension to the X.509 certificate. This BGPSEC Router certificate profile further mandates that this certificate extension MUST appear in all BGPSEC Router certificates and MUST be marked as CRITICAL. Second, a test of the resource extension in the context of certificate validity includes the condition that the resources described in the immediate parent CA certificate in the PKI (the certificate where this certificate's issuer is the subject) has a resource set, hereinafter called the "issuer's resource set" that MUST encompass the resource set of the issued certificate. In this context "encompass" allows for the issuer's resource set to be the same as, or a strict superset of, a subject's resource set. Kent, et al Expires December 4, 2011 [Page 5] Internet-Draft BGPSEC Router Certificate Profile June 2011 3. BGPSEC Router Certificate Fields A BGPSEC Router Certificate is a valid X.509 public key certificate, consistent with the PKIX profile [RFC5380], containing the fields listed in this section. Unless specifically noted as being OPTIONAL, all the fields listed here MUST be present, and any other field MUST NOT appear in a conforming BGPSEC Router Certificate. If a field value is specified here, this value MUST be used in conforming BGPSEC Router certificates. For any BGPSEC Router certificate field that is the same as in the [ID.res-cert-prof] profile, this document will cite the corresponding section in that document. 3.1 Version Refer to section 4.1 of [ID.res-cert-prof]. 3.2 Serial Number Refer to section 4.2 of [ID.res-cert-prof]. 3.3 Signature Algorithm Refer to section 4.3 of [ID.res-cert-prof]. 3.4 Issuer Refer to section 4.4 of [ID.res-cert-prof]. The value of this field is a distinguished name that adheres to the conventions imposed on Issuer (and Subject) names that appear in Resource Certificates, as described in [ID.sidr-arch]. 3.5 Subject This field identifies the router to which the certificate has been issued. Consistent with [ID.res-cert-prof], only two attributes are allowed in the Subject field: common name and serial number. Moreover, the only common name encoding options that are supported are printableString and UTF8String. For router certificates, it is RECOMMENDED that the common name attribute contain the literal string "ROUTER-" followed by the 32-bit router ID encoded as eight hexadecimal digits. If the same certificate is issued to more than one router (hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the issuer. Note that router IDs are not guaranteed to be unique across the Internet, and thus the Subject name in a BGPSEC Router certificate issued using this convention also is not guaranteed to be unique across different issuers. However, each certificate issued by an individual CA MUST contain a subject name that is unique within Kent, et al Expires December 4, 2011 [Page 6] Internet-Draft BGPSEC Router Certificate Profile June 2011 that context. 3.6 Valid From Refer to section 4.6 of [ID.res-cert-prof]. 3.7 Valid To Refer to section 4.6 of [ID.res-cert-prof]. 3.8 Subject Public Key Info Refer to section 4.7 of [ID.res-cert-prof]. 3.9 BGPSEC Router Certificate Version 3 Extension Fields The following X.509 V3 extensions MUST be present (or MUST be absent, if so stated) in a conforming BGPSEC Router certificate, except where explicitly noted otherwise. No other extensions are allowed in a conforming BGPSEC Router certificate. 3.9.1 Basic Constraints The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate. Since a BGPSEC Router certificate is always an EE certificate, the basic constraints extension MUST NOT be present. 3.9.2 Subject Key Identifier The subject key identifier (SKI) extension MUST appear in every Resource Certificate, as per section 4.8.2 of [ID.res-cert-prof]. For a BGPSEC Router certificate, the SKI is used as a shorthand means of uniquely identifying an individual certificate. The SKI in a Resource certificate is generated from the public key in the certificate, using the SHA-1 algorithm, as described in section 4.2.1.2 of RFC 5280. This extension MUST appear in all BGPSEC Router certificates. This extension is non-critical. 3.9.3 Authority Key Identifier This is a non-critical extension and it MUST be present, as per section 4.8.3 of [ID.res-cert-prof]. 3.9.4 Key Usage This is a critical extension, and it MUST be present. The Kent, et al Expires December 4, 2011 [Page 7] Internet-Draft BGPSEC Router Certificate Profile June 2011 digitalSignature bit MUST be set to TRUE in all BGPSEC Router certificates, and it MUST be the only bit set to TRUE. 3.9.5 Extended Key Usage The EKU extension MUST NOT appear in a BGPSEC Router certificate. 3.9.6 CRL Distribution Points The CRLDP extension is non-critical and MUST appear in every BGPSEC Router Certificate, as per section 4.8.6 of [ID.res-cert-prof]. 3.9.7 Authority Information Access The AIA extension is non-critical and MUST appear in every BGPSEC Router Certificate, as per section 4.8.7 of [ID.res-cert-prof]. 3.9.8 Subject Information Access This extension is not used in BGPSEC Router certificates. It MUST be omitted. 3.9.9 Certificate Policies This critical extension MUST be present as per section 4.8.9 of [ID.res-cert-prof]. 3.9.10 IP Resources This extension is not used in BGPSEC Router certificates. It MUST be omitted. 3.9.11 AS Resources This extension contains the list of AS numbers that the router is authorized to represent in BGP advertisements, encoded as specified in RFC 3779. The "inherit" element MUST NOT be specified. As specified in section 4.8.11 of [ID.res-cert-prof], RDI values MUST NOT be used. All BGPSEC Router certificates MUST include an AS resources extension, and the extension MUST contain exactly one AS number. This extension MUST be marked critical. Kent, et al Expires December 4, 2011 [Page 8] Internet-Draft BGPSEC Router Certificate Profile June 2011 4. BGPSEC Router Certificate Revocation List Profile BGPSEC Router certificates are just another type of EE certificate issued by an RPKI CA. Therefore, there are no distinguishing features for the CRLs on which they appear. Refer to section 5 of [ID.res- cert-prof] for a complete description of the profile for these CRLs. Kent, et al Expires December 4, 2011 [Page 9] Internet-Draft BGPSEC Router Certificate Profile June 2011 5. BGPSEC Router Certificate Request Profile Refer to section 6 of [ID.res-cert-prof]. Kent, et al Expires December 4, 2011 [Page 10] Internet-Draft BGPSEC Router Certificate Profile June 2011 6. BGPSEC Router Certificate Validation The validation procedure used for BGPSEC Router certificates is identical to the validation procedure described in Section 7 of [ID.res-cert-prof], with two further restrictions. First, all IP address resources for a BGPSEC Router certificate will be empty. Second, the sole AS number resource in the BGPSEC Router certificate must match the last AS number in the AS path information of each BGP UPDATE message. While this second restriction is not part of validation per se, it is part of the operational validation of UPDATEs performed by the router. Kent, et al Expires December 4, 2011 [Page 11] Internet-Draft BGPSEC Router Certificate Profile June 2011 7. Design Notes The BGPSEC Router Certificate profile is based off the Resource Certificate profile as specified in [ID.res-cert-prof]. As a result, many of the design choices herein are a reflection of the design choices that were taken in that prior work. The reader is referred to [ID.res-cert-prof] for a fuller discussion of those choices. Kent, et al Expires December 4, 2011 [Page 12] Internet-Draft BGPSEC Router Certificate Profile June 2011 8. Security Considerations The Security Considerations of RFC5280 and RFC3779 apply to BGPSEC Router Certificates as defined by this profile, and their use. Additionally, the Security Considerations documented in the RPKI Architecture and Resource Certificate Profile [ID.res-cert-prof] apply. A BGPSEC Router Certificate is an extension of the RPKI to encompass routers. It is a building block of the larger BGPSEC security protocol used to validate signatures on BGPSEC Signature-Segment origination of Signed-Path segments. Thus its essential security function is the secure binding of an AS number to a public key, consistent with the RPKI allocation/assignment hierarchy. 9. IANA Considerations [Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this version of the document.] 10 References 10.1 Normative References [ID.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure" (work in progress); Internet Drafts draft-ietf-sidr-rpki-algs- 05.txt, April 2011. [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenburg, D., and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3513] Hinden, R., and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC4211] Schaad, J., and S. Deering, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, June 2004. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Kent, et al Expires December 4, 2011 [Page 13] Internet-Draft BGPSEC Router Certificate Profile June 2011 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [X.509] ITU-T, "Recommendation X.509: The Directory Authentication Format", 2000. [I-D. sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-side-arch-13.txt (work in progress), May 2011. [I-D. sidr-manifests] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Intrastructure" (work in progress); Internet Draft draft-ietf-sidr-rpki- manifests-12.txt, May 2011. [I-D. sidr-res-cert-prof] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr- res-certs-22.txt; (work in progress), May 2011. 10.2 Informative References [rsync] Tridgell, A., "rsync", April 2006, Authors' Addresses Stephen Kent Raytheon BBN Technologies Corp. 10 Moulton St. Cambridge, MA 02138 Email: kent@bbn.com Matthew Lepinski Raytheon BBN Technologies Corp. 10 Moulton St. Cambridge, MA 02138 Email: mlepinsk@bbn.com Mark Reynolds Raytheon BBN Technologies Corp. Kent, et al Expires December 4, 2011 [Page 14] Internet-Draft BGPSEC Router Certificate Profile June 2011 10 Moulton St. Cambridge, MA 02138 Email: mreynold@bbn.com Kent, et al Expires December 4, 2011 [Page 15] Internet-Draft BGPSEC Router Certificate Profile June 2011 Appendix A: Example BGPSEC Router Certificate TBD Appendix B: Example Certificate Revocation List TBD Kent, et al Expires December 4, 2011 [Page 16]