idnits 2.17.1 draft-ietf-sidr-roa-format-06.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.i 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5280' is mentioned on line 109, but not defined -- Looks like a reference, but probably isn't: '0' on line 302 -- Looks like a reference, but probably isn't: '1' on line 289 == Unused Reference: 'CP' is defined on line 529, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rpki-algs-00 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 == Outdated reference: A later version (-17) exists of draft-ietf-sidr-cp-07 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 -- Obsolete informational reference (is this intentional?): RFC 4049 (Obsoleted by RFC 6019) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing (sidr) M. Lepinski 2 Internet Draft S. Kent 3 Expires: April 26, 2010 D. Kong 4 Intended Status: Proposed Standard BBN Technologies 5 October 26, 2009 7 A Profile for Route Origin Authorizations (ROAs) 8 draft-ietf-sidr-roa-format-06.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 April 26, 2010. 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 Route Origin 47 Authorizations (ROAs). A ROA is a digitally signed object that 48 provides a means of verifying that an IP address block holder has 49 authorized an Autonomous System (AS) to originate routes to that one 50 or more prefixes within the address block. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Basic Format...................................................3 56 2.1. Signed-Data Content Type..................................4 57 2.1.1. version..............................................4 58 2.1.2. digestAlgorithms.....................................4 59 2.1.3. encapContentInfo.....................................4 60 2.1.3.1. eContentType....................................4 61 2.1.3.2. eContent........................................5 62 2.1.3.2.1. version....................................5 63 2.1.3.2.2. asID.......................................5 64 2.1.3.2.3. ipAddrBlocks...............................5 65 2.1.4. certificates.........................................6 66 2.1.5. crls.................................................6 67 2.1.6. signerInfos..........................................7 68 2.1.6.1. version.........................................7 69 2.1.6.2. sid.............................................7 70 2.1.6.3. digestAlgorithm.................................7 71 2.1.6.4. signedAttrs.....................................7 72 2.1.6.4.1. ContentType Attribute......................8 73 2.1.6.4.2. MessageDigest Attribute....................8 74 2.1.6.4.3. SigningTime Attribute......................8 75 2.1.6.4.4. BinarySigningTimeAttribute.................9 76 2.1.6.5. signatureAlgorithm..............................9 77 2.1.6.6. signature......................................10 78 2.1.6.7. unsignedAttrs..................................10 79 3. ROA Validation................................................10 80 4. Security Considerations.......................................11 81 5. IANA Considerations...........................................12 82 6. Acknowledgments...............................................12 83 7. References....................................................13 84 7.1. Normative References.....................................13 85 7.2. Informative References...................................13 86 Authors' Addresses...............................................14 87 Intellectual Property Statement..................................14 88 Disclaimer of Validity...........................................14 89 Copyright Statement..............................................14 91 1. Introduction 93 The primary purpose of the Internet IP Address and AS Number Resource 94 Public Key Infrastructure (RPKI) system is to improve routing 95 security. As part of this system, a mechanism is needed to allow 96 entities to verify that an AS has been given permission by an IP 97 address block holder to advertise routes to one or more prefixes 98 within that block. A ROA provides this function. 100 A ROA is a digitally signed object that makes use of Cryptographic 101 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 102 CMS was chosen to take advantage of existing open source software 103 available for processing messages in this format. 105 1.1. Terminology 107 It is assumed that the reader is familiar with the terms and concepts 108 described in "Internet X.509 Public Key Infrastructure Certificate 109 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 110 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC-2119 [RFC2119]. 116 1.2. Note on Algorithms 118 Cryptographic Message Syntax is a general format capable of 119 accommodating a wide variety of signature and digest algorithms. This 120 specification takes no stand with regards to the signature and digest 121 algorithms that are appropriate for use in a ROA. Appropriate 122 algorithms and associated key sizes are specified in a separate 123 document [ALGS]. 125 2. Basic Format 127 Using CMS syntax, a ROA is a type of signed-data object. The general 128 format of a CMS object is: 130 ContentInfo ::= SEQUENCE { 131 contentType ContentType, 132 content [0] EXPLICIT ANY DEFINED BY contentType } 134 ContentType ::= OBJECT IDENTIFIER 136 As a ROA is a signed-data object, it uses the corresponding OID, 137 1.2.840.113549.1.7.2. [RFC3852] 139 2.1. Signed-Data Content Type 141 According to the CMS standard, the signed-data content type shall 142 have ASN.1 type SignedData: 144 SignedData ::= SEQUENCE { 145 version CMSVersion, 146 digestAlgorithms DigestAlgorithmIdentifiers, 147 encapContentInfo EncapsulatedContentInfo, 148 certificates [0] IMPLICIT CertificateSet OPTIONAL, 149 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 150 signerInfos SignerInfos } 152 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 154 SignerInfos ::= SET OF SignerInfo 156 Additionally, the SignerInfos set must contain only a single 157 SignerInfo object. 159 2.1.1. version 161 The version is the syntax version number. It MUST be 3, 162 corresponding to the signerInfo structure having version number 3. 164 2.1.2. digestAlgorithms 166 The digestAlgorithms set contains the OIDs of the digest algorithm(s) 167 used in signing the encapsulated content. This set MUST conform to 168 the RPKI Algorithms and Key Size Profile specification [ALGS]. 170 2.1.3. encapContentInfo 172 encapContentInfo is the signed content, consisting of a content type 173 identifier and the content itself. 175 EncapsulatedContentInfo ::= SEQUENCE { 176 eContentType ContentType, 177 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 179 ContentType ::= OBJECT IDENTIFIER 181 2.1.3.1. eContentType 183 The ContentType for a ROA is defined as routeOriginAttestation and 184 has the numerical value of 1.2.840.113549.1.9.16.1.24. 186 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 187 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 189 id-ct OBJECT INDENTIFIER ::= { id-smime 1 } 191 routeOriginAttestion OBJECT IDENTIFIER ::= { id-ct 24 } 193 2.1.3.2. eContent 195 The content of a ROA identifies a single AS that has been authorized 196 by the address space holder to originate routes and a list of one or 197 more IP address prefixes that will be advertised. If the address 198 space holder needs to authorize multiple ASes to advertise the same 199 set of address prefixes, the holder issues multiple ROAs, one per AS 200 number. A ROA is formally defined as: 202 RouteOriginAttestation ::= SEQUENCE { 203 version [0] INTEGER DEFAULT 0, 204 asID ASID, 205 ipAddrBlocks SEQUENCE OF ROAIPAddressFamily } 207 ASID ::= INTEGER 209 ROAIPAddressFamily ::= SEQUENCE { 210 addressFamily OCTET STRING (SIZE (2..3)), 211 addresses SEQUENCE OF ROAIPAddress } 213 ROAIPAddress ::= SEQUENCE { 214 address IPAddress, 215 maxLength INTEGER OPTIONAL } 217 IPAddress ::= BIT STRING 219 2.1.3.2.1. version 221 The version number of the RouteOriginAttestation MUST be 0. 223 2.1.3.2.2. asID 225 The asID field contains the AS number that is authorized to originate 226 routes to the given IP address prefixes. 228 2.1.3.2.3. ipAddrBlocks 230 The ipAddrBlocks field encodes the set of IP address prefixes to 231 which the AS is authorized to originate routes. Note that the syntax 232 here is more restrictive than that used in the IP Address Delegation 233 extension defined in RFC 3779. That extension can represent arbitrary 234 address ranges, whereas ROAs need to represent only prefixes. 236 Within the ROAIPAddressFamily structure, addressFamily contains the 237 Address Family Identifier (AFI) of an IP address family. This 238 specification only supports IPv4 and IPv6. Therefore, addressFamily 239 MUST be either 0001 or 0002. 241 Within a ROAIPAddress structure, the addresses field represents 242 prefixes as a sequence of type IPAddress. (See [RFC3779] for more 243 details). If present, the maxLength must be an integer greater than 244 or equal to the length of the accompanying prefix and less than or 245 equal to the length (in bits) of an IP address in the address family 246 (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies 247 the maximum length of IP address prefix that the AS is authorized to 248 advertise. (For example, if the IP Address prefix is 10.0/16 and the 249 maxLength is 24, the AS is authorized to advertise any more specific 250 prefix having length at most 24. That is, in this example, the AS 251 would be authorized to advertise 10.0/16, 10.0.128/20, or 252 10.0.255/24, but not 10.0.255.0/25.) When the maxLength is not 253 present, the AS is only authorized to advertise exactly the prefix 254 specified in the ROA. 256 Note that a valid ROA may contain an IP Address prefix (within a 257 ROAIPAddress element) that is encompassed by another IP Address 258 prefix (within a separate ROAIPAddress element). For example, a ROA 259 may contain the prefix 10.0/16 with maxLength 18, as well as the 260 prefix 10.0.0/24 with maxLength 24. (Such a ROA would authorize the 261 indicated AS to advertise any prefix beginning with 10.0 with length 262 at least 16 and no greater than 18, as well as the specific prefix 263 10.0.0/24.) Additionally, a ROA MAY contain two ROAIPAddress elements 264 where the IP Address prefix is identical in both cases. However, this 265 is NOT RECOMMENDED as in such a case the ROAIPAddress with the 266 shorter maxLength grants no additional privileges to the indicated AS 267 and thus can be omitted without changing the meaning of the ROA. 269 2.1.4. certificates 271 The certificates field MUST be included and MUST contain only the end 272 entity certificate needed to validate this ROA. 274 2.1.5. crls 276 The crls field MUST be omitted. 278 2.1.6. signerInfos 280 SignerInfo is defined under CMS as: 282 SignerInfo ::= SEQUENCE { 283 version CMSVersion, 284 sid SignerIdentifier, 285 digestAlgorithm DigestAlgorithmIdentifier, 286 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 287 signatureAlgorithm SignatureAlgorithmIdentifier, 288 signature SignatureValue, 289 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 291 2.1.6.1. version 293 The version number MUST be 3, corresponding with the choice of 294 SubjectKeyIdentifier for the sid. 296 2.1.6.2. sid 298 The sid is defined as: 300 SignerIdentifier ::= CHOICE { 301 issuerAndSerialNumber IssuerAndSerialNumber, 302 subjectKeyIdentifier [0] SubjectKeyIdentifier } 304 For a ROA, the sid MUST be a SubjectKeyIdentifier. 306 2.1.6.3. digestAlgorithm 308 The digestAlgorithm MUST consist of the OID of a digest algorithm 309 that conforms to the RPKI Algorithms and Key Size Profile 310 specification [ALGS]. 312 2.1.6.4. signedAttrs 314 The signedAttrs is defined as: 316 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 318 Attribute ::= SEQUENCE { 319 attrType OBJECT IDENTIFIER, 320 attrValues SET OF AttributeValue } 322 AttributeValue ::= ANY 324 The signedAttr element MUST be present and MUST include the content- 325 type and message-digest attributes. The signer MAY also include the 326 signing-time signed attribute, the binary-signing-time signed 327 attribute, or both signed attributes. Other signed attributes that 328 are deemed appropriate MAY also be included. The intent is to allow 329 additional signed attributes to be included if a future need is 330 identified. This does not cause an interoperability concern because 331 unrecognized signed attributes are ignored by the relying party. 333 The signedAttr MUST include only a single instance of any particular 334 attribute. Additionally, even though the syntax allows for a SET OF 335 AttributeValue, in a ROA the attrValues must consist of only a single 336 AttributeValue. 338 2.1.6.4.1. ContentType Attribute 340 The ContentType attribute MUST be present. The attrType OID for the 341 ContentType attribute is 1.2.840.113549.1.9.3. 343 The attrValues for the ContentType attribute in a ROA MUST be 344 1.2.840.113549.1.9.16.1.24 (matching the eContentType in the 345 EncapsulatedContentInfo). 347 2.1.6.4.2. MessageDigest Attribute 349 The MessageDigest Attribute MUST be present. The attrType OID for the 350 MessageDigest Attribute is 1.2.840.113549.1.9.4. 352 The attrValues for the MessageDigest attribute contains the output of 353 the digest algorithm applied to the content being signed, as 354 specified in Section 11.1 of RFC 3852. 356 2.1.6.4.3. SigningTime Attribute 358 The SigningTime Attribute MAY be present. If it is present it MUST be 359 ignored by the relying party. The presence of absence of the 360 SigningTime attribute in no way affects the validation of the ROA (as 361 specified in Section 3). The attrType OID for the SigningTime 362 attribute is 1.2.840.113549.1.9.5. 364 The attrValues for the SigningTime attribute is defined as: 366 SigningTime ::= Time 368 Time ::= CHOICE { 369 utcTime UTCTime, 370 generalizedTime GeneralizedTime } 372 The Time element specifies the time, based on the local system clock, 373 at which the digital signature was applied to the content. 375 The definition of Time matches the one specified in the 1997 version 376 of X.509. Additional information regarding the use of UTCTime and 377 GeneralizedTime can we found in [RFC3852]. 379 2.1.6.4.4. BinarySigningTimeAttribute 381 The BinarySigningTime Attribute MAY be present. If it is present it 382 MUST be ignored by the relying party. The presence of absence of the 383 BinarySigningTime attribute in no way affects the validation of the 384 ROA (as specified in Section 3). The attrType OID for the SigningTime 385 attribute is 1.2.840.113549.1.9.16.2.46. 387 The attrValues for the SigningTime attribute is defined as: 389 BinarySigningTime ::= BinaryTime 391 BinaryTime ::= INTEGER (0..MAX) 393 The BinaryTime element specifies the time, based on the local system 394 clock, at which the digital signature was applied to the content. The 395 precise definition of the BinaryTime element can be found in 396 [RFC4049]. 398 2.1.6.5. signatureAlgorithm 400 The signatureAlgorithm MUST consist of the OID of a signature 401 algorithm that conforms RPKI Algorithms and Key Size Profile 402 specification [ALGS]. 404 2.1.6.6. signature 406 The signature value is defined as: 408 SignatureValue ::= OCTET STRING 410 The signature characteristics are defined by the digest and signature 411 algorithms. 413 2.1.6.7. unsignedAttrs 415 unsignedAttrs MUST be omitted. 417 3. ROA Validation 419 Before a relying party can use a ROA to validate a routing 420 announcement, the relying party must first validate the ROA by 421 verifying that all of the following conditions hold. (Note that a 422 relying party may perform these checks in any order.) 424 1. The ROA syntax complies with this specification. In particular, 425 that each of the following is true: 427 a. The contentType of the CMS object is SignedData (OID 428 1.2.840.113549.1.7.2) 430 b. The version of the SignedData object is 3. 432 c. The certificates field in the SignedData object is present and 433 contains an EE certificate whose Subject Key Identifier (SKI) 434 matches the sid field of the SignerInfo object. 436 d. The crls field in the SignedData object is omitted. 438 e. The eContentType in the EncapsulatedContentInfo is 439 routeOriginAttestation (OID 1.2.840.113549.1.9.16.1.24) 441 f. The version of the RouteOriginAttestation is 0. 443 g. The addressFamily in the ROAIPAddressFamily is either IPv4 or 444 IPv6 (0001 and 0002, respectively). 446 h. The version of the SignerInfo is 3. 448 i. The signedAttrs field in the SignerInfo object is present and 449 contains both the ContentType attribute (OID 450 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 451 1.2.840.113549.1.9.4). 453 j. The unsignedAttrs field in the SignerInfo object is omitted. 455 k. The digestAlgorithm in the SignedData and SignerInfo objects 456 as well as the signatureAlgorithm in the SignerInfo object 457 conform to the RPKI Algorithms and Key Size Profile 458 specification [ALGS]. 460 2. The public key of the end-entity certificate (contained within the 461 ROA) can be used to successfully verify the signature on the ROA. 463 3. The IP Address Delegation extension [RFC3779] is present in the EE 464 certificate (contained within the ROA) and each IP address 465 prefix(es) in ROA is contained within the set of IP addresses 466 specified by the EE certificate's IP address delegation extension. 468 4. The EE certificate (contained within the ROA) is a valid end- 469 entity certificate in the resource PKI as specified by [RESCERT]. 470 (In particular, there exists a valid certification path from a 471 trust anchor to the EE certificate.) 473 4. Security Considerations 475 There is no assumption of confidentiality for the data in a ROA; it 476 is anticipated that ROAs will be stored in repositories that are 477 accessible to all ISPs, and perhaps to all Internet users. There is 478 no explicit authentication associated with a ROA, since the PKI used 479 for ROA validation provides authorization but not authentication. 480 Although the ROA is a signed, application layer object, there is no 481 intent to convey non-repudiation via a ROA. 483 The purpose of a ROA is to convey authorization for an AS to 484 originate a route to the prefix(es) in the ROA. Thus the integrity of 485 a ROA must be established. The ROA makes use of the CMS signed 486 message format for integrity, and thus inherits the security 487 considerations associated with that data structure. The right of the 488 ROA signer to authorize the target AS to originate routes to the 489 prefix(es) is established through use of the address space and AS 490 number PKI described in [ARCH]. Specifically one must verify the 491 signature on the ROA using an X.509 certificate issued under this 492 PKI, and check that the prefix(es) in the ROA match those in the 493 address space extension in the certificate. 495 5. IANA Considerations 497 None. 499 6. Acknowledgments 501 The authors wish to thank Charles Gardiner and Russ Housley for their 502 help and contributions. Additionally, the authors would like to thank 503 Danny McPherson and Roque Gagliano for their careful reviews and 504 helpful comments. 506 7. References 508 7.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC3852] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 514 2004. 516 [RFC3779] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for IP 517 Addresses and AS Identifiers", RFC 3779, June 2004. 519 [ALGS] Huston, G., "A Profile for Algorithms and Key Sizes for use 520 in the Resource Public Key Infrastructure", draft-ietf- 521 sidr-rpki-algs-00, August 2009 523 7.2. Informative References 525 [ARCH] Lepinski, M. and Kent, S., "An Infrastructure to Support 526 Secure Internet Routing," draft-ietf-sidr-arch-09, October 527 2009. 529 [CP] Seo, K., et. al., "A Certificate Policy for the Resource 530 PKI," draft-ietf-sidr-cp-07, October 2009. 532 [RESCERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 533 X.509 PKIX Resource Certificates," draft-ietf-sidr-res- 534 certs-17, August 2009. 536 [RFC4049] Housley, R., "BinaryTime: An Alternative Format for 537 Representing Time in ASN.1," RFC 4049, April 2005. 539 Authors' Addresses 541 Matt Lepinski 542 BBN Technologies 543 10 Moulton Street 544 Cambridge MA 02138 546 Email: mlepinski@bbn.com 548 Stephen Kent 549 BBN Technologies 550 10 Moulton Street 551 Cambridge MA 02138 553 Email: skent@bbn.com 555 Derrick Kong 556 BBN Technologies 557 10 Moulton Street 558 Cambridge MA 02138 560 Email: dkong@bbn.com 562 Pre-5378 Material Disclaimer 564 This document may contain material from IETF Documents or IETF 565 Contributions published or made publicly available before November 566 10, 2008. The person(s) controlling the copyright in some of this 567 material may not have granted the IETF Trust the right to allow 568 modifications of such material outside the IETF Standards Process. 569 Without obtaining an adequate license from the person(s) controlling 570 the copyright in such materials, this document may not be modified 571 outside the IETF Standards Process, and derivative works of it may 572 not be created outside the IETF Standards Process, except to format 573 it for publication as an RFC or to translate it into languages other 574 than English.