idnits 2.17.00 (12 Aug 2021) /tmp/idnits23859/draft-reynolds-bgpsec-rtrcerts-00.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 abstract seems to contain references ([ID.sidr-arch], [ID.res-cert-prof]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 2, 2011) is 4005 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: 'ID.sidr-arch' is mentioned on line 194, but not defined == Missing Reference: 'ID.res-cert-prof' is mentioned on line 339, but not defined == Missing Reference: 'RFC 5492' is mentioned on line 136, but not defined == Missing Reference: 'RFC 5123' is mentioned on line 137, but not defined == Missing Reference: 'RFC 4272' is mentioned on line 138, but not defined == Missing Reference: 'RFC5380' is mentioned on line 168, but not defined == Unused Reference: 'ID.sidr-rpki-algs' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC2050' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC4211' is defined on line 377, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-rpki-algs has been published as RFC 6485 ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S. Kent 3 Internet-Draft M. Lepinski 4 Intended status: Standards Track M. Reynolds 5 Expires: December 4, 2011 BBN 6 June 2, 2011 8 A Profile for BGPSEC Router Certificates 9 draft-reynolds-bgpsec-rtrcerts-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on December 4, 2011. 34 Copyright and License Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 included Simplified BSD License text as described in Section 4.e of 46 the Legal Trust Provisions and are provided without warranty as 47 described in the BSD License. 49 Abstract 51 This document defines a standard profile for X.509 certificates for 52 the purposes of supporting validation of Autonomous System (AS) paths 53 in the Border Gateway Protocol (BGP), as part of an extension to that 54 protocol known as BGPSEC. BGP is a critical component for the proper 55 operation of the Internet as a whole. The BGPSEC protocol is under 56 development as a component to address the requirement to provide 57 security for the BGP protocol. The goal of BGPSEC is to design a 58 protocol for full AS path validation based on the use of strong 59 cryptographic primitives. The end-entity (EE) certificates specified 60 by this profile are issued under Resource PKI (RPKI) CA certificates, 61 containing the RFC 3779 AS number extension, to routers within the 62 autonomous system. The certificate asserts that the router(s) holding 63 the public key are authorized to send out secure route advertisements 64 on behalf of the specified autonomous system. Note that since these 65 certificates extend the RPKI [ID.sidr-arch], this profile is based on 66 the profile for RPKI resource certificates [ID.res-cert-prof]. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 73 3. BGPSEC Router Certificate Fields . . . . . . . . . . . . . . . 6 74 3.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2 Serial Number . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.3 Signature Algorithm . . . . . . . . . . . . . . . . . . . . 6 77 3.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.5 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.6 Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.7 Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.8 Subject Public Key Info . . . . . . . . . . . . . . . . . . 7 82 3.9 BGPSEC Router Certificate Version 3 Extension Fields . . . 7 83 3.9.1 Basic Constraints . . . . . . . . . . . . . . . . . . 7 84 3.9.2 Subject Key Identifier . . . . . . . . . . . . . . . . 7 85 3.9.3 Authority Key Identifier . . . . . . . . . . . . . . . 7 86 3.9.4 Key Usage . . . . . . . . . . . . . . . . . . . . . . 7 87 3.9.5 Extended Key Usage . . . . . . . . . . . . . . . . . . 8 88 3.9.6 CRL Distribution Points . . . . . . . . . . . . . . . 8 89 3.9.7 Authority Information Access . . . . . . . . . . . . . 8 90 3.9.8 Subject Information Access . . . . . . . . . . . . . . 8 91 3.9.9 Certificate Policies . . . . . . . . . . . . . . . . . 8 92 3.9.10 IP Resources . . . . . . . . . . . . . . . . . . . . 8 93 3.9.11 AS Resources . . . . . . . . . . . . . . . . . . . . 8 94 4. BGPSEC Router Certificate Revocation List Profile . . . . . . . 9 95 5. BGPSEC Router Certificate Request Profile . . . . . . . . . . 10 96 6. BGPSEC Router Certificate Validation . . . . . . . . . . . . 11 97 7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . 12 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 102 10.2 Informative References . . . . . . . . . . . . . . . . . 14 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 104 Appendix A: Example BGPSEC Router Certificate . . . . . . . . . . 16 105 Appendix B: Example Certificate Revocation List . . . . . . . . . 16 107 1. Introduction 109 This document defines a profile for X.509 end entity (EE) 110 certificates [X.509] for use in the context of certification of AS 111 paths in the BGPSEC protocol. Such certificates are termed "BGPSEC 112 Router certificates". The holder of the private key associated with a 113 BGPSEC router certificate is authorized to send secure route 114 advertisements (BGPSEC UPDATEs) on behalf of the AS named in the 115 certificate. That is, a router holding the private key may send to 116 its BGP peers, route advertisements that contain the specified AS 117 number as the last item in the AS PATH attribute. A key property that 118 BGPSEC will provide is that every autonomous system along the AS PATH 119 can verify that the other ASes along the path have authorized the 120 advertisement of the given route (to the next AS along the AS PATH). 122 This document is a profile of [ID.res-cert-prof], which is a profile 123 of RFC 5280. It establishes requirements imposed on a Resource 124 certificate that is used as a BGPSEC Router certificate, i.e., it 125 defines constraints for certificate fields and extensions for the 126 certificate to be valid in this context. A relying party processing 127 what purports to be a BGPSEC Router certificate MUST verify that the 128 certificate conforms to this profile. 130 1.1 Terminology 132 It is assumed that the reader is familiar with the terms and concepts 133 described in "Internet X.509 Public Key Infrastructure Certificate 134 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 135 Extensions for IP Addresses and AS Identifiers" [RFC3779], 136 "Capability Advertisement with BGP-4" [RFC 5492], "Considerations in 137 Validating the Path in BGP" [RFC 5123], "BGP Security Vulnerabilities 138 Analysis" [RFC 4272], and "A Border Gateway Protocol 4 (BGP-4)" [RFC 139 4271]. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 2. Describing Resources in Certificates 147 The framework for describing an association between the subject of a 148 certificate and the AS resources currently under the subject's 149 control is described in RFC 3779. 151 There are two aspects of this resource extension that are noted in 152 this profile. First, RFC 3779 notes that a resource extension SHOULD 153 be a CRITICAL extension to the X.509 certificate. This BGPSEC Router 154 certificate profile further mandates that this certificate extension 155 MUST appear in all BGPSEC Router certificates and MUST be marked as 156 CRITICAL. Second, a test of the resource extension in the context of 157 certificate validity includes the condition that the resources 158 described in the immediate parent CA certificate in the PKI (the 159 certificate where this certificate's issuer is the subject) has a 160 resource set, hereinafter called the "issuer's resource set" that 161 MUST encompass the resource set of the issued certificate. In this 162 context "encompass" allows for the issuer's resource set to be the 163 same as, or a strict superset of, a subject's resource set. 165 3. BGPSEC Router Certificate Fields 167 A BGPSEC Router Certificate is a valid X.509 public key certificate, 168 consistent with the PKIX profile [RFC5380], containing the fields 169 listed in this section. Unless specifically noted as being OPTIONAL, 170 all the fields listed here MUST be present, and any other field MUST 171 NOT appear in a conforming BGPSEC Router Certificate. If a field 172 value is specified here, this value MUST be used in conforming BGPSEC 173 Router certificates. For any BGPSEC Router certificate field that is 174 the same as in the [ID.res-cert-prof] profile, this document will 175 cite the corresponding section in that document. 177 3.1 Version 179 Refer to section 4.1 of [ID.res-cert-prof]. 181 3.2 Serial Number 183 Refer to section 4.2 of [ID.res-cert-prof]. 185 3.3 Signature Algorithm 187 Refer to section 4.3 of [ID.res-cert-prof]. 189 3.4 Issuer 191 Refer to section 4.4 of [ID.res-cert-prof]. The value of this field 192 is a distinguished name that adheres to the conventions imposed on 193 Issuer (and Subject) names that appear in Resource Certificates, as 194 described in [ID.sidr-arch]. 196 3.5 Subject 198 This field identifies the router to which the certificate has been 199 issued. Consistent with [ID.res-cert-prof], only two attributes are 200 allowed in the Subject field: common name and serial number. 201 Moreover, the only common name encoding options that are supported 202 are printableString and UTF8String. For router certificates, it is 203 RECOMMENDED that the common name attribute contain the literal string 204 "ROUTER-" followed by the 32-bit router ID encoded as eight 205 hexadecimal digits. If the same certificate is issued to more than 206 one router (hence the private key is shared among these routers), the 207 choice of the router ID used in this name is at the discretion of the 208 issuer. Note that router IDs are not guaranteed to be unique across 209 the Internet, and thus the Subject name in a BGPSEC Router 210 certificate issued using this convention also is not guaranteed to be 211 unique across different issuers. However, each certificate issued by 212 an individual CA MUST contain a subject name that is unique within 213 that context. 215 3.6 Valid From 217 Refer to section 4.6 of [ID.res-cert-prof]. 219 3.7 Valid To 221 Refer to section 4.6 of [ID.res-cert-prof]. 223 3.8 Subject Public Key Info 225 Refer to section 4.7 of [ID.res-cert-prof]. 227 3.9 BGPSEC Router Certificate Version 3 Extension Fields 229 The following X.509 V3 extensions MUST be present (or MUST be absent, 230 if so stated) in a conforming BGPSEC Router certificate, except where 231 explicitly noted otherwise. No other extensions are allowed in a 232 conforming BGPSEC Router certificate. 234 3.9.1 Basic Constraints 236 The basic constraints extension identifies whether the subject of the 237 certificate is a CA and the maximum depth of valid certification 238 paths that include this certificate. Since a BGPSEC Router 239 certificate is always an EE certificate, the basic constraints 240 extension MUST NOT be present. 242 3.9.2 Subject Key Identifier 244 The subject key identifier (SKI) extension MUST appear in every 245 Resource Certificate, as per section 4.8.2 of [ID.res-cert-prof]. For 246 a BGPSEC Router certificate, the SKI is used as a shorthand means of 247 uniquely identifying an individual certificate. The SKI in a Resource 248 certificate is generated from the public key in the certificate, 249 using the SHA-1 algorithm, as described in section 4.2.1.2 of RFC 250 5280. This extension MUST appear in all BGPSEC Router certificates. 251 This extension is non-critical. 253 3.9.3 Authority Key Identifier 255 This is a non-critical extension and it MUST be present, as per 256 section 4.8.3 of [ID.res-cert-prof]. 258 3.9.4 Key Usage 260 This is a critical extension, and it MUST be present. The 261 digitalSignature bit MUST be set to TRUE in all BGPSEC Router 262 certificates, and it MUST be the only bit set to TRUE. 264 3.9.5 Extended Key Usage 266 The EKU extension MUST NOT appear in a BGPSEC Router certificate. 268 3.9.6 CRL Distribution Points 270 The CRLDP extension is non-critical and MUST appear in every BGPSEC 271 Router Certificate, as per section 4.8.6 of [ID.res-cert-prof]. 273 3.9.7 Authority Information Access 275 The AIA extension is non-critical and MUST appear in every BGPSEC 276 Router Certificate, as per section 4.8.7 of [ID.res-cert-prof]. 278 3.9.8 Subject Information Access 280 This extension is not used in BGPSEC Router certificates. It MUST be 281 omitted. 283 3.9.9 Certificate Policies 285 This critical extension MUST be present as per section 4.8.9 of 286 [ID.res-cert-prof]. 288 3.9.10 IP Resources 290 This extension is not used in BGPSEC Router certificates. It MUST be 291 omitted. 293 3.9.11 AS Resources 295 This extension contains the list of AS numbers that the router is 296 authorized to represent in BGP advertisements, encoded as specified 297 in RFC 3779. The "inherit" element MUST NOT be specified. As 298 specified in section 4.8.11 of [ID.res-cert-prof], RDI values MUST 299 NOT be used. All BGPSEC Router certificates MUST include an AS 300 resources extension, and the extension MUST contain exactly one AS 301 number. This extension MUST be marked critical. 303 4. BGPSEC Router Certificate Revocation List Profile 305 BGPSEC Router certificates are just another type of EE certificate 306 issued by an RPKI CA. Therefore, there are no distinguishing features 307 for the CRLs on which they appear. Refer to section 5 of [ID.res- 308 cert-prof] for a complete description of the profile for these CRLs. 310 5. BGPSEC Router Certificate Request Profile 312 Refer to section 6 of [ID.res-cert-prof]. 314 6. BGPSEC Router Certificate Validation 316 The validation procedure used for BGPSEC Router certificates is 317 identical to the validation procedure described in Section 7 of 318 [ID.res-cert-prof], with two further restrictions. First, all IP 319 address resources for a BGPSEC Router certificate will be empty. 320 Second, the sole AS number resource in the BGPSEC Router certificate 321 must match the last AS number in the AS path information of each BGP 322 UPDATE message. While this second restriction is not part of 323 validation per se, it is part of the operational validation of 324 UPDATEs performed by the router. 326 7. Design Notes 328 The BGPSEC Router Certificate profile is based off the Resource 329 Certificate profile as specified in [ID.res-cert-prof]. As a result, 330 many of the design choices herein are a reflection of the design 331 choices that were taken in that prior work. The reader is referred to 332 [ID.res-cert-prof] for a fuller discussion of those choices. 334 8. Security Considerations 336 The Security Considerations of RFC5280 and RFC3779 apply to BGPSEC 337 Router Certificates as defined by this profile, and their use. 338 Additionally, the Security Considerations documented in the RPKI 339 Architecture and Resource Certificate Profile [ID.res-cert-prof] 340 apply. 342 A BGPSEC Router Certificate is an extension of the RPKI to encompass 343 routers. It is a building block of the larger BGPSEC security 344 protocol used to validate signatures on BGPSEC Signature-Segment 345 origination of Signed-Path segments. Thus its essential security 346 function is the secure binding of an AS number to a public key, 347 consistent with the RPKI allocation/assignment hierarchy. 349 9. IANA Considerations 351 [Note to IANA, to be removed prior to publication: there are no IANA 352 considerations stated in this version of the document.] 354 10 References 356 10.1 Normative References 358 [ID.sidr-rpki-algs] 359 Huston, G., "A Profile for Algorithms and Key Sizes for 360 use in the Resource Public Key Infrastructure" (work in 361 progress); Internet Drafts draft-ietf-sidr-rpki-algs- 362 05.txt, April 2011. 364 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenburg, D., and 365 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 366 BCP 12, RFC 2050, November 1996. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC3513] Hinden, R., and S. Deering, "Internet Protocol Version 6 372 (IPv6) Addressing Architecture", RFC 3513, April 2003. 374 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 375 Addresses and AS Identifiers", RFC 3779, June 2004. 377 [RFC4211] Schaad, J., and S. Deering, "Internet X.509 Public Key 378 Infrastructure Certificate Request Message Format 379 (CRMF)", RFC 4211, June 2004. 381 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 382 Housley, R., and W. Polk, "Internet X.509 Public Key 383 Infrastructure Certificate and Certificate Revocation 384 List (CRL) Profile", RFC 5280, May 2008. 386 [X.509] ITU-T, "Recommendation X.509: The Directory Authentication 387 Format", 2000. 389 [I-D. sidr-arch] 390 Lepinski, M. and S. Kent, "An Infrastructure to Support 391 Secure Internet Routing", draft-ietf-side-arch-13.txt 392 (work in progress), May 2011. 394 [I-D. sidr-manifests] 395 Austein, R., Huston, G., Kent, S., and M. Lepinski, 396 "Manifests for the Resource Public Key Intrastructure" 397 (work in progress); Internet Draft draft-ietf-sidr-rpki- 398 manifests-12.txt, May 2011. 400 [I-D. sidr-res-cert-prof] 401 Huston, G., Michaelson, G., and R. Loomans, "A Profile 402 for X.509 PKIX Resource Certificates", draft-ietf-sidr- 403 res-certs-22.txt; (work in progress), May 2011. 405 10.2 Informative References 407 [rsync] Tridgell, A., "rsync", April 2006, 408 410 Authors' Addresses 412 Stephen Kent 413 Raytheon BBN Technologies Corp. 414 10 Moulton St. 415 Cambridge, MA 02138 417 Email: kent@bbn.com 419 Matthew Lepinski 420 Raytheon BBN Technologies Corp. 421 10 Moulton St. 422 Cambridge, MA 02138 424 Email: mlepinsk@bbn.com 426 Mark Reynolds 427 Raytheon BBN Technologies Corp. 429 10 Moulton St. 430 Cambridge, MA 02138 432 Email: mreynold@bbn.com 434 Appendix A: Example BGPSEC Router Certificate 436 TBD 438 Appendix B: Example Certificate Revocation List 440 TBD