Internet Engineering Task Force Charles Lynn Internet Draft BBN Technologies draft-clynn-bgp-x509-auth-00.txt June 1999 X.509 Extensions for Authorization of IP Addresses, AS Numbers, and Routers within an AS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Please send comments on this draft to CLynn@BBN.Com. Abstract This document defines three X.509 v3 Certificate Extensions. The first binds a list of IP Address blocks to the public key of the subject of a certificate. The second binds a list of Autonomous System Numbers to the public key of the subject of a certificate. The third binds a BGP Router Identifier and an Autonomous System Number to the public key of the subject of a certificate. Third parties, e.g., BGP routers, may use these certificates to verify that the holder of the private key corresponding to the public key in the certificate has been properly authorized to use resources specified in the certificate extension. Copyright Notice Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Expires December 1999 CLynn [Page 1] Internet Draft X.509 Extensions for Authorization June 1999 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. X.509 Certificate Extensions . . . . . . . . . . . . . . . . 4 2. PKI for IP Address Allocation . . . . . . . . . . . . . . . . 4 2.1. IP Address Block Certificate Extension . . . . . . . . . . . 6 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Certification Path Verification . . . . . . . . . . . . . . 7 3. PKI for Assignment of ASes and Router Associations . . . . . . 8 3.1. Autonomous System Number Extension . . . . . . . . . . . . . 9 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Certification Path Verification . . . . . . . . . . . . . 10 3.2. Router Authorization Certificate Extension . . . . . . . . . 10 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Certification Path Verification . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Intellectual Property Rights . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Author's Addresse . . . . . . . . . . . . . . . . . . . . . . 13 Expires December 1999 CLynn [Page 2] Internet Draft X.509 Extensions for Authorization June 1999 1. Introduction Internet routing is based on a distributed system composed of many routers, grouped into management domains called Autonomous Systems (ASes). Routing information is exchanged between ASes in Border Gateway Protocol (BGP) [1,2] UPDATE messages. BGP has proven to be highly vulnerable to a variety of attacks [3], due to the lack of a scalable means of verifying the authenticity and legitimacy of BGP control traffic. Verification of the legitimacy of the control traffic requires that several conditions be met. Some of the conditions are: * The AS number of each peer in a BGP peering session has been authorized for use and to be a neighboring AS. * The peer that sends an UPDATE was authorized to act on behalf of its AS to advertise the routing information contained within the UPDATE to BGP peers in the recipient AS. * The AS that originates an UPDATE was authorized, by the owners of the address space corresponding to the set of reachable destinations, to advertise those destinations. * The owner of an address space corresponding to a reachable destination advertised in an UPDATE was authorized by its parent organization to own that address space. Checking these conditions requires a mechanism that can be used to verify: the ownership of IP Address Prefixes, the ownership of AS Numbers, and the authorization of a router to represent an AS. The mechanism must scale to the projected number of address prefixes, AS numbers, and inter-AS routers in the Internet. Due to the distributed nature of Internet routing, the entities that are checking the conditions will generally be unknown to the entities that own these resources, and thus any mechanism that requires a peer to peer security relationship between the entities will not meet the scaling requirements. Public Key Infrastructures (PKIs) have been designed to solve such problems. PKIs can be created, rooted at ICANN (formerly IANA), that corresponds to the assignment delegation system for IP address prefixes and AS numbers that is currently used in the Internet. This document describes these PKIs and defines the X.509 Certificate Extensions that they use to convey the necessary authorizations. Expires December 1999 CLynn [Page 3] Internet Draft X.509 Extensions for Authorization June 1999 1.1. X.509 Certificate Extensions Version 3 of X.509 [X.509] provides an extensible mechanism to include application specific information in certificates. Each extension contains three elements: an OBJECT IDENTIFIER that is associated with the syntax of the application specific data, a BOOLEAN that indicates if the certificate user must reject the certificate if it does not properly process the extension, and the application specific data encoded in an OCTET STRING. The ASN.1 specification for an X.509 v3 Certificate Extension is: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER , -- identifies extnValue syntax critical BOOLEAN DEFAULT FALSE , -- must reject if unknown extnValue OCTET STRING } -- application specific data 2. PKI for IP Address Allocation A certificate will be issued to each organization that is given ownership of a portion of the IP address space. This certificate is issued through a hierarchy of entities that, in the physical environment, is responsible for address allocation. The root of this hierarchy is ICANN, and includes at lower layers regional address space allocation authorities (e.g., ARIN, Internic, RIPE), Internet Service Providers (ISPs), Down Stream Providers (DSPs), and subscribers owning IP address prefixes. Note, however, that address assignments do not have to be certified all the way to every subscriber. If a subscriber's address is allocated from that of a DSP or an ISP with which it is currently affiliated, then the certification process need only be effected as far as the DSP/ISP. The same applies to DSPs that receive their address space assignments from ISPs. This PKI reflects the assignment of address blocks to organizations by binding address blocks to a public key belonging to the organization to whom the addresses are being assigned. It has the possible drawback that this violates the "assumption" that for a typical X.509 certificate, the issuer is vouching for the identity of the subject. Instead, these certificates will be used for proving ownership of a block of addresses. In Figure 1 below, (a) ICANN is the root and issues certificates to the first tier of organizations (Org1_x). At present, Org1_x could be an Internet Registry, an ISP, an organization, etc. ICANN signs the tier 1 certificates using its private key. A certificate extension is used to specify a list of address families and address blocks. The alternate name in the certificate is the DNS name of the Expires December 1999 CLynn [Page 4] Internet Draft X.509 Extensions for Authorization June 1999 organization. (b) Org1_x then assigns sub-blocks of its address space to ISPs, DSPs, etc. In the diagram, for example, Org1_1 issues a certificate to each of Org2_1 through Org2_7 while Org1_N issues a certificate to Org2_8. Org1_x signs the certificate using the private key corresponding to the public key in the certificate it received in (a). The same certificate extension as in (a) is used to specify a list of address families and address blocks to be delegated to ISPs, DSP, etc. The alternate name in the certificate is the DNS name of the organization. (c) Org2_x then assigns sub-blocks of its address space to DSPs, customers, etc. In the diagram, Org2_1 issues a certificate to each of Org3_1 through Org3_4. Org2_x signs the certificate using the private key corresponding to the public key in the certificate it received in (b). The same certificate extension is used to specify a list of address families and address blocks to be delegated to organizations. The alternate name in the certificate is the DNS name of the organization. (d) And so on.... ICANN Addr block(s) | +----------------+---------+++---------+ | | ||| | Org1_1 Org1_2 ... Org1_N Addr block(s) Addr block(s) Addr block(s) | | +--------+++--------+ | | ||| | | Org2_1 ... Org2_7 Org2_8 Addr block(s) Addr block(s) Addr block(s) | +--------+++--------+ | ||| | Org3_1 ... Org3_4 Addr block(s) Addr block(s) Org1_x = a 1st tier organization, e.g., an Internet Registry Org2_x = a 2nd tier organization, e.g., an ISP or organization Org3_x = a 3rd tier organization, e.g., an organization or DSP Figure 1. IP Address Assignment PKI Hierarchy Expires December 1999 CLynn [Page 5] Internet Draft X.509 Extensions for Authorization June 1999 2.1. IP Address Block Certificate Extension X.509 v3 Certificate Extension with OID XXX is used to bind the subject organization and its public key to one or more address prefixes. This extension is CRITICAL since, for a given certificate, the certificate user must verify that all prefixes and address ranges present in the extension are subsets of those present in the certificate of the certificate authority that signed the given certificate. The type of address is specified by the addressFamily OCTET STRING. The values of the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) are specified on the IANA web page http://www.iana.org under the "Address Family Numbers" item, or in RFC 1700 [RFC 1700]. The 16-bit AFI and 8-bit SAFI are encoded as three octets: two octets of AFI followed by a single octet of SAFI (see [RFC 2283]). When the maxIPAddress element is not present, the minIPPrefix OCTET STRING contains a list of address prefixes, encoded as specified in the "NLRI encoding" section of the BGP Multiprotocol RFC (RFC 1771). Each prefix is encoded as a one-octet count of significant (left- most) bits (0 to 255) in the prefix, followed by as many address prefix octets as are required to hold that many bits. The value of any bits beyond those specified in the count octet should be zero. When the maxIPAddress element is present, an address range that is not a power of two can be expressed. The minIPPrefix OCTET STRING contains a list of the low end address items in a range of addresses, and the corresponding items in the maxIPAddress OCTET STRING contains the high end addresses. If the number of significant bits is less than the number of bits in an address of the specified family, then any unspecified bits default to zero bits in minIPPrefix and one bits in maxIPAddress. IPAddressRanges ::= SEQUENCE OF IPAddressRange IPAddressRange ::= SEQUENCE { addressFamily OCTET STRING, minIPPrefix OCTET STRING, maxIPAddress OCTET STRING OPTIONAL } -- when only a minIPPrefix is present, it represents a list -- of address prefixes -- when both minIPPrefix and maxIPAddress are present, they -- are minimum and maximum values in an address range 2.2. Examples An extension that specifies net 10, i.e., 10/8 or addresses 10.0.0.0 through 10.255.255.255 would be (in hexadecimal): Expires December 1999 CLynn [Page 6] Internet Draft X.509 Extensions for Authorization June 1999 20 len Extension 06 len XXX extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 0D extnValue OCTET STRING } 20 0B IPAddressRanges 20 09 IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 04 02 08 0A minIPPrefix -- 10/8 An extension specifying 10/8, 172.16/12, 192.168/16 and 5800::/8 would be: 20 len Extension 06 len XXX extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN -- TRUE 04 20 extnValue OCTET STRING } 20 1E IPAddressRanges 20 1C IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 04 08 08 0A minIPPrefix -- 10/8 0C AC 10 -- 172.16/12 10 C0 A8 -- 192.168/16 20 09 IPAddressRange 04 03 00 02 01 addressFamily -- IPv6 Unicast 04 02 08 58 minIPPrefix -- 5800::/8 An extension specifying 10.16.0.0 to 10.48.255.255 would be: 20 len Extension 06 len XXX extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 13 extnValue OCTET STRING } 20 11 IPAddressRanges 20 0F IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 04 03 0C 0A 10 minIPPrefix -- 10.16.0.0 04 03 0C 0A 3F maxIPAddress -- 10.48.255.255 2.3. Certification Path Verification During certification path verification of a certificate containing the IP Address Block Extension, additional processing is required. Each preceding certificate in the certification path must contain an IP Address Block Extension that contains all of the IP Address Block(s) in the certificate being verified, recursively, until a trusted certificate has been verified. Expires December 1999 CLynn [Page 7] Internet Draft X.509 Extensions for Authorization June 1999 3. PKI for Assignment of ASes and Router Associations Two types of certificates will be used to support the authentication of ASes, BGP speakers and the relationship between speakers and ASes. As shown in Figure 2 below, these certificates bind together: (a) one or more a blocks of AS numbers and an organization's public key -- a registry issues these to organizations and signs them using its private key. The alternate name in the certificate is the DNS name of the organization. An extension contains the (list of) AS number(s). (b) an AS number and its public key -- An organization owning an AS number issues these and signs them using the private key corresponding to the public key in the certificate described in (a). The certificate extension containing the AS nubmer is the same as is used in (a). The alternate name in the certificate is the DNS name of the organization. (c) a router (DNS) name, a router id, an AS number, and the router's public key -- An organization owning the AS number of the AS of the router issues these and signs them using the private key corresponding to the public key in the certificate described in (a). Note that both the router id (an IP address) and the AS number are extensions in this certificate, and the binding of three items is a critical aspect of this certificate. The alternate name in the certificate is the DNS name of the router corresponding to the router id. Expires December 1999 CLynn [Page 8] Internet Draft X.509 Extensions for Authorization June 1999 ICANN list of AS#s | +++---------+---------+++ ||| | ||| ... Registry ... list of AS#s | +---------------+-------+++--------+ | | ||| | Org-1 Org-2 ... Org-N list of AS#s list of AS#s list of AS#s | +------------------+ | | +----+++---+ +-----+++-----+ | ||| | | ||| | AS-1 ... AS-N Rtr-1 ... Rtr-N AS# AS# AS-1 AS-N RtrId-1 RtrId-N Org-N = DNS Name of ISP/DSP/Organization N AS-N = DNS Name of Autonomous System N Rtr-N = DNS Name of router N RtrId-N = Router identifier (IP address) of router N Figure 2. AS Number Assignment and Router PKI Hierarchy 3.1. Autonomous System Number Extension X.509 v3 Certificate Extension with OID YYY is used to bind the subject organization and its public key to one or more Autonomous System Number ranges. An Autonomous System Number is currently an unsigned 16-bit unsigned quantity, but may be enlarged in the future. This extension is CRITICAL since, for a given certificate, all Autonomous System number ranges present in the extension must be subsets of those present in the certificate of the certificate authority that signed the given certificate. Each range of Autonomous System Numbers is encoded in an ASNumberRange sequence by placing the low end of the range in the minASNumber OCTET STRING and the high end of the range in the maxASNumber OCTET STRING. If a single Autonomous System Number is being specified, the maxASNumber element is omitted. ASNumberRanges ::= SEQUENCE OF ASNumberRange ASNumberRange ::= SEQUENCE { minASNumber OCTET STRING, maxASNumber OCTET STRING OPTIONAL } -- OCTET STRING length is currently 2k Autonomous System Numbers Expires December 1999 CLynn [Page 9] Internet Draft X.509 Extensions for Authorization June 1999 3.1.1. Example An extension that specifies Autonomous System Numbers 3000 to 3999 would be (in hexadecimal): 20 len Extension 06 len yyy extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 0C extnValue OCTET STRING } 20 0A ASNumberRanges 20 08 ASNumberRange 04 02 0b b8 minASNumber -- 3000 04 02 0f 9f maxASNumber -- 3999 3.1.2. Certification Path Verification During certification path verification of a certificate containing the Autonomous System Number Extension, additional processing is required. Each preceding certificate in the certification path must contain an Autonomous System Number Extension that contains all of the Autonomous System Number(s) in the certificate being verified, recursively, until a trusted certificate has been verified. 3.2. Router Authorization Certificate Extension X.509 v3 Certificate Extension with OID ZZZ is used to bind the subject router (specified, e.g., by a DNS name), its public key, its BGP Router Identifier (currently a 32-bit IPv4 address), and the number of the Autonomous System of which the router is an authorized BGP speaker. This extension is not CRITICAL. Currently, the owningASNumber OCTET STRING would have a length of two and the routerId OCTET STRING a length of four. RouterIdentifiers ::= SEQUENCE { owningASNumber OCTET STRING, routerId OCTET STRING } 3.2.1. Example An extension in the certificate for a router with BGP Router Identifier 10.0.0.1 in Autonomous System 3456 would be (in hexadecimal): Expires December 1999 CLynn [Page 10] Internet Draft X.509 Extensions for Authorization June 1999 20 len Extension 06 len zzz extnID OBJECT IDENTIFIER , critical BOOLEAN DEFAULT FALSE , 04 0C extnValue OCTET STRING } 20 0A RouterIdentifiers 04 02 0d 80 owningASNumber 04 04 0A 00 00 01 routerId 3.2.2. Certification Path Verification During certification path verification of a certificate containing the Router Authorization Extension, additional processing is required. The issuer's certificate must contain an Autonomous System Number Extension that contains the owningASNumber in one of its ASNumberRange elements. 4. Security Considerations This specification is devoted to the format and encoding of three extensions for X.509 certificates. Since certificates are digitally signed, no additional integrity service is necessary. Certificates need not be kept secret, and unrestricted and anonymous access to certificates and CRLs has no security implications. However, security factors outside the scope of this specification will affect the assurance provided to certificate users. This section highlights critical issues that should be considered by implementors, administrators, and users. The procedures performed by CAs and RAs to validate the binding of the subject's identity and their public key greatly affects the assurance that should be placed in the certificate. Certificate users may wish to review the CA's certificate practice statement to determine what level of assurance, if any, may be associated with the identity of the subject of the certificate. The protection afforded private keys is a critical factor in maintaining security. Failure of organizations or routers to protect their private keys will permit an attacker to masquerade as them. The availability and freshness of revocation information will affect the degree of assurance that should be placed in a certificate. While certificates expire naturally, events may occur during its natural lifetime which negate the binding between the subject and either public key or the information in the extension. If revocation information is untimely or unavailable, the assurance associated with the bindings is clearly reduced. Similarly, implementations of the additional Certification Path Verification mechanisms described in Expires December 1999 CLynn [Page 11] Internet Draft X.509 Extensions for Authorization June 1999 sections 2.3, 3.1.2, and 3.3.2 that omit revocation checking provide less assurance than those that support it. Certification Path Verification depends on the certain knowledge of the public keys (and other information) about one or more trusted CAs. The decision to trust a CA is an important decision as it ultimately determines the trust afforded a certificate. The authenticated distribution of trusted CA public keys (usually in the form of a "self-signed" certificate) is a security critical out of band process that is beyond the scope of this specification. In addition, where a key compromise or CA failure occurs for a trusted CA, the user will need to modify the information provided to the Certification Path Verification routine. The quality of implementations that process certificates may also affect the degree of assurance provided. Certification Path Verification relies upon the integrity of the trusted CA information, and especially the integrity of the public keys associated with the trusted CAs. By substituting public keys for which an attacker has the private key, an attacker could trick the user into accepting false certificates. The binding between a key and resources specified in the certificate extension cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. 5. Acknowledgements PKIX doc for security concerns section ... 6. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Expires December 1999 CLynn [Page 12] Internet Draft X.509 Extensions for Authorization June 1999 rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. References [1] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", , August 1998. [3] S. Murphy, "BGP Security Analysis", draft-murphy-bgp- secr-02.txt, NOV 1998. [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. (see also http://www.iana.org/iana/assignments.html) [RFC 2283] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Extensions for BGP-4", February 1998 [X.509] ITU-T Recommendation X.509 (1997 E): "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997. 8. Author's Addresses Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 CLynn@BBN.Com Expires December 1999 CLynn [Page 13]