idnits 2.17.1 draft-rgaglian-lisp-iao-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 25, 2009) is 5503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 295 -- Looks like a reference, but probably isn't: '1' on line 282 == Unused Reference: 'I-D.farinacci-lisp' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 507, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-06 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-04 ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Gagliano 3 Internet-Draft LACNIC 4 Intended status: Informational March 25, 2009 5 Expires: September 22, 2009 7 A Profile for Endpoint Identifier Origin Authorizations (IOA) 8 draft-rgaglian-lisp-iao-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 22, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines a standard profile for End-Point Identifiers 47 Origin Authorizations (IOAs). An IOA is a digitally signed object 48 that provides a means of verifying that the EID IP address block 49 holder has authorized a set of Router Locators (RLOCs) as its de- 50 encapsulation point in a Map & Encap mapping service. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Securing the Mapping functions and its relationship to RPKI . 3 56 3. IOA Especification . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 58 3.2. version . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. digestAlgorithms . . . . . . . . . . . . . . . . . . . . . 4 60 3.4. encapContentInfo . . . . . . . . . . . . . . . . . . . . . 5 61 3.4.1. eContentType . . . . . . . . . . . . . . . . . . . . . 5 62 3.4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.5. certificates . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. crls . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.7. signerInfos . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.7.1. version . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.7.2. sid . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.7.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . 8 69 3.7.4. signedAttrs . . . . . . . . . . . . . . . . . . . . . 8 70 4. IOA Validation . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Map & Encap solutions such as LISP [I-D.ietf-sidr-res-certs] or APT 80 [I-D.jen-apt] require the existence of a mapping service that given a 81 destination EID returns the correspondant globally reachable RLOC. 82 The primary purpose of the Internet IP Address and AS Number Resource 83 Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch] system is to 84 improve routing security. In a Map and Encap environment that needs 85 to include the mapping service, where the authorization for a set of 86 RLOC as a de-encap point for a particular EID needs to be verifiable. 87 The IOA provides this function. 89 An IOA is a digitally signed object that makes use of Cryptographic 90 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 91 CMS was chosen to take advantage of existing open source software 92 available for processing messages in this format. 94 This spec is based on the ROA especification at 95 [I-D.ietf-sidr-roa-format]. 97 2. Securing the Mapping functions and its relationship to RPKI 99 IP addresses are allocated following [RFC2050] in a hierarchy that 100 considers allocations from IANA to Regional Internet Registries 101 (RIRs) and from RIRs to other registries (such as LIR, NIR or ISPs). 102 Following the RPKI Architecture, each resource holder will be 103 provided with a certificate with RFC3779 [RFC3779] extension that 104 ennumerates the IP address prefixes and Autonomous System numbers 105 (ASNs) that the particular resource holder has the right to use. 106 RPKI has been propossed to improve security in the inter-domain 107 routing system, particularly to validade the authorization of a 108 particular ASN to originate a BGPv4 address prefix announcement. The 109 relationship between the address prefix and the ASN that is 110 authorized to originate the BGP announcement is done by the existance 111 of a ROA. Signed material such as ROAs are hosted in a publicly 112 available repository. 114 Using the same ideas for verifying the authorization of a particular 115 ASN to originate a prefix, it is possible that the EID IP address 116 block holder signs the authorization of a particular set of RLOC to 117 populate the mapping database in a Map & Encap solution. This signed 118 objects may be used by: 120 a. the mapping service to verify every entry before accepting them 121 in its mapping database. 123 b. the mapping clients to verify the mapping service reponses. 125 IOA are not intended to be used neither to sign nor encrypt mapping 126 messages. The securization of the communication channel between the 127 mapping service and its clients will depend on the architecture to be 128 implemented. 130 3. IOA Especification 132 Using CMS syntax an IOA is a signed-data object. The general format 133 of a CMS object is: 135 ContentInfo ::= SEQUENCE { 136 contentType ContentType, 137 content [0] EXPLICIT ANY DEFINED BY contentType } 139 ContentType ::= OBJECT IDENTIFIER 141 As an IOA is a signed-data object. it uses the corresponding OID 142 1.2.840.113549.1.7.2. [RFC3852]. 144 3.1. Signed-Data Content Type 146 According to the CMS standard, the signed-data content type shall 147 have ASN.1 type SignedData: 149 SignedData ::= SEQUENCE { 150 version CMSVersion, 151 digestAlgorithms DigestAlgorithmIdentifiers, 152 encapContentInfo EncapsulatedContentInfo, 153 certificates [0] IMPLICIT CertificateSet OPTIONAL, 154 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 155 signerInfos SignerInfos } 157 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 159 SignerInfos ::= SET OF SignerInfo 161 3.2. version 163 The version is the syntax version number. It MUST be 3, 164 corresponding to the signerInfo structure having version number 3. 166 3.3. digestAlgorithms 168 The digestAlgorithms set MUST include only SHA-256, the OID for which 169 is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other 170 algorithms. 172 3.4. encapContentInfo 174 encapContentInfo is the signed content, consisting of a content type 175 identifier and the content itself. 177 EncapsulatedContentInfo ::= SEQUENCE { 178 eContentType ContentType, 179 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 181 ContentType ::= OBJECT IDENTIFIER 183 3.4.1. eContentType 185 The ContentType for an IOA is defined as IdentifierOriginAttestation 186 and has the numerical value of TBA. 188 3.4.2. eContent 190 The content of an IOA identifies a sequence of locators that has been 191 authorized by the identifiers address space holder to populate the 192 mapping database. One or more locators can be authorized in one IOA. 193 IPv4 and/or IPv6 locators can be included in an IOA together with 194 IPv4 and/or IPv6 identifiers.an IOA is formally defined as: 196 LocatorOriginAttestation ::= SEQUENCE { 197 version [0] INTEGER DEFAULT 0, 198 locAddrBlocks SEQUENCE OF LocatorIPAddressFamily, 199 idAddrBlocks SEQUENCE OF IdIPAddressFamily } 201 LocatorIPAddressFamily ::= SEQUENCE { 202 locaddressFamily OCTET STRING (SIZE (2..3)), 203 locaddresses SEQUENCE OF LocatorIPAddress } 205 LocatorIPAddress ::= IPAddressOrRange 207 IdIPAddressFamily ::= SEQUENCE { 208 idaddressFamily OCTET STRING (SIZE (2..3)), 209 idaddresses SEQUENCE OF IdIPAddress } 211 IdIPAddress ::= SEQUENCE { 212 idaddress IPAddressOrRange, 213 idmaxLength INTEGER OPTIONAL } 215 IPAddressOrRange ::= CHOICE { 216 addressPrefix IPAddress, 217 addressRange IPAddressRange } 219 IPAddressRange ::= SEQUENCE { 220 min IPAddress, 221 max IPAddress } 223 IPAddress ::= BIT STRING 225 3.4.2.1. version 227 The version number of the IdentifierOriginAttestation MUST be 0 229 3.4.2.2. locAddrBlocks 231 The locAddrBlocks field encodes the set of RLOCs IP addresses. The 232 syntax MUST follow the IP Address Delegation extention in RFC 3779. 234 Within the LocatorIPAddressFamily structure, locaddressFamily 235 contains the Address Family Identifier (AFI) of an IP address family 236 that MUST be either 0001 (ipv4) or 0002 (ipv6). The LocatorIPAddress 237 represent a sequence of type IPAddressOrRange as defined in RFC 3779. 238 Single IP addresses, IP address prefixes or IP address ranges can be 239 representated using this element type. 241 3.4.2.3. idAddrBlocks 243 The idAddrBlocks field encodes the set of identifiers IP 244 addresses.The syntax MUST follow the IP Address Delegation extention 245 in RFC3779. Single IP address, IP prefixes or address ranges are 246 possible using this notation. 248 Within the idIPAddressFamily structure, idaddressFamily contains the 249 Address Family Identifier (AFI) of an IP address family that MUST be 250 either 0001 (ipv4) or 0002 (ipv6). The IdIPAddress represent a 251 sequence of type IPAddressOrRange as defined in RFC 3779. Single IP 252 addresses, IP address prefixes or IP address ranges can be 253 representated using this element type. If the IPAddressOrRange is of 254 type IPAddressRange, the field idmaxLength MUST be omitted. If the 255 IPAddressOrRange is of type IPAddress, the idmaxLength MAY be 256 included. When present, the idmaxLength specifies the maximum length 257 of EID IP address prefix that the RLOC is authorized to advertise in 258 the mapping function. (For example, if the IP Address prefix is 259 10.0/16 and the maxLength is 24, the RLOC is authorized to advertise 260 any more specific prefix having length at most 24. 262 3.5. certificates 264 The certificates field MUST be included and MUST contain only the end 265 entity certificate needed to validate this IOA. 267 3.6. crls 269 The crls field MUST be omitted. 271 3.7. signerInfos 273 SignerInfo is defined under CMS as: 275 SignerInfo ::= SEQUENCE { 276 version CMSVersion, 277 sid SignerIdentifier, 278 digestAlgorithm DigestAlgorithmIdentifier, 279 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 280 signatureAlgorithm SignatureAlgorithmIdentifier, 281 signature SignatureValue, 282 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 284 3.7.1. version 286 The version number MUST be 3, corresponding with the choice of 287 SubjectKeyIdentifier for the sid. 289 3.7.2. sid 291 The sid is defined as: 293 SignerIdentifier ::= CHOICE { 294 issuerAndSerialNumber IssuerAndSerialNumber, 295 subjectKeyIdentifier [0] SubjectKeyIdentifier } 297 For an IOA, the sid MUST be a SubjectKeyIdentifier. 299 3.7.3. digestAlgorithm 301 The digestAlgorithm MUST be SHA-256, the OID for which is 302 2.16.840.1.101.3.4.2.1. [RFC4055]. 304 3.7.4. signedAttrs 306 The signedAttrs is defined as: 308 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 310 Attribute ::= SEQUENCE { 311 attrType OBJECT IDENTIFIER, 312 attrValues SET OF AttributeValue } 314 AttributeValue ::= ANY 316 The signedAttr element MUST be present and MUST include the content- 317 type and message-digest attributes. The signer MAY also include the 318 signing-time signed attribute, the binary-signing-time signed 319 attribute, or both signed attributes. Other signed attributes that 320 are deemed appropriate MAY also be included. The intent is to allow 321 additional signed attributes to be included if a future need is 322 identified. This does not cause an interoperability concern because 323 unrecognized signed attributes are ignored by the relying party. 325 The signedAttr MUST include only a single instance of any particular 326 attribute. Additionally, even though the syntax allows for a SET OF 327 AttributeValue, in an IOA the attrValues must consist of only a 328 single AttributeValue. 330 3.7.4.1. ContentType Attribute 332 The ContentType attribute MUST be present. The attrType OID for the 333 ContentType attribute is 1.2.840.113549.1.9.3. 335 The attrValues for the ContentType attribute in an IOA MUST be TBA 336 (matching the eContentType in the EncapsulatedContentInfo). 338 3.7.4.2. MessageDigest Attribute 340 The MessageDigest Attribute MUST be present. The attrType OID for 341 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 343 The attrValues for the MessageDigest attribute contains the output of 344 the digest algorithm applied to the content being signed, as 345 specified in Section 5.4 of [RFC3852]. 347 3.7.4.3. SigningTime Attribute 349 The SigningTime Attribute MAY be present. If it is present it MUST 350 be ignored by the relying party. The presence of absence of the 351 SigningTime attribute in no way affects the validation of the IOA (as 352 specified in Section 4). The attrType OID for the SigningTime 353 attribute is 1.2.840.113549.1.9.5. 355 The attrValues for the SigningTime attribute is defined as: 357 SigningTime ::= Time 359 Time ::= CHOICE { 360 utcTime UTCTime, 361 generalizedTime GeneralizedTime } 363 The Time element specifies the time, based on the local system clock, 364 at which the digital signature was applied to the content. 366 3.7.4.4. BinarySigningTimeAttribute 368 The BinarySigningTime Attribute MAY be present. If it is present it 369 MUST be ignored by the relying party. The presence of absence of the 370 BinarySigningTime attribute in no way affects the validation of the 371 IOA (as specified in Section 4). The attrType OID for the 372 BinarySigningTime attribute is 1.2.840.113549.1.9.16.2.46 [RFC4049] 373 The BinarySigningTime Attribute MAY be present. If it is present it 374 MUST be ignored by the relying party. The presence of absence of the 375 SigningTime attribute in no way affects the validation of the IOA (as 376 specified in Section 3). The attrType OID for the SigningTime 377 attribute is 1.2.840.113549.1.9.5. 379 The attrValues for the BinarySigningTime attribute is defined as: 381 BinarySigningTime ::= BinaryTime 383 BinaryTime ::= INTEGER (0..MAX) 385 The BinaryTime element specifies the time, based on the local system 386 clock, at which the digital signature was applied to the content. 388 3.7.4.5. signatureAlgorithm 390 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 391 is 1.2.840.113549.1.1.1. 393 3.7.4.6. signature 395 The signature value is defined as: 397 SignatureValue ::= OCTET STRING 399 3.7.4.7. unsignedAttrs 401 unsignedAttrs MUST be omitted. 403 4. IOA Validation 405 Before a relying party can use an IOA to validate a entry in the 406 mapping function, the relying party must first validate the IOA by 407 verifying that all of the following conditions hold. 409 1. The IOA syntax complies with this specification. In particular, 410 that each of the following is true: 412 A. The contentType of the CMS object is SignedData (OID 413 1.2.840.113549.1.7.2). 415 B. The version of the SignedData object is 3. 417 C. The digestAlgorithm in the SignedData object is SHA-256 (OID 418 2.16.840.1.101.3.4.2.1). 420 D. The certificates field in the SignedData object is present 421 and contains an EE certificate whose Subject Key Identifier 422 (SKI) matches the sid field of the SignerInfo object. 424 E. The crls field in the SignedData object is omitted. 426 F. The eContentType in the EncapsulatedContentInfo is 427 IdentifierOriginAttestation (OID TBA) 429 G. The version of the IdentifierOriginAttestation is 0. 431 H. The idaddressFamily in the IdIPAddressFamily is either IPv4 432 or IPv6 (0001 and 0002, respectively). 434 I. The locaddressFamily in the LocatorIPAddressFamily is either 435 IPv4 or IPv6 (0001 and 0002, respectively). 437 J. The version of the SignerInfo is 3. 439 K. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 440 2.16.840.1.101.3.4.2.1). 442 L. The signatureAlgorithm in the SignerInfo object is RSA (OID 443 1.2.840.113549.1.1.1). 445 M. The signedAttrs field in the SignerInfo object is present and 446 contains both the ContentType attribute (TBA) and the 447 MessageDigest attribute (OID 1.2.840.113549.1.9.4). 449 N. The unsignedAttrs field in the SignerInfo object is omitted. 451 2. The public key of the EE certificate (contained within the IOA) 452 can be used to verify the signature on the IOA. 454 3. The IP Address Delegation extension [RFC3779] is present in the 455 EE certificate (contained within the IOA) and each IP address 456 prefix(es) in the IdIPAddress of the IOA is contained within the 457 set of IP addresses specified by the EE certificate's IP address 458 delegation extension. 460 4. The EE certificate (contained within the IOA) is a valid end- 461 entity certificate in the resource PKI as specified by . (In 462 particular, there exists a valid certification path from a 463 [I-D.ietf-sidr-res-certs] trust anchor to the EE certificate.) 465 5. IANA Considerations 467 This memo includes no request to IANA. 469 6. Security Considerations 471 TBD. 473 7. Acknowledgements 474 8. Normative References 476 [I-D.farinacci-lisp] 477 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 478 "Locator/ID Separation Protocol (LISP)", 479 draft-farinacci-lisp-12 (work in progress), March 2009. 481 [I-D.ietf-sidr-arch] 482 Lepinski, M. and S. Kent, "An Infrastructure to Support 483 Secure Internet Routing", draft-ietf-sidr-arch-06 (work in 484 progress), March 2009. 486 [I-D.ietf-sidr-res-certs] 487 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 488 X.509 PKIX Resource Certificates", 489 draft-ietf-sidr-res-certs-16 (work in progress), 490 February 2009. 492 [I-D.ietf-sidr-roa-format] 493 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 494 Origin Authorizations (ROAs)", 495 draft-ietf-sidr-roa-format-04 (work in progress), 496 November 2008. 498 [I-D.jen-apt] 499 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 500 L. Zhang, "APT: A Practical Transit Mapping Service", 501 draft-jen-apt-01 (work in progress), November 2007. 503 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 504 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 505 BCP 12, RFC 2050, November 1996. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 511 Addresses and AS Identifiers", RFC 3779, June 2004. 513 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 514 RFC 3852, July 2004. 516 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 517 Representing Date and Time in ASN.1", RFC 4049, 518 April 2005. 520 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 521 Algorithms and Identifiers for RSA Cryptography for use in 522 the Internet X.509 Public Key Infrastructure Certificate 523 and Certificate Revocation List (CRL) Profile", RFC 4055, 524 June 2005. 526 Author's Address 528 Roque Gagliano 529 LACNIC 530 Rambla Rep Mexico 6125 531 Montevideo, 11400 532 UY 534 Phone: +598 2 4005633 535 Email: roque@lacnic.net