One document matched: draft-rgaglian-lisp-iao-00.txt
Internet Engineering Task Force R. Gagliano
Internet-Draft LACNIC
Intended status: Informational March 25, 2009
Expires: September 22, 2009
A Profile for Endpoint Identifier Origin Authorizations (IOA)
draft-rgaglian-lisp-iao-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 22, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines a standard profile for End-Point Identifiers
Origin Authorizations (IOAs). An IOA is a digitally signed object
that provides a means of verifying that the EID IP address block
Gagliano Expires September 22, 2009 [Page 1]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
holder has authorized a set of Router Locators (RLOCs) as its de-
encapsulation point in a Map & Encap mapping service.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Securing the Mapping functions and its relationship to RPKI . 3
3. IOA Especification . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4
3.2. version . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. digestAlgorithms . . . . . . . . . . . . . . . . . . . . . 4
3.4. encapContentInfo . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. eContentType . . . . . . . . . . . . . . . . . . . . . 5
3.4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. certificates . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. crls . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. signerInfos . . . . . . . . . . . . . . . . . . . . . . . 7
3.7.1. version . . . . . . . . . . . . . . . . . . . . . . . 7
3.7.2. sid . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . 8
3.7.4. signedAttrs . . . . . . . . . . . . . . . . . . . . . 8
4. IOA Validation . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Gagliano Expires September 22, 2009 [Page 2]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
1. Introduction
Map & Encap solutions such as LISP [I-D.ietf-sidr-res-certs] or APT
[I-D.jen-apt] require the existence of a mapping service that given a
destination EID returns the correspondant globally reachable RLOC.
The primary purpose of the Internet IP Address and AS Number Resource
Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch] system is to
improve routing security. In a Map and Encap environment that needs
to include the mapping service, where the authorization for a set of
RLOC as a de-encap point for a particular EID needs to be verifiable.
The IOA provides this function.
An IOA is a digitally signed object that makes use of Cryptographic
Message Syntax (CMS) [RFC3852] as a standard encapsulation format.
CMS was chosen to take advantage of existing open source software
available for processing messages in this format.
This spec is based on the ROA especification at
[I-D.ietf-sidr-roa-format].
2. Securing the Mapping functions and its relationship to RPKI
IP addresses are allocated following [RFC2050] in a hierarchy that
considers allocations from IANA to Regional Internet Registries
(RIRs) and from RIRs to other registries (such as LIR, NIR or ISPs).
Following the RPKI Architecture, each resource holder will be
provided with a certificate with RFC3779 [RFC3779] extension that
ennumerates the IP address prefixes and Autonomous System numbers
(ASNs) that the particular resource holder has the right to use.
RPKI has been propossed to improve security in the inter-domain
routing system, particularly to validade the authorization of a
particular ASN to originate a BGPv4 address prefix announcement. The
relationship between the address prefix and the ASN that is
authorized to originate the BGP announcement is done by the existance
of a ROA. Signed material such as ROAs are hosted in a publicly
available repository.
Using the same ideas for verifying the authorization of a particular
ASN to originate a prefix, it is possible that the EID IP address
block holder signs the authorization of a particular set of RLOC to
populate the mapping database in a Map & Encap solution. This signed
objects may be used by:
a. the mapping service to verify every entry before accepting them
in its mapping database.
Gagliano Expires September 22, 2009 [Page 3]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
b. the mapping clients to verify the mapping service reponses.
IOA are not intended to be used neither to sign nor encrypt mapping
messages. The securization of the communication channel between the
mapping service and its clients will depend on the architecture to be
implemented.
3. IOA Especification
Using CMS syntax an IOA is a signed-data object. The general format
of a CMS object is:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
As an IOA is a signed-data object. it uses the corresponding OID
1.2.840.113549.1.7.2. [RFC3852].
3.1. Signed-Data Content Type
According to the CMS standard, the signed-data content type shall
have ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
3.2. version
The version is the syntax version number. It MUST be 3,
corresponding to the signerInfo structure having version number 3.
3.3. digestAlgorithms
The digestAlgorithms set MUST include only SHA-256, the OID for which
is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other
Gagliano Expires September 22, 2009 [Page 4]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
algorithms.
3.4. encapContentInfo
encapContentInfo is the signed content, consisting of a content type
identifier and the content itself.
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
3.4.1. eContentType
The ContentType for an IOA is defined as IdentifierOriginAttestation
and has the numerical value of TBA.
3.4.2. eContent
The content of an IOA identifies a sequence of locators that has been
authorized by the identifiers address space holder to populate the
mapping database. One or more locators can be authorized in one IOA.
IPv4 and/or IPv6 locators can be included in an IOA together with
IPv4 and/or IPv6 identifiers.an IOA is formally defined as:
Gagliano Expires September 22, 2009 [Page 5]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
LocatorOriginAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
locAddrBlocks SEQUENCE OF LocatorIPAddressFamily,
idAddrBlocks SEQUENCE OF IdIPAddressFamily }
LocatorIPAddressFamily ::= SEQUENCE {
locaddressFamily OCTET STRING (SIZE (2..3)),
locaddresses SEQUENCE OF LocatorIPAddress }
LocatorIPAddress ::= IPAddressOrRange
IdIPAddressFamily ::= SEQUENCE {
idaddressFamily OCTET STRING (SIZE (2..3)),
idaddresses SEQUENCE OF IdIPAddress }
IdIPAddress ::= SEQUENCE {
idaddress IPAddressOrRange,
idmaxLength INTEGER OPTIONAL }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
3.4.2.1. version
The version number of the IdentifierOriginAttestation MUST be 0
3.4.2.2. locAddrBlocks
The locAddrBlocks field encodes the set of RLOCs IP addresses. The
syntax MUST follow the IP Address Delegation extention in RFC 3779.
Within the LocatorIPAddressFamily structure, locaddressFamily
contains the Address Family Identifier (AFI) of an IP address family
that MUST be either 0001 (ipv4) or 0002 (ipv6). The LocatorIPAddress
represent a sequence of type IPAddressOrRange as defined in RFC 3779.
Single IP addresses, IP address prefixes or IP address ranges can be
representated using this element type.
Gagliano Expires September 22, 2009 [Page 6]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
3.4.2.3. idAddrBlocks
The idAddrBlocks field encodes the set of identifiers IP
addresses.The syntax MUST follow the IP Address Delegation extention
in RFC3779. Single IP address, IP prefixes or address ranges are
possible using this notation.
Within the idIPAddressFamily structure, idaddressFamily contains the
Address Family Identifier (AFI) of an IP address family that MUST be
either 0001 (ipv4) or 0002 (ipv6). The IdIPAddress represent a
sequence of type IPAddressOrRange as defined in RFC 3779. Single IP
addresses, IP address prefixes or IP address ranges can be
representated using this element type. If the IPAddressOrRange is of
type IPAddressRange, the field idmaxLength MUST be omitted. If the
IPAddressOrRange is of type IPAddress, the idmaxLength MAY be
included. When present, the idmaxLength specifies the maximum length
of EID IP address prefix that the RLOC is authorized to advertise in
the mapping function. (For example, if the IP Address prefix is
10.0/16 and the maxLength is 24, the RLOC is authorized to advertise
any more specific prefix having length at most 24.
3.5. certificates
The certificates field MUST be included and MUST contain only the end
entity certificate needed to validate this IOA.
3.6. crls
The crls field MUST be omitted.
3.7. signerInfos
SignerInfo is defined under CMS as:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
3.7.1. version
The version number MUST be 3, corresponding with the choice of
SubjectKeyIdentifier for the sid.
Gagliano Expires September 22, 2009 [Page 7]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
3.7.2. sid
The sid is defined as:
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For an IOA, the sid MUST be a SubjectKeyIdentifier.
3.7.3. digestAlgorithm
The digestAlgorithm MUST be SHA-256, the OID for which is
2.16.840.1.101.3.4.2.1. [RFC4055].
3.7.4. signedAttrs
The signedAttrs is defined as:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
The signedAttr element MUST be present and MUST include the content-
type and message-digest attributes. The signer MAY also include the
signing-time signed attribute, the binary-signing-time signed
attribute, or both signed attributes. Other signed attributes that
are deemed appropriate MAY also be included. The intent is to allow
additional signed attributes to be included if a future need is
identified. This does not cause an interoperability concern because
unrecognized signed attributes are ignored by the relying party.
The signedAttr MUST include only a single instance of any particular
attribute. Additionally, even though the syntax allows for a SET OF
AttributeValue, in an IOA the attrValues must consist of only a
single AttributeValue.
3.7.4.1. ContentType Attribute
The ContentType attribute MUST be present. The attrType OID for the
ContentType attribute is 1.2.840.113549.1.9.3.
The attrValues for the ContentType attribute in an IOA MUST be TBA
(matching the eContentType in the EncapsulatedContentInfo).
Gagliano Expires September 22, 2009 [Page 8]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
3.7.4.2. MessageDigest Attribute
The MessageDigest Attribute MUST be present. The attrType OID for
the MessageDigest Attribute is 1.2.840.113549.1.9.4.
The attrValues for the MessageDigest attribute contains the output of
the digest algorithm applied to the content being signed, as
specified in Section 5.4 of [RFC3852].
3.7.4.3. SigningTime Attribute
The SigningTime Attribute MAY be present. If it is present it MUST
be ignored by the relying party. The presence of absence of the
SigningTime attribute in no way affects the validation of the IOA (as
specified in Section 4). The attrType OID for the SigningTime
attribute is 1.2.840.113549.1.9.5.
The attrValues for the SigningTime attribute is defined as:
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The Time element specifies the time, based on the local system clock,
at which the digital signature was applied to the content.
3.7.4.4. BinarySigningTimeAttribute
The BinarySigningTime Attribute MAY be present. If it is present it
MUST be ignored by the relying party. The presence of absence of the
BinarySigningTime attribute in no way affects the validation of the
IOA (as specified in Section 4). The attrType OID for the
BinarySigningTime attribute is 1.2.840.113549.1.9.16.2.46 [RFC4049]
The BinarySigningTime Attribute MAY be present. If it is present it
MUST be ignored by the relying party. The presence of absence of the
SigningTime attribute in no way affects the validation of the IOA (as
specified in Section 3). The attrType OID for the SigningTime
attribute is 1.2.840.113549.1.9.5.
The attrValues for the BinarySigningTime attribute is defined as:
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
The BinaryTime element specifies the time, based on the local system
Gagliano Expires September 22, 2009 [Page 9]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
clock, at which the digital signature was applied to the content.
3.7.4.5. signatureAlgorithm
The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which
is 1.2.840.113549.1.1.1.
3.7.4.6. signature
The signature value is defined as:
SignatureValue ::= OCTET STRING
3.7.4.7. unsignedAttrs
unsignedAttrs MUST be omitted.
4. IOA Validation
Before a relying party can use an IOA to validate a entry in the
mapping function, the relying party must first validate the IOA by
verifying that all of the following conditions hold.
1. The IOA syntax complies with this specification. In particular,
that each of the following is true:
A. The contentType of the CMS object is SignedData (OID
1.2.840.113549.1.7.2).
B. The version of the SignedData object is 3.
C. The digestAlgorithm in the SignedData object is SHA-256 (OID
2.16.840.1.101.3.4.2.1).
D. The certificates field in the SignedData object is present
and contains an EE certificate whose Subject Key Identifier
(SKI) matches the sid field of the SignerInfo object.
E. The crls field in the SignedData object is omitted.
F. The eContentType in the EncapsulatedContentInfo is
IdentifierOriginAttestation (OID TBA)
G. The version of the IdentifierOriginAttestation is 0.
H. The idaddressFamily in the IdIPAddressFamily is either IPv4
or IPv6 (0001 and 0002, respectively).
Gagliano Expires September 22, 2009 [Page 10]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
I. The locaddressFamily in the LocatorIPAddressFamily is either
IPv4 or IPv6 (0001 and 0002, respectively).
J. The version of the SignerInfo is 3.
K. The digestAlgorithm in the SignerInfo object is SHA-256 (OID
2.16.840.1.101.3.4.2.1).
L. The signatureAlgorithm in the SignerInfo object is RSA (OID
1.2.840.113549.1.1.1).
M. The signedAttrs field in the SignerInfo object is present and
contains both the ContentType attribute (TBA) and the
MessageDigest attribute (OID 1.2.840.113549.1.9.4).
N. The unsignedAttrs field in the SignerInfo object is omitted.
2. The public key of the EE certificate (contained within the IOA)
can be used to verify the signature on the IOA.
3. The IP Address Delegation extension [RFC3779] is present in the
EE certificate (contained within the IOA) and each IP address
prefix(es) in the IdIPAddress of the IOA is contained within the
set of IP addresses specified by the EE certificate's IP address
delegation extension.
4. The EE certificate (contained within the IOA) is a valid end-
entity certificate in the resource PKI as specified by . (In
particular, there exists a valid certification path from a
[I-D.ietf-sidr-res-certs] trust anchor to the EE certificate.)
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
TBD.
7. Acknowledgements
Gagliano Expires September 22, 2009 [Page 11]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
8. Normative References
[I-D.farinacci-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12 (work in progress), March 2009.
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-06 (work in
progress), March 2009.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-16 (work in progress),
February 2009.
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-04 (work in progress),
November 2008.
[I-D.jen-apt]
Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service",
draft-jen-apt-01 (work in progress), November 2007.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
BCP 12, RFC 2050, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC4049] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 4049,
April 2005.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
Gagliano Expires September 22, 2009 [Page 12]
Internet-Draft Endpoint Identifier Origin Authorizations March 2009
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
Author's Address
Roque Gagliano
LACNIC
Rambla Rep Mexico 6125
Montevideo, 11400
UY
Phone: +598 2 4005633
Email: roque@lacnic.net
Gagliano Expires September 22, 2009 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 09:43:28 |