idnits 2.17.1 draft-ietf-sidr-roa-format-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. 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 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 (February 2007) is 6279 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 230 -- Looks like a reference, but probably isn't: '1' on line 217 == Unused Reference: 'RFC2119' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 311, 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-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing (sidr) Kent, S. 2 Internet Draft Kong, D. 3 Expires: August 2007 BBN Technologies 4 Intended Status: Proposed Standard February 2007 6 A Profile for Route Origin Authorizations (ROA) 7 draft-ietf-sidr-roa-format-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 26, 2007. 35 Abstract 37 This document defines a standard profile for Route Origin 38 Authorizations (ROAs). A ROA is a digitally signed object that 39 provides a means of verifying that an IP address block holder has 40 authorized an Autonomous System (AS) to originate routes to that 41 address block. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 Error! 48 Reference source not found.. 50 Table of Contents 52 1. Introduction...................................................2 53 2. Basic Format...................................................3 54 2.1. Signed-Data Content Type..................................3 55 2.1.1. version..............................................3 56 2.1.2. digestAlgorithms.....................................3 57 2.1.3. encapContentInfo.....................................3 58 2.1.3.1. eContentType....................................4 59 2.1.3.2. eContent........................................4 60 2.1.4. certificates.........................................5 61 2.1.5. crls.................................................5 62 2.1.6. signerInfos..........................................5 63 2.1.6.1. version.........................................5 64 2.1.6.2. sid.............................................5 65 2.1.6.3. digestAlgorithm.................................6 66 2.1.6.4. signedAttrs.....................................6 67 2.1.6.5. signatureAlgorithm..............................6 68 2.1.6.6. signature.......................................6 69 2.1.6.7. unsignedAttrs...................................6 70 3. Security Considerations........................................6 71 4. IANA Considerations............................................7 72 5. Acknowledgments................................................7 73 6. References.....................................................8 74 6.1. Normative References......................................8 75 6.2. Informative References....................................8 76 Author's Addresses................................................9 77 Intellectual Property Statement..................................10 78 Disclaimer of Validity...........................................10 79 Copyright Statement..............................................10 81 1. Introduction 83 The primary purpose of the Internet IP Address and AS Number public 84 key infrastructure (PKI) system is to improve routing security. As 85 part of this system, a mechanism is needed to allow entities to 86 verify that an AS has been given permission by an IP address block 87 holder to advertise routes to that block. A ROA provides this 88 function. 90 A ROA is a digitally signed object that makes use of Cryptographic 91 Message Syntax (CMS) [RFC3852] as a standard encapsulation format. 93 CMS was chosen to take advantage of existing open source software 94 available for processing messages in this format. 96 2. Basic Format 98 Using CMS syntax, a ROA is a type of signed-data object. The general 99 format of a CMS object is: 101 ContentInfo ::= SEQUENCE { 102 contentType ContentType, 103 content [0] EXPLICIT ANY DEFINED BY contentType } 105 ContentType ::= OBJECT IDENTIFIER 107 As a ROA is a signed-data object, it uses the corresponding OID, 108 1.2.840.113549.1.7.2. [RFC3852] 110 2.1. Signed-Data Content Type 112 According to the CMS standard, the signed-data content type shall 113 have ASN.1 type SignedData: 115 SignedData ::= SEQUENCE { 116 version CMSVersion, 117 digestAlgorithms DigestAlgorithmIdentifiers, 118 encapContentInfo EncapsulatedContentInfo, 119 certificates [0] IMPLICIT CertificateSet OPTIONAL, 120 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 121 signerInfos SignerInfos } 123 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 125 SignerInfos ::= SET OF SignerInfo 127 2.1.1. version 129 The version is the syntax version number. It MUST be 3, 130 corresponding to the signerInfo structure having version number 3. 132 2.1.2. digestAlgorithms 134 The digestAlgorithms set MUST include only SHA-256, the OID for which 135 is 2.16.840.1.101.3.4.2.1. [RFC4055] It MUST NOT contain any other 136 algorithms. 138 2.1.3. encapContentInfo 140 encapContentInfo is the signed content, consisting of a content type 141 identifier and the content itself. 143 EncapsulatedContentInfo ::= SEQUENCE { 144 eContentType ContentType, 145 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 147 ContentType ::= OBJECT IDENTIFIER 149 2.1.3.1. eContentType 151 The ContentType for a ROA is defined as routeOriginAttestation and 152 has the numerical value of 1.2.840.113549.1.9.16.1.24. 154 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 155 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 157 id-ct OBJECT INDENTIFIER ::= { id-smime 1 } 159 routeOriginAttestion OBJECT IDENTIFIER ::= { id-ct 24 } 161 2.1.3.2. eContent 163 The content of a ROA is a single AS that has been authorized by the 164 address space holder to originate routes and a list of one or more IP 165 address prefixes that will be advertised. If the address space 166 holder needs to authorize multiple ASes to advertise the same set of 167 address blocks, the holder issues multiple ROAs, one per AS number. 168 It is formally defined as: 170 RouteOriginAttestation ::= SEQUENCE { 171 version [0] INTEGER DEFAULT 0, 172 asID ASID, 173 ipAddrBlocks ROAIPAddrBlocks } 175 ASID ::= INTEGER 177 ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily 179 ROAIPAddressFamily ::= SEQUENCE { 180 addressFamily OCTET STRING (SIZE (2..3)), 181 addressesOrRanges SEQUENCE OF IPAddressOrRange } 182 -- Only two address families are allowed: IPv4 and IPv6 183 IPAddressOrRange ::= CHOICE { 184 addressPrefix IPAddress, 185 addressRange IPAddressRange } 187 IPAddressRange ::= SEQUENCE { 188 min IPAddress, 189 max IPAddress } 191 IPAddress ::= BIT STRING 193 2.1.4. certificates 195 The certificates field MAY be included. If so, it MUST contain only 196 the end entity certificate needed to validate this ROA. This 197 certificate should be present only if the ROA is being transmitted to 198 a relying party. Thus in the initial use of ROA's where they are 199 being made available to relying parties via a repository system, this 200 certificate SHOULD be omitted. 202 2.1.5. crls 204 The crls field MUST be omitted. 206 2.1.6. signerInfos 208 SignerInfo is defined under CMS as: 210 SignerInfo ::= SEQUENCE { 211 version CMSVersion, 212 sid SignerIdentifier, 213 digestAlgorithm DigestAlgorithmIdentifier, 214 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 215 signatureAlgorithm SignatureAlgorithmIdentifier, 216 signature SignatureValue, 217 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 219 2.1.6.1. version 221 The version number MUST be 3, corresponding with the choice of 222 SubjectKeyIdentifier for the sid. 224 2.1.6.2. sid 226 The sid is defined as: 228 SignerIdentifier ::= CHOICE { 229 issuerAndSerialNumber IssuerAndSerialNumber, 230 subjectKeyIdentifier [0] SubjectKeyIdentifier } 232 For a ROA, the sid MUST be a SubjectKeyIdentifier. 234 2.1.6.3. digestAlgorithm 236 The digestAlgorithm MUST be SHA-256, the OID for which is 237 2.16.840.1.101.3.4.2.1. [RFC4055] 239 2.1.6.4. signedAttrs 241 signedAttrs MUST be omitted. 243 2.1.6.5. signatureAlgorithm 245 The signatureAlgorithm MUST be SHA-256 with RSA 246 (sha256WithRSAEncryption), the OID for which is 247 1.2.840.113549.1.1.11. [RFC4055] 249 2.1.6.6. signature 251 The signature value is defined as: 253 SignatureValue ::= OCTET STRING 255 The signature characteristics are defined by the digest and signature 256 algorithms. 258 2.1.6.7. unsignedAttrs 260 unsignedAttrs MUST be omitted. 262 3. Security Considerations 264 There is no assumption of confidentiality for the data in a ROA; it 265 is anticipated that ROAs will be stored in repositories that are 266 accessible to all ISPs, maybe to all Internet users. There is no 267 explicit authentication associated with a ROA, since the PKI used for 268 ROA validation provides authorization but not authentication. 269 Although the ROA is a signed, application layer object, there is no 270 intent to convey non-repudiation via a ROA. 272 The purpose of a ROA is to convey authorization for an AS to 273 originate a route to the prefix(es) in the ROA. Thus the integrity of 274 a ROA must be established. The ROA makes use of the CMS signed 275 message format for integrity, and thus inherits the security 276 considerations associated with that data structure. The right of the 277 ROA signer to authorize the target AS to originate routes to the 278 prefix(es) is established through use of the address space and AS 279 number PKI described in [ARCH]. Specifically one must verify the 280 signature on the ROA using an X.509 certificate issued under this 281 PKI, and check that the prefix(es) in the ROA match those in the 282 address space extension in the certificate. 284 4. IANA Considerations 286 None. 288 5. Acknowledgments 290 The authors wish to thank Charles Gardiner and Russ Housley for their 291 help and contributions. 293 6. References 295 6.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC3852] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 301 2004. 303 [RFC4055] Schaad, J., Kaliski, B., and Housley, R., "Additional 304 Algorithms and Identifiers for RSA Cryptography for use in 305 the Internet X.509 Public Key Infrastructure Certificate 306 and Certificate Revocation List (CRL) Profile", RFC 4055, 307 June 2005. 309 6.2. Informative References 311 [RSA] Rivest, R., Shamir, A., and Adelman, L. M. 1978. A method 312 for obtaining digital signatures and public-key 313 cryptosystems. Commun. ACM 21, 2 (Feb.), 120-126. 315 [ARCH] Kent, S., Barnes, R., "An Infrastructure to Support Secure 316 Internet Routing," draft-ietf-sidr-arch-00.txt, February, 317 2007 (work in progress). 319 Author's Addresses 321 Stephen Kent 322 BBN Technologies 323 10 Moulton Street 324 Cambridge MA 02138 325 USA 327 Phone: +1 (617) 873-3988 328 Email: skent@bbn.com 330 Derrick Kong 331 BBN Technologies 332 10 Moulton Street 333 Cambridge MA 02138 334 USA 336 Phone: +1 (617) 873-1951 337 Email: dkong@bbn.com 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 368 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 369 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 370 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The IETF Trust (2007). 377 This document is subject to the rights, licenses and restrictions 378 contained in BCP 78, and except as set forth therein, the authors 379 retain all their rights.