One document matched: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
Differences from draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
Internet Engineering Task Force Charles Lynn
Internet Draft Stephen Kent
draft-ietf-pkix-x509-ipaddr-as-extn-01.txt Karen Seo
Expires December 2003 BBN Technologies
June 2003
X.509 Extensions for IP Addresses and AS Identifiers
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 current Internet Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2003. All Rights Reserved.
Abstract
This document defines two private 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.
Please send comments on this draft to the ietf-pkix@imc.org mail
list.
Expires December 2003 Lynn, Kent, Seo [Page 1]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
Table of Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IP Address Delegation Extension . . . . . . . . . . . . . . . 5
2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Specification . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3.1. Type IPAddrBlocks . . . . . . . . . . . . . . . . . . . 7
2.2.3.2. Type IPAddressFamily . . . . . . . . . . . . . . . . . . 7
2.2.3.3. Element addressFamily . . . . . . . . . . . . . . . . . 7
2.2.3.4. Element ipAddressChoice and Type IPAddressChoice . . . . 7
2.2.3.5. Element inherit . . . . . . . . . . . . . . . . . . . . 7
2.2.3.6. Element addressesOrRanges . . . . . . . . . . . . . . . 8
2.2.3.7. Type IPAddressOrRange . . . . . . . . . . . . . . . . . 8
2.2.3.8. Element addressPrefix and Type IPAddress . . . . . . . . 8
2.2.3.9. Element addressRange and Type IPAddressRange . . . . . . 9
2.3. IP Address Delegation Extension Certification Path
Validation . . 10
3. Autonomous System Identifier Delegation Extension . . . . . . 10
3.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Criticality . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1. Type ASIdentifiers . . . . . . . . . . . . . . . . . . . 12
3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice . . . . 12
3.2.3.3. Element inherit . . . . . . . . . . . . . . . . . . . . 12
3.2.3.4. Element asIdOrRanges . . . . . . . . . . . . . . . . . . 12
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . . . . . . . . . . 12
3.2.3.6. Element id . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3.7. Element range . . . . . . . . . . . . . . . . . . . . . 13
3.2.3.8. Type ASRange . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3.9. Elements min and max . . . . . . . . . . . . . . . . . . 13
3.2.3.10. Type ASId . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A -- Examples of IP Address Delegation Extensions . . . . 14
Appendix B -- Example of an AS Identifier Delegation Extension . . 18
Expires December 2003 Lynn, Kent, Seo [Page 2]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
Appendix C -- Use of X.509 Attribute Certificates . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property Rights . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
Expires December 2003 Lynn, Kent, Seo [Page 3]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
1. Introduction
This document defines two private X.509 v3 certificate extensions
that authorize the transfer of the right to use IP addresses and
Autonomous System numbers 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 ("allocate") of the set of IP address
blocks and AS Identifiers to the subject of the certificate. These
certificates provide a scalable means of verifying the usage right of
IP address prefixes and AS Identifiers, and 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.
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], and "INTERNET REGISTRY IP ALLOCATION
GUIDELINES" [RFC2050] and related RIR address management policy
documents. Some relevant terms include:
Autonomous System (AS) - a set of routers under a single technical
administration, 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 [AS4Bytes].
delegate - Transfer of custodianship (that is, the usage right) 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 "."s. 10.5.0.5 is an
example.
IP v6 address - a 128-bit identifier written as eight hexadecimal
quantities, each in the range 0 to ffff, separated by ":"s.
2001:0:2:3:0:0:0:1 is an example. One string of :0: quantities
Expires December 2003 Lynn, Kent, Seo [Page 4]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
may be replaced by "::", thus 2001:0:2:3::1 represents the same
address as the immediately preceding example. (See [RFC3513]).
Regional Internet Registry (RIR) - any of the bodies recognized by
IANA as the regional authorities for management of IP addresses
and AS numbers. At 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 advertisement 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].
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 subject.
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
ISPs, customers, etc. The RIRs may also 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 delegating 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., [RFCbgp], [S-BGP].
Expires December 2003 Lynn, Kent, Seo [Page 5]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
2.2. Specification
2.2.1. OID
The OID for this extension is id-pe-ipAddrBlock.
id-pe-ipAddrBlock 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 usage right to 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-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE (2..3)), -- AFI & opt SAFI
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit BOOLEAN, -- Inherit from Issuer
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
Expires December 2003 Lynn, Kent, Seo [Page 6]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
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).
AFI's and SAFI's are specified in [IANA-AFI] and [IANA-SAFI],
respectively.
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 a 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
BOOLEAN MUST be TRUE. In this case, the set of authorized IP
addresses for the specified AFI and optional SAFI is taken from the
Issuer's certificate, or the Issuer's Issuer's certificate,
recursively, until a certificate containing an IPAddressChoice
containing an addressesOrRanges element is located. If no
authorization is being granted for a particular AFI and optional
SAFI, then there SHOULD NOT be an IPAddressFamily member for that
AFI/SAFI in the IPAddrBlocks sequence; i.e., the AFI/SAFI SHOULD be
omitted rather than setting inherit BOOLEAN to FALSE.
Expires December 2003 Lynn, Kent, Seo [Page 7]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
2.2.3.6. Element addressesOrRanges
The addressesOrRanges element is a sequence of IPAddressOrRange
types. The addressPrefixes and addressRange elements MUST be sorted
using the binary representation of <IP prefix>/<prefix length>. Note
that the bytes in this representation (a.b.c.d/length for IPv4 or
s:t:u:v:w:x:y:z/length for IPv6) are not in the same order as occurs
in a DER encoded BIT STRING. For example, given two addressPrefixes:
IP addr/length DER encoding
-------------- --------------
10.32.0.0/12 03 03 04 0a 20
10.64.0.0/16 03 03 00 0a 40
the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16
since 32 is less than 64; whereas if one were to sort by the DER BIT
STRINGs, the order would be reversed as the unused bits octet would
sort in the opposite order. Any pair of IPAddressOrRange choices in
an extension MUST NOT overlap each other. Any contiguous address
prefixes or ranges MUST be combined into a single range or, whenever
possible, a single prefix.
2.2.3.7. Type IPAddressOrRange
The IPAddressOrRange type is a CHOICE of either an addressPrefix (an
IP address Prefix) or an addressRange (an IP address range) element.
2.2.3.8. Element addressPrefix and Type IPAddress
The addressPrefix element is an IPAddress type. The IPAddress type
defines a range of IP addresses in which the most significant (left-
most) N bits of the address remain constant while the remaining bits
(32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero
or one. A prefix is written in textual form as the constant octets
followed by a "/" and the number of constant bits (N). For example,
the IPv4 prefix 10.64/12 corresponds to the addresses 10.64.0.0 to
10.79.255.255 while 10.64/11 corresponds to 10.64.0.0 to
10.95.255.255. The IPv6 prefix 2001:0:2/48 represents addresses
2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff.
An IP address prefix is encoded as a BIT STRING. The DER encoding of
a BIT STRING uses the initial octet of the string to specify how many
of the least significant bits of the last subsequent octet are
unused. DER encoding specifies that these unused bits MUST be set to
zero. The special case of all IP address blocks, i.e., a prefix of
all zero bits -- "0/0", MUST be encoded per DER with a length octet
of one, an initial octet of zero, and no subsequent octets -- 0x03,
0x01, 0x00. Note that the number of trailing zero bits is
Expires December 2003 Lynn, Kent, Seo [Page 8]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
significant for IP addresses. For example, the DER encoding of
10.64/12, 0x03, 0x03, 0x04, 0x0a, 0x40, is different than 10.64/11,
encoded as 0x03, 0x03, 0x05, 0x0a, 0x40.
2.2.3.9. Element addressRange and Type IPAddressRange
The addressRange element is of type IPAddressRange. The
IPAddressRange type consists of a SEQUENCE containing a minimum
(element min) and maximum (element max) IP address. Each IP address
is encoded as a BIT STRING. The semantic interpretation of the
minimum address in an IPAddressRange is that all the unspecified bits
(for the full length of the IP address) are zero-bits (0). The
semantic interpretation of the maximum address is that all the
unspecified bits are one-bits (1).
Note that an IP address prefix can be encoded as a range, where the
minimum and maximum values would be identical. However, a range of
IP addresses MUST, whenever possible, be encoded as a single prefix
and MUST NOT be encoded as a range.
1) Address ranges (bit strings) should be sorted into ascending order
by most-significant address bits
2) Contiguous prefixes and/or ranges MUST be combined into a single
prefix (whenever possible) or range.
Let "LMBx" denote the "Left Most Bits of x".
3) If a range is of the form minimum IP address = <n LMBp><zeros>
and maximum IP address = <n LMBp><ones>,
where n >= 0, then the prefix form MUST be used:
BIT STRING ((8 - (n mod 8)) mod 8) <n LMBp><zero pad last byte>
otherwise the min/max form MUST be used.
Example:
128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000
to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
BIT STRING 4 128 -- 1000
4) A range form with minimum IP address = <(i - 1) LMBn><1><zeros>
and maximum IP address = <(j - 1) LMBx><0><ones>
MUST be encoded as:
SEQUENCE {
BIT STRING ((8 - (i mod 8)) mod 8) <i LMBn><zero pad last
octet>
BIT STRING ((8 - (j mod 8)) mod 8) <j LMBx><zero pad last
octet> }
I.e., all trailing zero bits are removed from the min and all
trailing 1 bits are removed from the max.
Expires December 2003 Lynn, Kent, Seo [Page 9]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
Example:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
SEQUENCE {
BIT STRING 6 129 64 -- 1000 0001.01
BIT STRING 4 128 -- 1000
}
To simplify the comparison of IP address blocks when performing
certificate path validation, a maximum IP address MUST contain at
least one bit whose value is 1, i.e., the subsequent octets may
neither be omitted nor all zero.
2.3. IP Address Delegation Extension Certification Path Validation
Certification path validation of a certificate containing the IP
address delegation extension requires additional processing. As each
certificate in a path is validated, the IP addresses in the IP
address delegation extension of that certificate MUST be subsumed by
IP addresses in the IP address delegation extension in the issuer's
certificate. Validation MUST fail when this is not the case.
3. Autonomous System Identifier Delegation Extension
This extension conveys the allocation of Autonomous System (AS)
identifiers to the subject by binding those AS identifiers to a
public key belonging to the subject.
3.1. Context
AS identifier delegation is currently managed by a hierarchy
nominally rooted at IANA, but managed by the RIRs. IANA allocates AS
identifiers to the RIRs, who in turn allocate AS identifiers to
organizations who are end entities, i.e., will not be re-delegating
any of their AS identifiers to other organizations. The AS
identifier delegation extension is intended to enable verification of
the proper delegation of AS identifiers, i.e., of the authorization
of an entity to use these AS identifiers. Accordingly, it makes
sense to take advantage of the inherent authoritativeness of the
existing administrative framework for delegating AS identifiers. 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 manage the
AS identified by an AS identifier in the extension.
Expires December 2003 Lynn, Kent, Seo [Page 10]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
3.2. Specification
3.2.1. OID
The OID for this extension is id-pe-autonomousSysId.
id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 }
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 }
3.2.2. Criticality
This extension SHOULD be CRITICAL. The intended use of this
extension is to connote usage right to the AS identifiers 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.
3.2.3. Syntax
id-pe-autonomousSysId OBJECT IDENTIFIER ::= { id-pe 8 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit BOOLEAN, -- Inherit from Issuer
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
Expires December 2003 Lynn, Kent, Seo [Page 11]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
3.2.3.1. Type ASIdentifiers
The ASIdentifiers type is a SEQUENCE containing one or more forms of
Autonomous System identifiers -- AS numbers (in the asnum element) or
Routing Domain Identifiers (in the rdi element). When the
ASIdentifiers type contains multiple forms of identifiers, the asnum
entry MUST precede the rdi entry. AS numbers are used by BGP and
Routing Domain Identifiers are specified in the IDRP.
3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice
The asnum and rdi elements are both of type ASIdentifierChoice. The
ASIdentifierChoice type is a CHOICE of either the inherit or
asIdsOrRanges element.
3.2.3.3. Element inherit
If the ASIdentifierChoice choice contains the inherit element, then
the BOOLEAN MUST be TRUE. In this case, the set of authorized AS
identifiers is taken from the Issuer's certificate, or the Issuer's
Issuer's certificate, recursively, until a certificate containing an
ASIdentifierChoice containing an asIdsOrRanges element is located.
If no authorization is being granted for a particular form of AS
identifier then there MUST NOT be an asnum/rdi member in the
ASIdentifiers sequence; i.e., the member MUST be omitted rather than
setting inherit BOOLEAN to FALSE.
3.2.3.4. Element asIdsOrRanges
The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any
pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any
contiguous AS identifiers MUST be combined into a single range
whenever possible. The AS identifiers in the asIdsOrRanges element
MUST be sorted by increasing numeric value.
3.2.3.5. Type ASIdOrRange
The ASIdOrRange type is a CHOICE of either a single integer (ASId) or
a single sequence (ASRange).
3.2.3.6. Element id
The id element has type ASId.
Expires December 2003 Lynn, Kent, Seo [Page 12]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
3.2.3.7. Element range
The range element has type ASRange.
3.2.3.8. Type ASRange
The ASRange type is a SEQUENCE of a min and a max element and is used
to specify a range of AS identifier values.
3.2.3.9. Elements min and max
The min and max elements have type ASId. The min element is used to
specify the value of the minimum AS identifier in the range and the
max elements specifies the value of the maximum AS identifier in the
range.
3.2.3.10. Type ASId
The ASId type is an INTEGER.
3.3. Autonomous System Identifier Delegation Extension Certification
Path Validation
Certification path validation of a certificate containing the
Autonomous System identifier delegation extension requires additional
processing. As each certificate in a path is validated, the AS
identifiers in the Autonomous System identifier delegation extension
of that certificate MUST be subsumed by the AS identifiers in the
Autonomous System identifier delegation extension in the issuer's
certificate. Validation MUST fail when this is not the case.
4. Security Considerations
This specification describes two private X.509 extensions. Since
X.509 certificates are digitally signed, no additional integrity
service is necessary. Certificates with these extensions need not be
kept secret, and unrestricted and anonymous access to these
certificates 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.
These extensions represent authorization information, i.e., usage
right to IP addresses or AS identifiers. They were developed to
Expires December 2003 Lynn, Kent, Seo [Page 13]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
support a secure version of BGP [S-BGP], but may be employed in other
contexts. In the secure BGP context, certificates containing these
extensions function as capabilities: the certificate asserts that the
holder of the private key (the Subject) is authorized to use the IP
addresses or AS identifiers represented in the extension(s). As a
result of this capability model, the Subject field is largely
irrelevant for security purposes, contrary to common PKI conventions.
5. Acknowledgements
The authors would like to acknowledge the contributions to this
specification by Charles Gardiner and Russ Housley.
Appendix A -- Examples of IP Address Delegation Extensions
A critical X.509 v3 certificate extension that specifies:
IPv4 unicast address prefixes
1) 10.0.32/20 i.e., 10.0.32.0 to 10.0.47.255
2) 10.0.64/24 i.e., 10.0.64.0 to 10.0.64.255
3) 10.1/16 i.e., 10.1.0.0 to 10.1.255.255
4) 10.2.48/20 i.e., 10.2.48.0 to 10.2.63.255
5) 10.2.64/24 i.e., 10.2.64.0 to 10.2.64.255
6) 10.3/16 i.e., 10.3.0.0 to 10.3.255.255, and
7) inherits all IPv6 addresses from the Issuer's certificate
would be (in hexadecimal):
Expires December 2003 Lynn, Kent, Seo [Page 14]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
30 47 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 38 extnValue {
30 36 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice {
30 24 addressesOrRanges {
IPAddressOrRange {
03 04 04 0a0020 addressPrefix 10.0.32/20
} -- IPAddressOrRange
IPAddressOrRange {
03 04 00 0a0040 addressPrefix 10.0.64/24
} -- IPAddressOrRange
IPAddressOrRange {
03 03 00 0a01 addressPrefix 10.1/16
} -- IPAddressOrRange
IPAddressOrRange {
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
} -- IPAddressOrRange
IPAddressOrRange {
03 03 00 0a03 addressPrefix 10.3/16
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice
} -- IPAddressFamily
30 07 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice {
01 01 ff inherit: TRUE from Issuer
} -- IPAddressChoice
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
This example illustrates how the prefixes and ranges are sorted.
+ Prefix 1 MUST precede prefix 2, even though the number of unused
bits (4) in prefix 1 is larger than the number of unused bits (0)
in prefix 2.
+ Prefix 2 MUST precede prefix 3 even though the number of octets
(4) in the BIT STRING encoding of prefix 2 is larger than the
number of octets (3) in the BIT STRING encoding of prefix 3.
+ Prefixes 4 and 5 are adjacent (representing the range of addresses
Expires December 2003 Lynn, Kent, Seo [Page 15]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range
(since the range cannot be encoded by a single prefix).
+ Note that the six trailing zero bits in the max element of the
range are significant to the semantic interpretation of the value
(as all unused bits are interpreted to be 1's, not 0's). The four
trailing zero bits in the min element are not significant and MUST
be removed (thus the (4) unused bits in the encoding of the min
element). (DER encoding requires that any unused bits in the last
subsequent octet be set to zero.)
+ The range formed by prefixes 4 and 5 MUST precede prefix 6 even
though the SEQUENCE encoding for a range (30) is larger than the
encoding for the BIT STRING (03) used to encode prefix 6.
+ The IPv4 information MUST precede the IPv6 information since the
address family identifier for IPv4 (0001) is less than the
identifier for IPv6 (0002).
An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4
prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast
addresses from the issuer's certificate would be:
Expires December 2003 Lynn, Kent, Seo [Page 16]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
30 3e Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2f extnValue {
30 2d IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice {
30 09 addressesOrRanges {
IPAddressOrRange {
03 02 00 0a addressPrefix 10/8
} -- IPAddressOrRange
IPAddressOrRange {
03 03 04 b010 addressPrefix 172.16/12
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice
} -- IPAddressFamily
30 08 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice {
01 01 ff inherit: TRUE from Issuer
} -- IPAddressChoice
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice {
30 09 addressesOrRanges {
IPAddressOrRange {
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- IPAddressOrRange
} -- addressesOrRanges
} -- IPAddressChoice
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
Expires December 2003 Lynn, Kent, Seo [Page 17]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
Appendix B -- Example of an AS Identifier Delegation Extension
An extension that specifies AS Numbers 135, 3000 to 3999, and 5001,
and which inherits all Routing Domain Identifiers from the issuers
certificate would be (in hexadecimal):
30 2c Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1d extnValue {
30 1b ASIdentifiers {
a0 14 asnum
ASIdentifierChoice {
30 12 asIdsOrRanges {
ASIdOrRange {
02 02 0087 ASId
} -- ASIdOrRange
ASIdOrRange {
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
} -- ASIdOrRange
ASIdOrRange {
02 02 1389 ASId
} -- ASIdOrRange
} -- asIdsOrRanges
} -- ASIdentifierChoice
} -- asnum
a1 03 rdi {
ASIdentifierChoice {
01 01 ff inherit
} -- ASIdentifierChoice
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
Expires December 2003 Lynn, Kent, Seo [Page 18]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
Appendix C -- Use of X.509 Attribute Certificates
This appendix discusses issues arising from a proposal to use
Attribute Certificates (ACs, as specified in RFC 3281) [RFC3281] to
convey, from the Regional Internet Registries (RIRs) to the end-user
organizations (orgs), the "right-to-use" IP address blocks or AS
identifiers.
The two resources, AS numbers and IP address blocks, are currently
managed differently. All orgs with the right-to-use an AS number
receive the authorization directly from an RIR. Orgs with a right-
to-use an IP address block receive the authorization either directly
from an RIR, or indirectly, e.g., from a Downstream Service Provider,
who might receive its authorization from an Internet Service
Provider, who in turn gets its authorization from a RIR. Note that
AS identifiers might be sub-allocated in the future, so the
mechanisms used should not rely upon a three level hierarchy.
In section 1 of RFC 3281, two reasons are given why the use of ACs
might be preferable to use of Public Key Certificates (PKCs) with
extensions that convey the authorization information:
"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime.
Second, the PKC issuer is not usually authoritative for the
authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the
authoritative source."
"For these reasons, it is often better to separate authorization
information from the PKC. Yet, authorization information also
needs to be bound to an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes."
In the case of these authorizations, these reasons do not apply.
First, the public key certificates are issued exclusively for
authorization, so the certificate lifetime corresponds exactly to the
authorization lifetime, which is tied to a contractual relationship
between the issuer and entity receiving the authorization. The
Subject and Issuer names are only used for chaining during
certification path validation, and the names need not correspond to
any physical entity. The Subject name in the PKCs may actually be
assigned by the issuing CA, allowing the resource holder limited
anonymity. Second, the certificate hierarchy is constructed so that
the certificate issuer is authoritative for the authorization
Expires December 2003 Lynn, Kent, Seo [Page 19]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
information.
Thus the two points in the first cited paragraph above are not true
in the case of AS number and IP address block allocations. The point
of the second cited paragraph is also not applicable as the resources
are not being bound to an identity but to the holder of the private
key corresponding to the public key in the PKC.
RFC 3281 specifies several requirements that a conformant Attribute
Certificates must meet. In relation to S-BGP, the more significant
requirements are:
1 from section 1: "this specification does NOT RECOMMEND the use of
AC chains. Other (future) specifications may address the use of
AC chains."
Delegation from IANA to RIRs to ISPs to DSPs to end organizations
would require the use of chains, at least for IP address block
delegation. We would have to provide a description of how the
superior's AC should be located and its processed. Readers of
this document are encouraged to propose ways the chaining might be
avoided.
2 from section 4.2.9: "section 4.3 defines the extensions that MAY
be used with this profile, and whether or not they may be marked
critical. If any other critical extension is used, the AC does
not conform to this profile. However, if any other non-critical
extension is used, the AC does conform to this profile."
This means that the existing delegation extensions, which are
critical, could not be simply placed into an AC. They could be
used if not marked critical, but the intended use requires the
extensions be critical so that the certificates that contain them
cannot be used as identity certificates by an unsuspecting
application.
3 from section 4.5: "an AC issuer MUST NOT also be a PKC Issuer.
That is, an AC issuer cannot be a CA as well."
This means that for each AC issuer there would need to be a
separate CA to issue the PKC that contains the public key of the
AC holder. The AC issuer cannot issue the PKC of the holder, and
the PKC issuer cannot sign the AC. Thus each entity in the PKI
would need to operate an AC issuer in addition to its CA.There
would be twice as many certificate issuers, and CRLs to process,
to support Attribute certificates than are needed if PKCs are
used. The possibility of mis-alignment also arises when there are
two issuers issuing certificates for a single purpose.
The AC model of RFC 3281 implies that the AC holder presents the
AC to the AC verifier when the holder wants to substantiate an
Expires December 2003 Lynn, Kent, Seo [Page 20]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
attribute or authorization. The intended usage does not have a
direct interaction between an AC verifier (a NOC) and the AC
issuers (all RIRs and NOCs). Given a signature on a claimed right
to use object, the "AC verifier" can locate the AC holder's PKC,
but there is no direct way to locate the Subject's AC(s).
4 from section 5: "4. The AC issuer MUST be directly trusted as an
AC issuer (by configuration or otherwise)."
This is not true in the case of right to use an IP address block,
which is delegated through a hierarchy. Path validation of the AC
will require chaining up through the delegation hierarchy. Having to
configure each replying party (NOC) to "trust" every other NOC does
not scale, and such "trust" has resulted in failures that the
proposed security mechanism are designed to prevent. A single PKI
with a trusted root is used, not thousands of individually trusted
per-ISP AC issuers.
The amount of work that would be required to properly validate an AC
is larger than for the mechanism that places the S-BGP extensions in
the PKCs. There are twice as many certificates to be validated, in
addition to the ACs. There could be considerable increase in the
management burden required to support ACs.
Expires December 2003 Lynn, Kent, Seo [Page 21]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
References
Normative References
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI]http://www.iana.org/assignments/safi-namespace.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 00009, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3279] W. Polk, R. Housley, and L. Bassham, " Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC3280] R. Housley, W. Polk, W. Ford, D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
"Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)".
Informational References
[AS4Bytes] Q. Vohra, and E. Chen, "BGP support for four-octet AS
number space", draft-ietf-idr-as4bytes-05.txt, May 2002.
[RFC2050] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J.
Postel, "Internet Registry IP Allocation Guidelines", RFC
2050, BCP 00012, November 1996.
[RFC3513] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[RFC3280] R. Housley, W., Polk, W. Ford, D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3281] S. Farrell, and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[RFCbgp] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol
Expires December 2003 Lynn, Kent, Seo [Page 22]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
4 (BGP-4)", draft-ietf-idr-bgp4-20.txt
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
[X.509] ITU-T Recommendation X.509 (1997 E): "Information
Technology - Open Systems Interconnection - The Directory:
Authentication Framework", June 1997.
Disclaimer
The views and specification here are those of the authors and are not
necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Authors' Address
Charles Lynn
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3367
Email: CLynn@BBN.Com
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
Email: Kent@BBN.Com
Karen Seo
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3152
Email: KSeo@BBN.Com
Expires December 2003 Lynn, Kent, Seo [Page 23]
Internet Draft X.509 Extensions for IP Addr and AS ID June 2003
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 assurance 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
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
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
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 shall 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.
Expires December 2003 Lynn, Kent, Seo [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-22 19:16:29 |