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]