idnits 2.17.1 draft-spaghetti-sidrops-rpki-validation-update-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6482, updated by this document, for RFC5378 checks: 2007-02-28) (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 (27 February 2022) is 782 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) -- Duplicate reference: RFC8360, mentioned in 'Report', was also mentioned in 'RFC8360'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Fastly 4 Obsoletes: 8360 (if approved) B. Maddison 5 Updates: 6482, 6487 (if approved) Workonline 6 Intended status: Standards Track 27 February 2022 7 Expires: 31 August 2022 9 RPKI Validation Re-reconsidered 10 draft-spaghetti-sidrops-rpki-validation-update-02 12 Abstract 14 This document describes an improved validation procedure for Resource 15 Public Key Infrastructure (RPKI) signed objects. This document 16 updates RFC 6482. This document updates RFC 6487. This document 17 obsoletes RFC 8360. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 31 August 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Deprecation of RFC 8360 . . . . . . . . . . . . . . . . . . . 2 55 3. Updates to RFC 6482 . . . . . . . . . . . . . . . . . . . . . 3 56 4. Updates to RFC 6487 . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Updates to Section 7.2 . . . . . . . . . . . . . . . . . 4 58 4.2. Updates to Section 9 . . . . . . . . . . . . . . . . . . 6 59 5. Implementation status - RFC EDITOR: REMOVE BEFORE 60 PUBLICATION . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 9.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 [RFC8360] describes an improved validation algorithm for signed 72 objects published in the RPKI. The improved validation algorithm 73 would help in situations such as described in this [Report]. 74 However, operational experience has shown the described procedure for 75 deploying updates to the validation algorithm, as described in 76 [RFC6487] Section 9, is impractical. This document deprecates the 77 original [RFC6487] section 7 algorithm in favour of the [RFC8360] 78 algorithm, and obsoletes [RFC8360] because a migration via those 79 codepoints is infeasible. This document also deprecates the 80 procedure set out in [RFC6487] section 9 for future changes to the 81 validation algorithm. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. Deprecation of RFC 8360 93 [RFC8360] defines several alternative OIDs for use in Resource 94 Certificates [RFC6487]: 96 * id-cp-ipAddr-asNumber-v2 - Section 4.2.1 [RFC8360] 97 * id-pe-ipAddrBlocks-v2 - Sections 4.2.2.1 and 4.2.2.2 [RFC8360] 99 * id-pe-autonomousSysIds-v2 - Sections 4.2.2.3 and 4.2.2.4 [RFC8360] 101 The stated purpose of the above OIDs is rendered obsolete by the 102 updated specifications contained in this document. 104 Therefore: 106 * Issuing CAs MUST NOT include the above OIDs in newly issued 107 Resource Certificates; and 109 * Relying parties encountering the above OIDs in Resource 110 Certificates MUST proceed according to the updated procedures 111 described below. 113 3. Updates to RFC 6482 115 This section updates Section 4 [RFC6482]. The following text: 117 The IP address delegation extension [RFC3779] is present in the 118 end-entity (EE) certificate (contained within the ROA), and each 119 IP address prefix(es) in the ROA is contained within the set of IP 120 addresses specified by the EE certificate's IP address delegation 121 extension. 123 Is replaced with: 125 Either the IP Address Delegation extension described in [RFC3779] 126 or the alternative IP Address Delegation extension described in 127 [RFC8360] (but not both) is present in the end entity (EE) 128 certificate (contained within the ROA), and each IP address 129 prefix(es) in the ROA is contained within the VRS-IP set that is 130 specified as an outcome of EE certificate validation described in 131 Section 7.2 (as updated by this document) [RFC6487]. 133 Note that this ensures that ROAs can be valid only if all IP address 134 prefixes in the ROA are encompassed by the VRS-IP of all certificates 135 along the path to the trust anchor used to verify it. 137 Operators MAY issue separate ROAs for each IP address prefix, so that 138 the loss of one or more IP address prefixes from the VRS-IP of any 139 certificate along the path to the trust anchor would not invalidate 140 authorizations for other IP address prefixes. 142 4. Updates to RFC 6487 144 This section updates [RFC6487] to specify an improved behavior of a 145 Relying Party implementation. 147 4.1. Updates to Section 7.2 149 The following section replaces Section 7.2 [RFC6487] (Resource 150 Certification Path Validation) in its entirety. 152 Validation of signed resource data using a target resource 153 certificate consists of verifying that the digital signature of the 154 signed resource data is valid, using the public key of the target 155 resource certificate, and also validating the resource certificate in 156 the context of the RPKI, using the path validation process. 158 There are two inputs to the validation algortihm: 160 1. A trust anchor 162 2. A certificate to be validated 164 The algorithm is initialized with two new variables for use in the 165 RPKI: Verified Resource Set-IP (VRS-IP) and Verified Resource Set-AS 166 (VRS-AS). These sets are used to track the set of INRs (IP address 167 space and AS numbers) that are considered valid for each CA 168 certificate. The VRS-IP and VRS-AS sets are initially set to the IP 169 Address Delegation and AS Identifier Delegation values, respectively, 170 from the trust anchor used to perform validation. 172 This path validation algorithm verifies, among other things, that a 173 prospective certification path (a sequence of n certificates) 174 satisfies the following conditions: 176 a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is 177 the issuer of certificate ('x' + 1); 179 b. certificate '1' is issued by a trust anchor; 181 c. certificate 'n' is the certificate to be validated; and 183 d. for all 'x' in {1, ..., n}, certificate 'x' is valid. 185 Certificate validation requires verifying that all of the following 186 conditions hold, in addition to the certification path validation 187 criteria specified in Section 6 of [RFC5280]. 189 1. The signature of certificate x (x>1) is verified using the public 190 key of the issuer's certificate (x-1), using the signature 191 algorithm specified for that public key (in certificate x-1). 193 2. The current time lies within the interval defined by the 194 NotBefore and NotAfter values in the Validity field of 195 certificate x. 197 3. The Version, Issuer, and Subject fields of certificate x satisfy 198 the constraints established in Sections 4.1 to 4.7 of RFC 6487. 200 4. If certificate x uses the Certificate Policy defined in 201 Section 4.8.9 of [RFC6487], then the certificate MUST contain all 202 extensions defined in Section 4.8 of [RFC6487] that must be 203 present. The value(s) for each of these extensions MUST satisfy 204 the constraints established for each extension in the respective 205 sections. Any extension not thus identified MUST NOT appear in 206 certificate x. 208 5. If certificate x uses the Certificate Policy defined in 209 Section 4.2.4.1 [RFC8360], then all extensions defined in 210 Section 4.8 of [RFC6487], except Sections 4.8.9, 4.8.10, and 211 4.8.11 MUST be present. The certificate MUST contain an 212 extension as defined in Sections 4.2.4.2 or 4.2.4.3 [RFC8360], or 213 both. The value(s) for each of these extensions MUST satisfy the 214 constraints established for each extension in the respective 215 sections. Any extension not thus identified MUST NOT appear in 216 certificate x. 218 6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT 219 appear on a Certificate Revocation List (CRL) issued by the CA 220 represented by certificate x-1. 222 7. Compute the VRS-IP and VRS-AS set values as indicated below: 224 * If the IP Address Delegation extension is present in 225 certificate x and x=1, set the VRS-IP to the resources found 226 in this extension. 228 * If the IP Address Delegation extension is present in 229 certificate x and x>1, set the VRS-IP to the intersection of 230 the resources between this extension and the value of the VRS- 231 IP computed for certificate x-1. 233 * If the IP Address Delegation extension is absent in 234 certificate x, set the VRS-IP to NULL. 236 * If the IP Address Delegation extension is present in 237 certificate x and x=1, set the VRS-IP to the resources found 238 in this extension. 240 * If the AS Identifier Delegation extension is present in 241 certificate x and x>1, set the VRS-AS to the intersection of 242 the resources between this extension and the value of the VRS- 243 AS computed for certificate x-1. 245 * If the AS Identifier Delegation extension is absent in 246 certificate x, set the VRS-AS to NULL. 248 8. If there is any difference in resources in the VRS-IP and the IP 249 Address Delegation extension on certificate x, or the VRS-AS and 250 the AS Identifier Delegation extension on certificate x, then a 251 warning listing the overclaiming resources for certificate x 252 SHOULD be issued. 254 These rules allow a CA certificate to contain resources that are not 255 present in (all of) the certificates along the path from the trust 256 anchor to the CA certificate. If none of the resources in the CA 257 certificate are present in all certificates along the path, no 258 subordinate certificates could be valid. However, the certificate is 259 not immediately rejected as this may be a transient condition. Not 260 immediately rejecting the certificate does not result in a security 261 problem because the associated VRS sets accurately reflect the 262 resources validly associated with the certificate in question. 264 4.2. Updates to Section 9 266 Section 9 "Operational Considerations for Profile Agility" is 267 removed. 269 5. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 271 This section records the status of known implementations of the 272 protocol defined by this specification at the time of posting of this 273 Internet-Draft, and is based on a proposal described in RFC7942. The 274 description of implementations in this section is intended to assist 275 the IETF in its decision processes in progressing drafts to RFCs. 276 Please note that the listing of any individual implementation here 277 does not imply endorsement by the IETF. Furthermore, no effort has 278 been spent to verify the information presented here that was supplied 279 by IETF contributors. This is not intended as, and must not be 280 construed to be, a catalog of available implementations or their 281 features. Readers are advised to note that other implementations may 282 exist. 284 As of today these changesets have been produced for commonly used 285 Relying Party implementations: 287 * NLnet Labs Routinator [routinator] 289 * OpenBSD rpki-client [rpkiclient] 291 * FORT Validator [fort] 293 The 'public' OpenSSL X509v3_addr_validate_path() and 294 X509v3_asid_validate_path() interfaces do not read the Policy OIDs. 295 Also, these interfaces are not referenced outside OpenSSL itself: 296 [codesearch] and [github]. 298 At the time of writing there are zero (0) certificates in the RPKI 299 carrying the extensions and policy defined in [RFC8360]. 301 6. Security Considerations 303 The authors believe that the revised validation algortihm introduces 304 no new security vulnerabilities into the RPKI, because it cannot lead 305 to any ROA and/or router certificates to be accepted if they contain 306 resources that are not held by the issuer. 308 7. IANA Considerations 310 IANA is requested to reference this document in the "SMI Security for 311 PKIX Certificate Policies" registry at: 313 * id-cp-ipAddr-asNumber-v2 315 IANA is requested to reference this document in the "SMI Security for 316 PKIX Certificate Extensions" registry at: 318 * id-pe-ipAddrBlocks-v2 320 * id-pe-autonomousSysIds-v2 322 IANA is requested to reference this document in the "SMI Security for 323 PKIX Module Identifier" registry at: 325 * id-mod-ip-addr-and-as-ident-v2 327 * id-mod-ip-addr-and-as-ident-2v2 329 8. Acknowledgements 331 The authors would like to thank Tim Bruijnzeels, Mikael Abrahamsson, 332 Nick Hilliard, and Peter Peele for their helpful review of this 333 document. 335 9. References 337 9.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 345 Addresses and AS Identifiers", RFC 3779, 346 DOI 10.17487/RFC3779, June 2004, 347 . 349 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 350 Housley, R., and W. Polk, "Internet X.509 Public Key 351 Infrastructure Certificate and Certificate Revocation List 352 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 353 . 355 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 356 Origin Authorizations (ROAs)", RFC 6482, 357 DOI 10.17487/RFC6482, February 2012, 358 . 360 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 361 X.509 PKIX Resource Certificates", RFC 6487, 362 DOI 10.17487/RFC6487, February 2012, 363 . 365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 367 May 2017, . 369 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 370 Newton, A., and D. Shaw, "Resource Public Key 371 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 372 DOI 10.17487/RFC8360, April 2018, 373 . 375 9.2. Informative References 377 [codesearch] 378 Debian, "Debian Codesearch", February 2021, 379 . 382 [fort] Snijders, J., "Harmonize RFC 8360 and RFC 6487 in FORT", 383 February 2021, . 387 [github] Github, "Github Search", February 2021, 388 . 391 [Report] Snijders, J., "[routing-wg] RFC 8360 should be the default 392 (Was: RPKI Outage Post-Mortem)", January 2021, 393 . 396 [routinator] 397 Snijders, J., "Harmonize RFC 8360 and RFC 6487 in rpki- 398 rs", February 2021, . 401 [rpkiclient] 402 Jeker, C., "rpki-client check IP and ASnum coverage only 403 on ROAs", January 2021, 404 . 406 Authors' Addresses 408 Job Snijders 409 Fastly 410 Amsterdam 411 Netherlands 412 Email: job@fastly.com 414 Ben Maddison 415 Workonline 416 Cape-Town 417 South Africa 418 Email: benm@workonline.africa