30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
Appendix C -- 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 issuer’s
certificate would be (in hexadecimal):
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
Appendix D -- Use of X.509 Attribute Certificates
This appendix discusses issues arising from a proposal to use
attribute certificates (ACs, as specified in [RFC3281]) to convey,
from the Regional Internet Registries (RIRs) to the end-user
organizations, the "right-to-use" for IP address blocks or AS
identifiers.
The two resources, AS identifiers and IP address blocks, are
currently managed differently. All organizations with the right-to-
use for an AS identifier receive the authorization directly from an
RIR. Organizations with a right-to-use for an IP address block
receive the authorization either directly from an RIR, or indirectly,
e.g., from a down stream 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 for why the use of
ACs might be preferable to the 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 the IP address and AS identifier 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 often
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 randomly 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 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
Certificate 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."
Allocation from IANA to RIRs to ISPs to DSPs and assignment to end
organizations would require the use of chains, at least for IP
address blocks. A description of how the superior’s AC should be
located and how it should be processed would have to be provided.
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 delegation extensions defined in this
specification, which are critical, could not be simply placed into
an AC. They could be used if not marked critical, but the
intended use requires that the extensions be critical so that the
certificates containing 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
attribute or authorization. The intended usage for the extensions
defined herein 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 a right-to-use for an IP address
block, which is allocated through a hierarchy. Certification path
validation of the AC will require chaining up through the
delegation hierarchy. Having to configure each relying party
(NOC) to "trust" every other NOC does not scale, and such "trust"
has resulted in failures that the proposed security mechanisms 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 certificate
extensions defined in this document in the PKCs. There would be
twice as many certificates to be validated, in addition to the
ACs. There could be a considerable increase in the management
burden required to support ACs.
References
Normative References
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W. and 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
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program
Protocol Specification", RFC 791, September 1981.
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System
(AS)", BCP 6, RFC 1930, March 1996.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and
J. Postel, "Internet Registry IP Allocation Guidelines",
BCP 12, RFC 2050, November 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
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
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.