idnits 2.17.1 draft-ietf-sidr-roa-format-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5647 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) -- Looks like a reference, but probably isn't: '0' on line 270 -- Looks like a reference, but probably isn't: '1' on line 257 == Unused Reference: 'RSA' is defined on line 493, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-03 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-14 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: May 2009 D. Kong 4 Intended Status: Proposed Standard BBN Technologies 5 November 3, 2008 7 A Profile for Route Origin Authorizations (ROAs) 8 draft-ietf-sidr-roa-format-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 8, 2008. 36 Abstract 38 This document defines a standard profile for Route Origin 39 Authorizations (ROAs). A ROA is a digitally signed object that 40 provides a means of verifying that an IP address block holder has 41 authorized an Autonomous System (AS) to originate routes to that one 42 or more prefixes within the address block. 44 Table of Contents 46 1. Introduction...................................................2 47 2. Basic Format...................................................3 48 2.1. Signed-Data Content Type..................................3 49 2.1.1. version..............................................4 50 2.1.2. digestAlgorithms.....................................4 51 2.1.3. encapContentInfo.....................................4 52 2.1.3.1. eContentType....................................4 53 2.1.3.2. eContent........................................4 54 2.1.3.2.1. version....................................5 55 2.1.3.2.2. asID.......................................5 56 2.1.3.2.3. ipAddrBlocks...............................5 57 2.1.4. certificates.........................................6 58 2.1.5. crls.................................................6 59 2.1.6. signerInfos..........................................6 60 2.1.6.1. version.........................................6 61 2.1.6.2. sid.............................................6 62 2.1.6.3. digestAlgorithm.................................6 63 2.1.6.4. signedAttrs.....................................7 64 2.1.6.4.1. ContentType Attribute......................7 65 2.1.6.4.2. MessageDigest Attribute....................7 66 2.1.6.4.3. SigningTime Attribute......................8 67 2.1.6.4.4. BinarySigningTimeAttribute.................8 68 2.1.6.5. signatureAlgorithm..............................8 69 2.1.6.6. signature.......................................9 70 2.1.6.7. unsignedAttrs...................................9 71 3. ROA Validation.................................................9 72 4. Security Considerations.......................................10 73 5. IANA Considerations...........................................11 74 6. Acknowledgments...............................................11 75 7. References....................................................12 76 7.1. Normative References.....................................12 77 7.2. Informative References...................................12 78 Authors' Addresses...............................................13 79 Intellectual Property Statement..................................14 80 Disclaimer of Validity...........................................14 81 Copyright Statement..............................................14 83 1. Introduction 85 The primary purpose of the Internet IP Address and AS Number Resource 86 Public Key Infrastructure (RPKI) system is to improve routing 87 security. As part of this system, a mechanism is needed to allow 88 entities to verify that an AS has been given permission by an IP 89 address block holder to advertise routes to one or more prefixes 90 within that block. A ROA provides this function. 92 A ROA is a digitally signed object that makes use of Cryptographic 93 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 95 CMS was chosen to take advantage of existing open source software 96 available for processing messages in this format. 98 1.1. Terminology 100 It is assumed that the reader is familiar with the terms and concepts 101 described in "Internet X.509 Public Key Infrastructure Certificate 102 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 103 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC-2119 [RFC2119]. 109 2. Basic Format 111 Using CMS syntax, a ROA is a type of signed-data object. The general 112 format of a CMS object is: 114 ContentInfo ::= SEQUENCE { 115 contentType ContentType, 116 content [0] EXPLICIT ANY DEFINED BY contentType } 118 ContentType ::= OBJECT IDENTIFIER 120 As a ROA is a signed-data object, it uses the corresponding OID, 121 1.2.840.113549.1.7.2. [RFC3852] 123 2.1. Signed-Data Content Type 125 According to the CMS standard, the signed-data content type shall 126 have ASN.1 type SignedData: 128 SignedData ::= SEQUENCE { 129 version CMSVersion, 130 digestAlgorithms DigestAlgorithmIdentifiers, 131 encapContentInfo EncapsulatedContentInfo, 132 certificates [0] IMPLICIT CertificateSet OPTIONAL, 133 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 134 signerInfos SignerInfos } 136 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 138 SignerInfos ::= SET OF SignerInfo 140 2.1.1. version 142 The version is the syntax version number. It MUST be 3, 143 corresponding to the signerInfo structure having version number 3. 145 2.1.2. digestAlgorithms 147 The digestAlgorithms set MUST include only SHA-256, the OID for which 148 is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other 149 algorithms. 151 2.1.3. encapContentInfo 153 encapContentInfo is the signed content, consisting of a content type 154 identifier and the content itself. 156 EncapsulatedContentInfo ::= SEQUENCE { 157 eContentType ContentType, 158 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 160 ContentType ::= OBJECT IDENTIFIER 162 2.1.3.1. eContentType 164 The ContentType for a ROA is defined as routeOriginAttestation and 165 has the numerical value of 1.2.840.113549.1.9.16.1.24. 167 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 168 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 170 id-ct OBJECT INDENTIFIER ::= { id-smime 1 } 172 routeOriginAttestion OBJECT IDENTIFIER ::= { id-ct 24 } 174 2.1.3.2. eContent 176 The content of a ROA identifies a single AS that has been authorized 177 by the address space holder to originate routes and a list of one or 178 more IP address prefixes that will be advertised. If the address 179 space holder needs to authorize multiple ASes to advertise the same 180 set of address prefixes, the holder issues multiple ROAs, one per AS 181 number. A ROA is formally defined as: 183 RouteOriginAttestation ::= SEQUENCE { 184 version [0] INTEGER DEFAULT 0, 185 asID ASID, 186 ipAddrBlocks SEQUENCE OF ROAIPAddressFamily } 188 ASID ::= INTEGER 190 ROAIPAddressFamily ::= SEQUENCE { 191 addressFamily OCTET STRING (SIZE (2..3)), 192 addresses SEQUENCE OF ROAIPAddress } 194 ROAIPAddress ::= SEQUENCE { 195 address IPAddress, 196 maxLength INTEGER OPTIONAL } 198 IPAddress ::= BIT STRING 200 2.1.3.2.1. version 202 The version number of the RouteOriginAttestation MUST be 0. 204 2.1.3.2.2. asID 206 The asID field contains the AS number that is authorized to originate 207 routes to the given IP address prefixes. 209 2.1.3.2.3. ipAddrBlocks 211 The ipAddrBlocks field encodes the set of IP address prefixes to 212 which the AS is authorized to originate routes. Note that the syntax 213 here is more restrictive than that used in the IP Address Delegation 214 extension defined in RFC 3779. That extension can represent arbitrary 215 address ranges, whereas ROAs need to represent only prefixes. 217 Within the ROAIPAddressFamily structure, addressFamily contains the 218 Address Family Identifier (AFI) of an IP address family. This 219 specification only supports IPv4 and IPv6. Therefore, addressFamily 220 MUST be either 0001 or 0002. 222 Within a ROAIPAddress structure, the addresses field represents 223 prefixes as a sequence of type IPAddress. (See [RFC3779] for more 224 details). If present, the maxLength must be an integer greater than 225 or equal to the length of the accompanying prefix and less than or 226 equal to the length (in bits) of an IP address in the address family 227 (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies 228 the maximum length of IP address prefix that the AS is authorized to 229 advertise. (For example, if the IP Address prefix is 10.0/16 and the 230 maxLength is 24, the AS is authorized to advertise any more specific 231 prefix having length at most 24. That is, in this example, the AS 232 would be authorized to advertise 10.0/16, 10.0.128/20, or 233 10.0.255/24, but not 10.0.255.0/25.) When the maxLength is not 234 present, the AS is only authorized to advertise exactly the prefix 235 specified in the ROA. 237 2.1.4. certificates 239 The certificates field MUST be included and MUST contain only the end 240 entity certificate needed to validate this ROA. 242 2.1.5. crls 244 The crls field MUST be omitted. 246 2.1.6. signerInfos 248 SignerInfo is defined under CMS as: 250 SignerInfo ::= SEQUENCE { 251 version CMSVersion, 252 sid SignerIdentifier, 253 digestAlgorithm DigestAlgorithmIdentifier, 254 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 255 signatureAlgorithm SignatureAlgorithmIdentifier, 256 signature SignatureValue, 257 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 259 2.1.6.1. version 261 The version number MUST be 3, corresponding with the choice of 262 SubjectKeyIdentifier for the sid. 264 2.1.6.2. sid 266 The sid is defined as: 268 SignerIdentifier ::= CHOICE { 269 issuerAndSerialNumber IssuerAndSerialNumber, 270 subjectKeyIdentifier [0] SubjectKeyIdentifier } 272 For a ROA, the sid MUST be a SubjectKeyIdentifier. 274 2.1.6.3. digestAlgorithm 276 The digestAlgorithm MUST be SHA-256, the OID for which is 277 2.16.840.1.101.3.4.2.1. [RFC4055] 279 2.1.6.4. signedAttrs 281 The signedAttrs is defined as: 283 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 285 Attribute ::= SEQUENCE { 286 attrType OBJECT IDENTIFIER, 287 attrValues SET OF AttributeValue } 289 AttributeValue ::= ANY 291 The signedAttr element MUST be present and MUST include the content- 292 type and message-digest attributes. The signer MAY also include the 293 signing-time signed attribute, the binary-signing-time signed 294 attribute, or both signed attributes. Other signed attributes that 295 are deemed appropriate MAY also be included. The intent is to allow 296 additional signed attributes to be included if a future need is 297 identified. This does not cause an interoperability concern because 298 unrecognized signed attributes are ignored by the relying party. 300 The signedAttr MUST include only a single instance of any particular 301 attribute. Additionally, even though the syntax allows for a SET OF 302 AttributeValue, in a ROA the attrValues must consist of only a single 303 AttributeValue. 305 2.1.6.4.1. ContentType Attribute 307 The ContentType attribute MUST be present. The attrType OID for the 308 ContentType attribute is 1.2.840.113549.1.9.3. 310 The attrValues for the ContentType attribute in a ROA MUST be 311 1.2.840.113549.1.9.16.1.24 (matching the eContentType in the 312 EncapsulatedContentInfo). 314 2.1.6.4.2. MessageDigest Attribute 316 The MessageDigest Attribute MUST be present. The attrType OID for the 317 MessageDigest Attribute is 1.2.840.113549.1.9.4. 319 The attrValues for the MessageDigest attribute contains the output of 320 the digest algorithm applied to the content being signed, as 321 specified in Section 11.1 of RFC 3852. 323 2.1.6.4.3. SigningTime Attribute 325 The SigningTime Attribute MAY be present. If it is present it MUST be 326 ignored by the relying party. The presence of absence of the 327 SigningTime attribute in no way affects the validation of the ROA (as 328 specified in Section 3). The attrType OID for the SigningTime 329 attribute is 1.2.840.113549.1.9.5. 331 The attrValues for the SigningTime attribute is defined as: 333 SigningTime ::= Time 335 Time ::= CHOICE { 336 utcTime UTCTime, 337 generalizedTime GeneralizedTime } 339 The Time element specifies the time, based on the local system clock, 340 at which the digital signature was applied to the content. 342 2.1.6.4.4. BinarySigningTimeAttribute 344 The BinarySigningTime Attribute MAY be present. If it is present it 345 MUST be ignored by the relying party. The presence of absence of the 346 BinarySigningTime attribute in no way affects the validation of the 347 ROA (as specified in Section 3). The attrType OID for the SigningTime 348 attribute is 1.2.840.113549.1.9.16.2.46. 350 The attrValues for the SigningTime attribute is defined as: 352 BinarySigningTime ::= BinaryTime 354 BinaryTime ::= INTEGER (0..MAX) 356 The BinaryTime element specifies the time, based on the local system 357 clock, at which the digital signature was applied to the content. 359 2.1.6.5. signatureAlgorithm 361 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 362 is 1.2.840.113549.1.1.1. 364 2.1.6.6. signature 366 The signature value is defined as: 368 SignatureValue ::= OCTET STRING 370 The signature characteristics are defined by the digest and signature 371 algorithms. 373 2.1.6.7. unsignedAttrs 375 unsignedAttrs MUST be omitted. 377 3. ROA Validation 379 Before a relying party can use a ROA to validate a routing 380 announcement, the relying party must first validate the ROA by 381 verifying that all of the following conditions hold. 383 1. The ROA syntax complies with this specification. In particular, 384 that each of the following is true: 386 a. The contentType of the CMS object is SignedData (OID 387 1.2.840.113549.1.7.2) 389 b. The version of the SignedData object is 3. 391 c. The digestAlgorithm in the SignedData object is SHA-256 (OID 392 2.16.840.1.101.3.4.2.1). 394 d. The certificates field in the SignedData object is present and 395 contains an EE certificate whose Subject Key Identifier (SKI) 396 matches the sid field of the SignerInfo object. 398 e. The crls field in the SignedData object is omitted. 400 f. The eContentType in the EncapsulatedContentInfo is 401 routeOriginAttestation (OID 1.2.840.113549.1.9.16.1.24) 403 g. The version of the RouteOriginAttestation is 0. 405 h. The addressFamily in the ROAIPAddressFamily is either IPv4 or 406 IPv6 (0001 and 0002, respectively). 408 i. The version of the SignerInfo is 3. 410 j. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 411 2.16.840.1.101.3.4.2.1). 413 k. The signatureAlgorithm in the SignerInfo object is RSA (OID 414 1.2.840.113549.1.1.1). 416 l. The signedAttrs field in the SignerInfo object is present and 417 contains both the ContentType attribute (OID 418 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 419 1.2.840.113549.1.9.4). 421 m. The unsignedAttrs field in the SignerInfo object is omitted. 423 2. The public key of the EE certificate (contained within the ROA) 424 can be used to verify the signature on the ROA. 426 3. The IP Address Delegation extension [RFC3779] is present in the EE 427 certificate (contained within the ROA) and each IP address 428 prefix(es) in ROA is contained within the set of IP addresses 429 specified by the EE certificate's IP address delegation extension. 431 4. The EE certificate (contained within the ROA) is a valid end- 432 entity certificate in the resource PKI as specified by [RESCERT]. 433 (In particular, there exists a valid certification path from a 434 trust anchor to the EE certificate.) 436 4. Security Considerations 438 There is no assumption of confidentiality for the data in a ROA; it 439 is anticipated that ROAs will be stored in repositories that are 440 accessible to all ISPs, and perhaps to all Internet users. There is 441 no explicit authentication associated with a ROA, since the PKI used 442 for ROA validation provides authorization but not authentication. 443 Although the ROA is a signed, application layer object, there is no 444 intent to convey non-repudiation via a ROA. 446 The purpose of a ROA is to convey authorization for an AS to 447 originate a route to the prefix(es) in the ROA. Thus the integrity of 448 a ROA must be established. The ROA makes use of the CMS signed 449 message format for integrity, and thus inherits the security 450 considerations associated with that data structure. The right of the 451 ROA signer to authorize the target AS to originate routes to the 452 prefix(es) is established through use of the address space and AS 453 number PKI described in [ARCH]. Specifically one must verify the 454 signature on the ROA using an X.509 certificate issued under this 455 PKI, and check that the prefix(es) in the ROA match those in the 456 address space extension in the certificate. 458 5. IANA Considerations 460 None. 462 6. Acknowledgments 464 The authors wish to thank Charles Gardiner, Russ Housley and 465 George Michaelson for their help and contributions. 467 7. References 469 7.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC3852] Housley, R., ''Cryptographic Message Syntax'', RFC 3852, 475 July 2004. 477 [RFC4055] Schaad, J., Kaliski, B., and Housley, R., ''Additional 478 Algorithms and Identifiers for RSA Cryptography for use in 479 the Internet X.509 Public Key Infrastructure Certificate 480 and Certificate Revocation List (CRL) Profile'', RFC 4055, 481 June 2005. 483 [RFC3779] Lynn, C., Kent, S., and Seo, K., ''X.509 Extensions for IP 484 Addresses and AS Identifiers'', RFC 3779, June 2004. 486 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 487 Housley, R., and W. Polk, "Internet X.509 Public Key 488 Infrastructure Certificate and Certificate Revocation List 489 (CRL) Profile", RFC 5280, May 2008. 491 7.2. Informative References 493 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method 494 for obtaining digital signatures and public-key 495 cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. 497 [ARCH] Lepinski, M., Kent, S., and Barnes, R., "An Infrastructure 498 to Support Secure Internet Routing," draft-ietf-sidr-arch- 499 03.txt, February, 2008 (work in progress). 501 [RESCERT] Huston, G., Michaelson, G., and Loomans, R., ''A Profile 502 for X.509 PKIX Resource Certificates,'' draft-ietf-sidr- 503 res-certs-14.txt, October, 2008 (work in progress). 505 Authors' Addresses 507 Matt Lepinski 508 BBN Technologies 509 10 Moulton Street 510 Cambridge MA 02138 512 Email: mlepinski@bbn.com 514 Stephen Kent 515 BBN Technologies 516 10 Moulton Street 517 Cambridge MA 02138 519 Email: skent@bbn.com 521 Derrick Kong 522 BBN Technologies 523 10 Moulton Street 524 Cambridge MA 02138 526 Email: dkong@bbn.com 528 Intellectual Property Statement 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 Disclaimer of Validity 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Copyright Statement 564 Copyright (C) The IETF Trust (2008). 566 This document is subject to the rights, licenses and restrictions 567 contained in BCP 78, and except as set forth therein, the authors 568 retain all their rights.