idnits 2.17.1 draft-spaghetti-sidrops-rpki-validation-update-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 : ---------------------------------------------------------------------------- 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 (February 22, 2021) is 1160 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 February 22, 2021 7 Expires: August 26, 2021 9 RPKI Validation Re-reconsidered 10 draft-spaghetti-sidrops-rpki-validation-update-00 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 August 26, 2021. 36 Copyright Notice 38 Copyright (c) 2021 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 2. Deprecation of RFC 8360 . . . . . . . . . . . . . . . . . . . 2 56 3. Updates to RFC 6482 . . . . . . . . . . . . . . . . . . . . . 3 57 4. Updates to RFC 6487 . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Updates to Section 7.2 . . . . . . . . . . . . . . . . . 4 59 4.2. Updates to Section 9 . . . . . . . . . . . . . . . . . . 6 60 5. Implementation status - RFC EDITOR: REMOVE BEFORE 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 . . . . . . . . . . . . . . . . . 9 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 o id-cp-ipAddr-asNumber-v2 - Section 4.2.1 [RFC8360] 98 o id-pe-ipAddrBlocks-v2 - Sections 4.2.2.1 and 4.2.2.2 [RFC8360] 100 o id-pe-autonomousSysIds-v2 - Sections 4.2.2.3 and 4.2.2.4 [RFC8360] 102 The stated purpose of the above OIDs is rendered obsolete by the 103 updated specifications contained in this document. 105 Therefore: 107 o Issuing CAs MUST NOT include the above OIDs in newly issued 108 Resource Certificates; and 110 o Relying parties encountering the above OIDs in Resource 111 Certificates MUST proceed according to the updated procedures 112 described below. 114 3. Updates to RFC 6482 116 This section updates Section 4 [RFC6482]. The following text: 118 The IP address delegation extension [RFC3779] is present in the 119 end-entity (EE) certificate (contained within the ROA), and each 120 IP address prefix(es) in the ROA is contained within the set of IP 121 addresses specified by the EE certificate's IP address delegation 122 extension. 124 Is replaced with: 126 Either the IP Address Delegation extension described in [RFC3779] 127 or the alternative IP Address Delegation extension described in 128 [RFC8360] (but not both) is present in the end entity (EE) 129 certificate (contained within the ROA), and each IP address 130 prefix(es) in the ROA is contained within the VRS-IP set that is 131 specified as an outcome of EE certificate validation described in 132 Section 7.2 (as updated by this document) [RFC6487]. 134 Note that this ensures that ROAs can be valid only if all IP address 135 prefixes in the ROA are encompassed by the VRS-IP of all certificates 136 along the path to the trust anchor used to verify it. 138 Operators MAY issue separate ROAs for each IP address prefix, so that 139 the loss of one or more IP address prefixes from the VRS-IP of any 140 certificate along the path to the trust anchor would not invalidate 141 authorizations for other IP address prefixes. 143 4. Updates to RFC 6487 145 This section updates [RFC6487] to specify an improved behavior of a 146 Relying Party implementation. 148 4.1. Updates to Section 7.2 150 The following section replaces Section 7.2 [RFC6487] (Resource 151 Certification Path Validation) in its entirety. 153 Validation of signed resource data using a target resource 154 certificate consists of verying that the digital signature of the 155 signed resource data is valid, using the public key of the target 156 resource certificate, and also validating the resource certificate in 157 the context of the RPKI, using the path validation process. 159 There are two inputs to the validation algortihm: 161 1. A trust anchor 163 2. A certificate to be validated 165 The algorithm is initialized with two new variables for use in the 166 RPKI: Verified Resource Set-IP (VRS-IP) and Verified Resource Set-AS 167 (VRS-AS). These sets are used to track the set of INRs (IP address 168 space and AS numbers) that are considered valid for each CA 169 certificate. The VRS-IP and VRS-AS sets are initially set to the IP 170 Address Delegation and AS Identifier Delegation values, respectively, 171 from the trust anchor used to perform validation. 173 This path validation algorithm verifies, among other things, that a 174 prospective certification path (a sequence of n certificates) 175 satisfies the following conditions: 177 a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is 178 the issuer of certificate ('x' + 1); 180 b. certificate '1' is issued by a trust anchor; 182 c. certificate 'n' is the certificate to be validated; and 184 d. for all 'x' in {1, ..., n}, certificate 'x' is valid. 186 Certificate validation requires verifying that all of the following 187 conditions hold, in addition to the certification path validation 188 criteria specified in Section 6 of [RFC5280]. 190 1. The signature of certificate x (x>1) is verified using the public 191 key of the issuer's certificate (x-1), using the signature 192 algorithm specified for that public key (in certificate x-1). 194 2. The current time lies within the interval defined by the 195 NotBefore and NotAfter values in the Validity field of 196 certificate x. 198 3. The Version, Issuer, and Subject fields of certificate x satisfy 199 the constraints established in Sections 4.1 to 4.7 of RFC 6487. 201 4. If certificate x uses the Certificate Policy defined in 202 Section 4.8.9 of [RFC6487], then the certificate MUST contain all 203 extensions defined in Section 4.8 of [RFC6487] that must be 204 present. The value(s) for each of these extensions MUST satisfy 205 the constraints established for each extension in the respective 206 sections. Any extension not thus identified MUST NOT appear in 207 certificate x. 209 5. If certificate x uses the Certificate Policy defined in 210 Section 4.2.4.1 [RFC8360], then all extensions defined in 211 Section 4.8 of [RFC6487], except Sections 4.8.9, 4.8.10, and 212 4.8.11 MUST be present. The certificate MUST contain an 213 extension as defined in Sections 4.2.4.2 or 4.2.4.3 [RFC8360], or 214 both. The value(s) for each of these extensions MUST satisfy the 215 constraints established for each extension in the respective 216 sections. Any extension not thus identified MUST NOT appear in 217 certificate x. 219 6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT 220 appear on a Certificate Revocation List (CRL) issued by the CA 221 represented by certificate x-1. 223 7. Compute the VRS-IP and VRS-AS set values as indicated below: 225 If the IP Address Delegation extension is present in 226 certificate x and x=1, set the VRS-IP to the resources found 227 in this extension. 229 If the IP Address Delegation extension is present in 230 certificate x and x>1, set the VRS-IP to the intersection of 231 the resources between this extension and the value of the VRS- 232 IP computed for certificate x-1. 234 If the IP Address Delegation extension is absent in 235 certificate x, set the VRS-IP to NULL. 237 If the IP Address Delegation extension is present in 238 certificate x and x=1, set the VRS-IP to the resources found 239 in this extension. 241 If the AS Identifier Delegation extension is present in 242 certificate x and x>1, set the VRS-AS to the intersection of 243 the resources between this extension and the value of the VRS- 244 AS computed for certificate x-1. 246 If the AS Identifier Delegation extension is absent in 247 certificate x, set the VRS-AS to NULL. 249 8. If there is any difference in resources in the VRS-IP and the IP 250 Address Delegation extension on certificate x, or the VRS-AS and 251 the AS Identifier Delegation extension on certificate x, then a 252 warning listing the overclaiming resources for certificate x 253 SHOULD be issued. 255 These rules allow a CA certificate to contain resources that are not 256 present in (all of) the certificates along the path from the trust 257 anchor to the CA certificate. If none of the resources in the CA 258 certificate are present in all certificates along the path, no 259 subordinate certificates could be valid. However, the certificate is 260 not immediately rejected as this may be a transient condition. Not 261 immediately rejecting the certificate does not result in a security 262 problem because the associated VRS sets accurately reflect the 263 resources validly associated with the certificate in question. 265 4.2. Updates to Section 9 267 Section 9 "Operational Considerations for Profile Agility" is 268 removed. 270 5. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 272 This section records the status of known implementations of the 273 protocol defined by this specification at the time of posting of this 274 Internet-Draft, and is based on a proposal described in RFC7942. The 275 description of implementations in this section is intended to assist 276 the IETF in its decision processes in progressing drafts to RFCs. 277 Please note that the listing of any individual implementation here 278 does not imply endorsement by the IETF. Furthermore, no effort has 279 been spent to verify the information presented here that was supplied 280 by IETF contributors. This is not intended as, and must not be 281 construed to be, a catalog of available implementations or their 282 features. Readers are advised to note that other implementations may 283 exist. 285 As of today these changesets have been produced for commonly used 286 Relying Party implementations: 288 NLnet Labs Routinator [routinator] 290 OpenBSD rpki-client [rpkiclient] 292 FORT Validator [fort] 294 The 'public' OpenSSL X509v3_addr_validate_path() and 295 X509v3_asid_validate_path() interfaces do not read the Policy OIDs. 296 Also, these interfaces are not referenced outside OpenSSL itself: 297 [codesearch] and [github]. 299 At the time of writing there are zero (0) certificates in the RPKI 300 carrying the extensions and policy defined in [RFC8360]. 302 6. Security Considerations 304 The authors believe that the revised validation algortihm introduces 305 no new security vulnerabilities into the RPKI, because it cannot lead 306 to any ROA and/or router certificates to be accepted if they contain 307 resources that are not held by the issuer. 309 7. IANA Considerations 311 IANA is requested to reference this document in the "SMI Security for 312 PKIX Certificate Policies" registry at: 314 id-cp-ipAddr-asNumber-v2 316 IANA is requested to reference this document in the "SMI Security for 317 PKIX Certificate Extensions" registry at: 319 id-pe-ipAddrBlocks-v2 321 id-pe-autonomousSysIds-v2 323 IANA is requested to reference this document in the "SMI Security for 324 PKIX Module Identifier" registry at: 326 id-mod-ip-addr-and-as-ident-v2 328 id-mod-ip-addr-and-as-ident-2v2 330 8. Acknowledgements 332 The authors would like to thank Tim Bruijnzeels, Mikael Abrahamsson, 333 and Nick Hilliard for their helpful review of this 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 413 Email: job@fastly.com 415 Ben Maddison 416 Workonline 417 Cape-Town 418 South Africa 420 Email: benm@workonline.africa