Request for Comments: 3779 S. Kent
Category: Standards Track K. Seo
BBN Technologies
June 2004
X.509 Extensions for IP Addresses and AS Identifiers
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines two X.509 v3 certificate extensions. The first
binds a list of IP address blocks, or prefixes, to the subject of a
certificate. The second binds a list of autonomous system
identifiers to the subject of a certificate. These extensions may be
used to convey the authorization of the subject to use the IP
addresses and autonomous system identifiers contained in the
extensions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Delegation Extension. . . . . . . . . . . . . . . . 5
2.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Encoding of an IP Address or Prefix. . . . . . . 5
2.1.2. Encoding of a Range of IP Addresses. . . . . . . 7
2.2. Specification. . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. Type IPAddrBlocks. . . . . . . . . . . 9
2.2.3.2. Type IPAddressFamily . . . . . . . . . 9
2.2.3.3. Element addressFamily. . . . . . . . . 10
2.2.3.4. Element ipAddressChoice and Type
IPAddressChoice. . . . . . . . . . . . 10
2.2.3.5. Element inherit. . . . . . . . . . . . 10
2.2.3.6. Element addressesOrRanges. . . . . . . 10
2.2.3.7. Type IPAddressOrRange. . . . . . . . . 11
2.2.3.8. Element addressPrefix and Type
IPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. Element addressRange and Type
IPAddressRange . . . . . . . . . . . . 12
2.3. IP Address Delegation Extension Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . 12
3. Autonomous System Identifier Delegation Extension. . . . . . . 13
3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Criticality. . . . . . . . . . . . . . . . . . . 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1. Type ASIdentifiers . . . . . . . . . . 14
3.2.3.2. Elements asnum, rdi, and Type
ASIdentifierChoice . . . . . . . . . . 14
3.2.3.3. Element inherit. . . . . . . . . . . . 15
3.2.3.4. Element asIdsOrRanges. . . . . . . . . 15
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . 15
3.2.3.6. Element id . . . . . . . . . . . . . . 15
3.2.3.7. Element range. . . . . . . . . . . . . 15
3.2.3.8. Type ASRange . . . . . . . . . . . . . 15
3.2.3.9. Elements min and max . . . . . . . . . 15
3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation. . . . . . . . . . . . . . . . 16
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
Appendix C -- Example of an AS Identifier Delegation Extension . . 21
Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . . . 25
Authors’ Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
This document defines two X.509 v3 certificate extensions that
authorize the transfer of the right-to-use for a set of IP addresses
and autonomous system identifiers from IANA through the regional
Internet registries (RIRs) to Internet service providers (ISPs) and
user organizations. The first binds a list of IP address blocks,
often represented as IP address prefixes, to the subject (private key
holder) of a certificate. The second binds a list of autonomous
system (AS) identifiers to the subject (private key holder) of a
certificate. The issuer of the certificate is an entity (e.g., the
IANA, a regional Internet registry, or an ISP) that has the authority
to transfer custodianship of ("allocate") the set of IP address
blocks and AS identifiers to the subject of the certificate. These
certificates provide a scalable means of verifying the right-to-use
for a set of IP address prefixes and AS identifiers. They may be
used by routing protocols, such as Secure BGP [S-BGP], to verify
legitimacy and correctness of routing information, or by Internet
routing registries to verify data that they receive.
Sections 2 and 3 specify several rules about the encoding of the
extensions defined in this specification that MUST be followed.
These encoding rules serve the following purposes. First, they
result in a unique encoding of the extension’s value; two instances
of an extension can be compared for equality octet-by-octet. Second,
they achieve the minimal size encoding of the information. Third,
they allow relying parties to use one-pass algorithms when performing
certification path validation; in particular, the relying parties do
not need to sort the information, or to implement extra code in the
subset checking algorithms to handle several boundary cases
(adjacent, overlapping, or subsumed ranges).
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" [RFC3280], "INTERNET
PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing
Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION GUIDELINES"
[RFC2050], and related regional Internet registry address management
policy documents. Some relevant terms include:
allocate - the transfer of custodianship of a resource to an
intermediate organization (see [RFC2050]).
assign - the transfer of custodianship of a resource to an end
organization (see [RFC2050]).
Autonomous System (AS) - a set of routers under a single technical
administration with a uniform policy, using one or more interior
gateway protocols and metrics to determine how to route packets
within the autonomous system, and using an exterior gateway
protocol to determine how to route packets to other autonomous
systems.
Autonomous System number - a 32-bit number that identifies an
autonomous system.
delegate - transfer of custodianship (that is, the right-to-use) of
an IP address block or AS identifier through issuance of a
certificate to an entity.
initial octet - the first octet in the value of a DER encoded BIT
STRING [X.690].
IP v4 address - a 32-bit identifier written as four decimal numbers,
each in the range 0 to 255, separated by a ".". 10.5.0.5 is an
example of an IPv4 address.
IP v6 address - a 128-bit identifier written as eight hexadecimal
quantities, each in the range 0 to ffff, separated by a ":".
2001:0:200:3:0:0:0:1 is an example of an IPv6 address. One string
of :0: fields may be replaced by "::", thus 2001:0:200:3::1
represents the same address as the immediately preceding example.
(See [RFC3513]).
prefix - a bit string that consists of some number of initial bits of
an address, written as an address followed by a "/", and the
number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
(or 2001:0:200:3::/64) are examples of prefixes. A prefix is
often abbreviated by omitting the less-significant zero fields,
but there should be enough fields to contain the indicated number
of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of
abbreviated prefixes.
Regional Internet Registry (RIR) - any of the bodies recognized by
IANA as the regional authorities for management of IP addresses
and AS identifiers. At the time of writing, these include
AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC.
right-to-use - for an IP address prefix, being authorized to specify
the AS that may originate advertisements of the prefix throughout
the Internet. For an autonomous system identifier, being
authorized to operate a network(s) that identifies itself to other
network operators using that autonomous system identifier.
subsequent octets - the second through last octets in the value of a
DER encoded BIT STRING [X.690].
trust anchor - a certificate that is to be trusted when performing
certification path validation (see [RFC3280]).
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [RFC2119].
2. IP Address Delegation Extension
This extension conveys the allocation of IP addresses to an entity by
binding those addresses to a public key belonging to the entity.
2.1. Context
IP address space is currently managed by a hierarchy nominally rooted
at IANA, but managed by the RIRs. IANA allocates IP address space to
the RIRs, who in turn allocate IP address space to Internet service
providers (ISPs), who may allocate IP address space to down stream
providers, customers, etc. The RIRs also may assign IP address space
to organizations who are end entities, i.e., organizations who will
not be reassigning any of their space to other organizations. (See
[RFC2050] and related RIR policy documents for the guidelines on the
allocation and assignment process).
The IP address delegation extension is intended to enable
verification of the proper delegation of IP address blocks, i.e., of
the authorization of an entity to use or sub-allocate IP address
space. Accordingly, it makes sense to take advantage of the inherent
authoritativeness of the existing administrative framework for
allocating IP address space. As described in Section 1 above, this
will be achieved by issuing certificates carrying the extension
described in this section. An example of one use of the information
in this extension is an entity using it to verify the authorization
of an organization to originate a BGP UPDATE advertising a path to a
particular IP address block; see, e.g., [RFC1771], [S-BGP].
2.1.1. Encoding of an IP Address or Prefix
There are two families of IP addresses: IPv4 and IPv6.
An IPv4 address is a 32-bit quantity that is written as four decimal
numbers, each in the range 0 through 255, separated by a dot (".").
10.5.0.5 is an example of an IPv4 address.
An IPv6 address is a 128-bit quantity that is written as eight
hexadecimal numbers, each in the range 0 through ffff, separated by a
semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
address. IPv6 addresses frequently have adjacent fields whose value
is 0. One such group of 0 fields may be abbreviated by two
semicolons ("::"). The previous example may thus be represented by
2001:0:200:3::1.
An address prefix is a set of 2^k continuous addresses whose most-
significant bits are identical. For example, the set of 512 IPv4
addresses from 10.5.0.0 through 10.5.1.255 all have the same 23
most-significant bits. The set of addresses is written by appending
a slash ("/") and the number of constant bits to the lowest address
in the set. The prefix for the example set is 10.5.0.0/23, and
contains 2^(32-23) = 2^9 addresses. The set of IPv6 addresses
2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff
(2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or
equivalently 2001:0:200::/39. A prefix may be abbreviated by
omitting the least-significant zero fields, but there should be
enough fields to contain the indicated number of constant bits. The
abbreviated forms of the example IPv4 prefix is 10.5.0/23, and of the
example IPv6 prefix is 2001:0:200/39.
An IP address or prefix is encoded in the IP address delegation
extension as a DER-encoded ASN.1 BIT STRING containing the constant
most-significant bits. Recall [X.690] that the DER encoding of a BIT
STRING consists of the BIT STRING type (0x03), followed by (an
encoding of) the number of value octets, followed by the value. The
value consists of an "initial octet" that specifies the number of
unused bits in the last value octet, followed by the "subsequent
octets" that contain the octets of the bit string. (For IP
addresses, the encoding of the length will be just the length.)
In the case of a single address, all the bits are constant, so the
bit string for an IPv4 address contains 32 bits. The subsequent
octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00
0x04. Since all the bits in the last octet are used, the initial
octet is 0x00. The octets in the DER-encoded BIT STRING is thus:
Type Len Unused Bits ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04
Similarly, the DER-encoding of the prefix 10.5.0/23 is:
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
In this case, the three subsequent octets contain 24 bits, but the
prefix only uses 23, so there is one unused bit in the last octet,
thus the initial octet is 1 (the DER require that all unused bits
MUST be set to zero-bits).
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
Type Len Unused Bits ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
and the DER-encoding of the prefix 2001:0:200/39, which has one
unused bit in the last octet, is:
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
2.1.2. Encoding of a Range of IP Addresses
While any contiguous range of IP addresses can be represented by a
set of contiguous prefixes, a more concise representation is achieved
by encoding the range as a SEQUENCE containing the lowest address and
the highest address, where each address is encoded as a BIT STRING.
Within the SEQUENCE, the bit string representing the lowest address
in the range is formed by removing all the least-significant zero-
bits from the address, and the bit string representing the highest
address in the range is formed by removing all the least-significant
one-bits. The DER BIT STRING encoding requires that all the unused
bits in the last octet MUST be set to zero-bits. Note that a prefix
can always be expressed as a range, but a range cannot always be
expressed as a prefix.
The range of addresses represented by the prefix 10.5.0/23 is
10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen
zero-bits that are removed. The DER-encoding of the resulting
sixteen-bit string is:
Type Len Unused Bits ...
0x03 0x03 0x00 0x0a 0x05
The highest address ends in nine one-bits that are removed. The DER-
encoding of the resulting twenty-three-bit string is:
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
The prefix 2001:0:200/39 can be encoded as a range where the DER-
encoding of the lowest address (2001:0:200::) is:
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which,
after removal of the ninety least-significant one-bits leaves a
thirty-eight bit string, is encoded as:
Type Len Unused Bits ...
0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
The special case of all IP address blocks, i.e., a prefix of all
zero-bits -- "0/0", MUST be encoded per the DER with a length octet
of one, an initial octet of zero, and no subsequent octets:
Type Len Unused Bits ...
0x03 0x01 0x00
Note that for IP addresses the number of trailing zero-bits is
significant. For example, the DER-encoding of 10.64/12:
Type Len Unused Bits ...
0x03 0x03 0x04 0x0a 0x40
is different than the DER-encoding of 10.64.0/20:
Type Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x00
2.2. Specification
2.2.1. OID
The OID for this extension is id-pe-ipAddrBlocks.
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
where [RFC3280] defines:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
2.2.2. Criticality
This extension SHOULD be CRITICAL. The intended use of this
extension is to connote a right-to-use for the block(s) of IP
addresses identified in the extension. A CA marks the extension as
CRITICAL to convey the notion that a relying party MUST understand
the semantics of the extension to make use of the certificate for the
purpose it was issued. Newly created applications that use
certificates containing this extension are expected to recognize the
extension.
2.2.3. Syntax
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
2.2.3.1. Type IPAddrBlocks
The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
2.2.3.2. Type IPAddressFamily
The IPAddressFamily type is a SEQUENCE containing an addressFamily
and ipAddressChoice element.
2.2.3.3. Element addressFamily
The addressFamily element is an OCTET STRING containing a two-octet
Address Family Identifier (AFI), in network byte order, optionally
followed by a one-octet Subsequent Address Family Identifier (SAFI).
AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI],
respectively.
If no authorization is being granted for a particular AFI and
optional SAFI, then there MUST NOT be an IPAddressFamily member for
that AFI/SAFI in the IPAddrBlocks SEQUENCE.
There MUST be only one IPAddressFamily SEQUENCE per unique
combination of AFI and SAFI. Each SEQUENCE MUST be ordered by
ascending addressFamily values (treating the octets as unsigned
quantities). An addressFamily without a SAFI MUST precede one that
contains an SAFI. When both IPv4 and IPv6 addresses are specified,
the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4
AFI of 0001 is less than the IPv6 AFI of 0002).
2.2.3.4. Element ipAddressChoice and Type IPAddressChoice
The ipAddressChoice element is of type IPAddressChoice. The
IPAddressChoice type is a CHOICE of either an inherit or
addressesOrRanges element.
2.2.3.5. Element inherit
If the IPAddressChoice CHOICE contains the inherit element, then the
set of authorized IP addresses for the specified AFI and optional
SAFI is taken from the issuer’s certificate, or from the issuer’s
issuer’s certificate, recursively, until a certificate containing an
IPAddressChoice containing an addressesOrRanges element is located.
2.2.3.6. Element addressesOrRanges
The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange
types. The addressPrefix and addressRange elements MUST be sorted