idnits 2.17.1 draft-ietf-sidr-bgpsec-pki-profiles-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6487, but the abstract doesn't seem to directly say this. It does mention RFC6487 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6487, updated by this document, for RFC5378 checks: 2006-06-09) -- 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 (March 27, 2014) is 3655 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) ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing Working Group M. Reynolds 3 Internet-Draft IPSw 4 Updates: 6487 (if approved) S. Turner 5 Intended Status: Standards Track IECA 6 Expires: September 27, 2014 S. Kent 7 BBN 8 March 27, 2014 10 A Profile for BGPSEC Router Certificates, 11 Certificate Revocation Lists, and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-07 14 Abstract 16 This document defines a standard profile for X.509 certificates for 17 the purposes of supporting validation of Autonomous System (AS) paths 18 in the Border Gateway Protocol (BGP), as part of an extension to that 19 protocol known as BGPSEC. BGP is a critical component for the proper 20 operation of the Internet as a whole. The BGPSEC protocol is under 21 development as a component to address the requirement to provide 22 security for the BGP protocol. The goal of BGPSEC is to design a 23 protocol for full AS path validation based on the use of strong 24 cryptographic primitives. The end-entity (EE) certificates specified 25 by this profile are issued under Resource Public Key Infrastructure 26 (RPKI) Certification Authority (CA) certificates, containing the AS 27 Identifier Delegation extension, to routers within the Autonomous 28 System (AS) or ASes. The certificate asserts that the router(s) 29 holding the private key are authorized to send out secure route 30 advertisements on behalf of the specified AS(es). This document also 31 profiles the Certificate Revocation List (CRL), profiles the format 32 of certification requests, and specifies Relying Party certificate 33 path validation procedures. The document extends the RPKI; 34 therefore, this documents updates the RPKI Resource Certificates 35 Profile (RFC 6487). 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 Copyright Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 1. Introduction 69 This document defines a profile for X.509 end-entity (EE) 70 certificates [RFC5280] for use in the context of certification of 71 Autonomous System (AS) paths in the Border Gateway Protocol Security 72 (BGPSEC) protocol. Such certificates are termed "BGPSEC Router 73 Certificates". The holder of the private key associated with a 74 BGPSEC Router Certificate is authorized to send secure route 75 advertisements (BGPSEC UPDATEs) on behalf of the AS(es) named in the 76 certificate. That is, a router holding the private key may send to 77 its BGP peers, route advertisements that contain one or more of the 78 specified AS number as the last item in the AS PATH attribute. A key 79 property that BGPSEC will provide is that every AS along the AS PATH 80 can verify that the other ASes along the path have authorized the 81 advertisement of the given route (to the next AS along the AS PATH). 83 This document is a profile of [RFC6487], which is a profile of 84 [RFC5280], and it updates [RFC6487]. It establishes requirements 85 imposed on a Resource Certificate that is used as a BGPSEC Router 86 Certificate, i.e., it defines constraints for certificate fields and 87 extensions for the certificate to be valid in this context. This 88 document also profiles the Certificate Revocation List (CRL) and 89 certification requests. Finally, this document specifies the Relying 90 Party (RP) certificate path validation procedures. 92 1.1. Terminology 94 It is assumed that the reader is familiar with the terms and concepts 95 described in "A Profile for X.509 PKIX Resource Certificates" 96 [RFC6487], "BGPSEC Protocol Specification" [ID.sidr-bgpsec-protocol], 97 "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security 98 Vulnerabilities Analysis" [RFC4272], "Considerations in Validating 99 the Path in BGP" [RFC5123], and "Capability Advertisement with BGP-4" 100 [RFC5492]. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 2. Describing Resources in Certificates 109 Figure 1 depicts some of the entities in the RPKI and some of the 110 products generated by RPKI entities. IANA issues a Certification 111 Authority (CA) to a Regional Internet Registries (RIR). The RIR, in 112 turn, issues a CA certificate to an Internet Service Providers (ISP). 113 The ISP in turn issues End-Entity (EE) Certificates to itself as 114 well as CRLs. These certificates are referred to as "Resource 115 Certificates", and are profiled in [RFC6487]. The [RFC6480] 116 envisioned using Resource Certificates to generate Manifests 117 [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs and 118 Manifests also include the Resource Certificates used to sign them. 120 +---------+ +------+ 121 | CA Cert |---| IANA | 122 +---------+ +------+ 123 \ 124 +---------+ +-----+ 125 | CA Cert |---| RIR | 126 +---------+ +-----+ 127 \ 128 +---------+ +-----+ 129 | CA Cert |---| ISP | 130 +---------+ +-----+ 131 / | | | 132 +-----+ / | | | +-----+ 133 | CRL |--+ | | +---| ROA | 134 +-----+ | | +-----+ 135 | | +----------+ 136 +----+ | +---| Manifest | 137 +-| EE |---+ +----------+ 138 | +----+ 139 +-----+ 140 Figure 1 142 This document defines another type of Resource Certificate, which is 143 referred to as a "BGPSEC Router Certificate". The purpose of this 144 certificate is explained in Section 1 and falls within the scope of 145 appropriate uses defined within [RFC6484]. The issuance of BGPSEC 146 Router Certificates has minimal impact on RPKI CAs because the RPKI 147 CA certificate and CRL profile remain unchanged (i.e., they are as 148 specified in [RFC6487]). Further, the algorithms used to generate 149 RPKI CA certificates that issue the BGPSEC Router Certificates and 150 the CRLs necessary to check the validity of the BGPSEC Router 151 Certificates remain unchanged (i.e., they are as specified in 152 [RFC6485]). The only impact is that the RPKI CAs will need to be 153 able to process a profiled certificate request (see Section 5) signed 154 with algorithms found in [ID.sidr-bgpsec-algs]. The use of BGPSEC 155 Router Certificates in no way affects RPKI RPs that process Manifests 156 and ROAs because the public key found in the BGPSEC Router 157 Certificate is only ever used to verify the signature on the BGPSEC 158 certificate request (only CAs process these) and the signature on a 159 BGPSEC Update Message [ID.sidr-bgpsec-protocol] (only BGPSEC routers 160 process these). 162 Only the differences between this profile and the profile in 163 [RFC6487] are listed. Note that BGPSEC Router Certificates are EE 164 certificates and as such there is no impact on process described in 165 [RFC6916]. 167 3. Updates to [RFC6487] 169 3.1 BGPSEC Router Certificate Fields 171 A BGPSEC Router Certificate is a valid X.509 public key certificate, 172 consistent with the PKIX profile [RFC5280], containing the fields 173 listed in this section. This profile is also based on [RFC6487] and 174 only the differences between this profile and the profile in 175 [RFC6487] are listed. 177 3.1.1.1. Subject 179 This field identifies the router to which the certificate has been 180 issued. Consistent with [RFC6487], only two attributes are allowed 181 in the Subject field: common name and serial number. Moreover, the 182 only common name encoding options that are supported are 183 printableString and UTF8String. For BGPSEC Router Certificates, it 184 is RECOMMENDED that the common name attribute contain the literal 185 string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded 186 as eight hexadecimal digits and that the serial number attribute 187 contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) 188 encoded as eight hexadecimal digits. If there is more than one AS 189 number, the choice of which to include in the common name is at the 190 discretion of the Issuer. If the same certificate is issued to more 191 than one router (hence the private key is shared among these 192 routers), the choice of the router ID used in this name is at the 193 discretion of the Issuer. Note that router IDs are not guaranteed to 194 be unique across the Internet, and thus the Subject name in a BGPSEC 195 Router Certificate issued using this convention also is not 196 guaranteed to be unique across different issuers. However, each 197 certificate issued by an individual CA MUST contain a Subject name 198 that is unique within that context. 200 3.1.2. Subject Public Key Info 202 Refer to section 3.1 of [ID.sidr-bgpsec-algs]. 204 3.1.3. BGPSEC Router Certificate Version 3 Extension Fields 206 The following X.509 V3 extensions MUST be present (or MUST be absent, 207 if so stated) in a conforming BGPSEC Router Certificate, except where 208 explicitly noted otherwise. No other extensions are allowed in a 209 conforming BGPSEC Router Certificate. 211 3.1.3.1. Basic Constraints 213 BGPSEC speakers are EEs; therefore, the Basic Constraints extension 214 must not be present, as per [RFC6487]. 216 3.1.3.2. Extended Key Usage 218 BGPSEC Router Certificates MUST include the Extended Key Usage (EKU) 219 extension. As specified, in [RFC6487] this extension MUST be marked 220 as non-critical. This document defines one EKU for BGPSEC Router 221 Certificates: 223 id-kp OBJECT IDENTIFIER ::= 224 { iso(1) identified-organization(3) dod(6) internet(1) 225 security(5) mechanisms(5) pkix(7) kp(3) } 227 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp TBD } 229 Relying Parties MUST require the extended key usage extension to be 230 present in a BGPSEC Router Certificate. If multiple KeyPurposeId 231 values are included, the relying parties need not recognize all of 232 them, as long as the required KeyPurposeId value is present. BGPSEC 233 RPs MUST reject certificates that do not contain the BGPSEC Router 234 EKU even if they include the anyExtendedKeyUsage OID defined in 235 [RFC5280]. 237 3.1.3.3. Subject Information Access 239 This extension is not used in BGPSEC Router Certificates. It MUST be 240 omitted. 242 3.1.3.4. IP Resources 244 This extension is not used in BGPSEC Router Certificates. It MUSt be 245 omitted. 247 3.1.3.5. AS Resources 249 Each BGPSEC Router Certificate MUST include the AS Resource 250 Identifier Delegation extension, as specified in section 4.8.11 of 251 [RFC6487]. The AS Resource Identifier Delegation extension MUST 252 include one or more AS numbers, and the "inherit" element MUST NOT be 253 specified. 255 3.2. BGPSEC Router Certificate Request Profile 257 Refer to section 6 of [RFC6487]. The only differences between this 258 profile and the profile in [RFC6487] are: 260 o The ExtendedKeyUsage extension request MUST be included and the CA 261 MUST honor the request; 263 o The SubjectPublicKeyInfo and PublicKey fields are specified in 264 [ID.sidr-bgpsec-algs]; and, 266 o The request is signed with the algorithms specified in [ID.sidr- 267 bgpsec-algs]. 269 3.3. BGPSEC Router Certificate Validation 271 The validation procedure used for BGPSEC Router Certificates is 272 identical to the validation procedure described in Section 7 of 273 [RFC6487]. The exception is that the constraints applied come from 274 this specification (e.g., in step 3: the certificate contains all the 275 field that must be present - refers to the fields that are required 276 by this specification). 278 The differences are as follows: 280 o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in 281 Section 3.1.3.1. 283 o BGPSEC Router Certificates MUST NOT include the SIA extension. 285 o BGPSEC Router Certificates MUST NOT include the IP Resource 286 extension. 288 o BGPSEC Router Certificates MUST include the AS Resource Identifier 289 Delegation extension. 291 o BGPSEC Router Certificate MUST include the "Subject Public Key 292 Info" described in [ID.sidr-bgpsec-algs] as it updates [RFC6485]. 294 NOTE: The cryptographic algorithms used by BGPSEC routers are 295 found in [ID.sidr-bgpsec-algs]. Currently, the algorithms 296 specified in [ID.sidr-bgpsec-algs] and [RFC6485] are different. 297 BGPSEC RPs will need to support algorithms that are needed to 298 validate BGPSEC signatures as well as the algorithms that are 299 needed to validate signatures on BGPSEC certificates, RPKI CA 300 certificates, and RPKI CRLs. 302 4. Design Notes 304 The BGPSEC Router Certificate profile is based on the Resource 305 Certificate profile as specified in [RFC6485]. As a result, many of 306 the design choices herein are a reflection of the design choices that 307 were taken in that prior work. The reader is referred to [RFC6484] 308 for a fuller discussion of those choices. 310 5. Security Considerations 312 The Security Considerations of [RFC6487] apply. 314 A bgpsec certificate will fail RPKI validation, as defined in 315 [RFC6487], because the algorithm suite is different. Consequently, a 316 RP needs to identify the EKU before applying the correspondent 317 validation. 319 A BGPSEC Router Certificate is an extension of the RPKI [RFC6480] to 320 encompass routers. It is a building block of the larger BGPSEC 321 security protocol used to validate signatures on BGPSEC Signature- 322 Segment origination of Signed-Path segments [ID.sidr-bgpsec- 323 protocol]. Thus its essential security function is the secure 324 binding of one or more AS numbers to a public key, consistent with 325 the RPKI allocation/assignment hierarchy. 327 6. IANA Considerations 329 None. 331 7. Acknowledgements 333 We would like to thanks Geoff Huston, George Michaelson, and Robert 334 Loomans for their work on [RFC6487], which this work is based on. In 335 addition, the efforts of Steve Kent and Matt Lepinski were 336 instrumental in preparing this work. Additionally, we'd like to 337 thank Roque Gagliano, Sandra Murphy, and Geoff Huston for their 338 reviews and comments. 340 8. References 342 8.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 348 Addresses and AS Identifiers", RFC 3779, June 2004. 350 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 351 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 353 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 354 Housley, R., and W. Polk, "Internet X.509 Public Key 355 Infrastructure Certificate and Certificate Revocation List 356 (CRL) Profile", RFC 5280, May 2008. 358 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 359 Use in the Resource Public Key Infrastructure (RPKI)", 360 RFC 6485, February 2012. 362 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 363 X.509 PKIX Resource Certificates", RFC 6487, February 2012. 365 [ID.sidr-bgpsec-algs] Reynolds, M. and S. Turner, "BGP Algorithms, 366 Key Formats, & Signature Formats", draft-ietf-sidr-bgpsec- 367 algs, work-in-progress. 369 8.2. Informative References 371 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 372 RFC 4272, January 2006. 374 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 375 Path in BGP", RFC 5123, February 2008. 377 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 378 with BGP-4", RFC 5492, February 2009. 380 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 381 Secure Internet Routing", RFC 6480, February 2012. 383 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 384 Origin Authorizations (ROAs)", RFC 6482, February 2012. 386 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 387 Policy (CP) for the Resource Public Key Infrastructure 388 (RPKI)", BCP 173, RFC 6484, February 2012. 390 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 391 "Manifests for the Resource Public Key Infrastructure 392 (RPKI)", RFC 6486, February 2012. 394 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 395 Procedure for the Resource Public Key Infrastructure 396 (RPKI)", BCP 182, RFC 6916, April 2013. 398 [ID.sidr-bgpsec-protocol] Lepinksi, M., "BGPSEC Protocol 399 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 400 progress. 402 Appendix A. ASN.1 Module 404 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 405 security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 407 DEFINITIONS EXPLICIT TAGS ::= 409 BEGIN 411 -- EXPORTS ALL -- 413 -- IMPORTS NOTHING -- 415 -- OID Arc -- 417 id-kp OBJECT IDENTIFIER ::= { 418 iso(1) identified-organization(3) dod(6) internet(1) 419 security(5) mechanisms(5) kp(3) } 421 -- BGPSEC Router Extended Key Usage -- 423 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp TBD } 425 END 427 Appendix B. Example BGPSEC Router Certificate 429 Appendix C. Example BGPSEC Router Certificate Request 430 Appendix D. Change Log 432 Please delete this section prior to publication. 434 D.1. Changes from sidr-bgpsec-pki-profiles-06 to sidr-bgpsec-pki- 435 profiles-07 437 Added text to multiple AS numbers in a single certificate. Updated 438 reference to RFC 6916. 440 D.2. Changes from sidr-bgpsec-pki-profiles-05 to sidr-bgpsec-pki- 441 profiles-06 443 Keep alive version. 445 D.3. Changes from sidr-bgpsec-pki-profiles-04 to sidr-bgpsec-pki- 446 profiles-05 448 Keep alive version. 450 D.4. Changes from sidr-bgpsec-pki-profiles-03 to sidr-bgpsec-pki- 451 profiles-04 453 In s2.1, removed the phrase "another BGPSEC Router Certificate (only 454 BGPSEC routers process these)" because the BGPSEC certificates are 455 only ever EE certificates and they're never used to verify another 456 certificate only the PDUs that are signed. 458 Added new s3.1.3.1 to explicitly state that EE certificates are only 459 ever EE certs. 461 D.5. Changes from sidr-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 462 profiles-03 464 Updated s3.3 to clarifify restrictions on path validation procedures 465 are in this specification (1st para was reworded). 467 Updated s3.3 to point to s3.1.3.1 for BGPSEC EKU (thanks Tom). 469 D.6. Changes from sidr-bgpsec-pki-profiles-01 to sidr-bgpsec-pki- 470 profiles-02 472 Updated references. 474 D.7. Changes from sidr-bgpsec-pki-profiles-00 to sidr-bgpsec-pki- 475 profiles-01 477 Added an ASN.1 Module and corrected the id-kp OID in s3.1.3.1. 479 D.8. Changes from turner-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 480 profiles-00 482 Added this change log. 484 Amplified that a BGPSEC RP will need to support both the algorithms 485 in [ID.sidr-bgpsec-algs] for BGPSEC and the algorithms in [ID.sidr- 486 rpki-algs] for certificates and CRLs. 488 Changed the name of AS Resource extension to AS Resource Identifier 489 Delegation to match what's in RFC 3779. 491 D.9. Changes from turner-bgpsec-pki-profiles -01 to -02 493 Added text in Section 2 to indicate that there's no impact on the 494 procedures defined in [RFC6916]. 496 Added a security consideration to let implementers know the BGPSEC 497 certificates will not pass RPKI validation [RFC6487] and that keying 498 off the EKU will help tremendously. 500 D.10. Changes from turner-bgpsec-pki-profiles -00 to -01 502 Corrected Section 2 to indicate that CA certificates are also RPKI 503 certificates. 505 Removed sections and text that was already in [RFC6487]. This will 506 make it easier for reviewers to figure out what is different. 508 Modified Section 6 to use 2119-language. 510 Removed requirement from Section 6 to check that the AS # in the 511 certificate is the last number in the AS path information of each BGP 512 UPDATE message. Moved to [ID.sidr-bgpsec-protocol]. 514 Authors' Addresses 516 Mark Reynolds 517 Island Peak Software 518 328 Virginia Road 519 Concord, MA 01742 521 Email: mcr@islandpeaksoftware.com 523 Sean Turner 524 IECA, Inc. 525 3057 Nutley Street, Suite 106 526 Fairfax, VA 22031 527 USA 529 EMail: turners@ieca.com 531 Steve Kent 532 Raytheon BBN Technologies 533 10 Moulton St. 534 Cambridge, MA 02138 536 Email: kent@bbn.com