idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-05.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 262: '...l the extensions that MUST be present,...' RFC 2119 keyword, line 264: '...these extensions MUST be satisfy the c...' RFC 2119 keyword, line 266: '...fied in Section 4.8 MUST NOT appear in...' RFC 2119 keyword, line 269: '.... Certificate x MUST NOT have been re...' RFC 2119 keyword, line 273: '... certificate MUST be "encompassed"...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2016) is 2855 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) == Unused Reference: 'RFC3849' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC5398' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-17 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: January 2, 2017 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 A. Aina 12 AFRINIC 13 July 1, 2016 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-05 18 Abstract 20 This document proposes an update to the certificate validation 21 procedure specified in RFC 6487 that reduces aspects of operational 22 fragility in the management of certificates in the RPKI, while 23 retaining essential security features. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Certificate Validation in the RPKI . . . . . . . . . . . . . 2 61 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 62 4. An Amended RPKI Certification Validation Process . . . . . . 4 63 4.1. Verified Resource Sets . . . . . . . . . . . . . . . . . 5 64 4.2. Changes to existing standards . . . . . . . . . . . . . . 5 65 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This document proposes an update to the certificate validation 77 procedure specified in [RFC6487] that reduces aspects of operational 78 fragility in the management of certificates in the RPKI, while 79 retaining essential security features. 81 2. Certificate Validation in the RPKI 83 As currently defined in section 7.2 of [RFC6487], validation of PKIX 84 certificates that conform to the RPKI profile relies on the use of a 85 path validation process where each certificate in the validation path 86 is required to meet the certificate validation criteria. 88 These criteria require, in particular, that the Internet Number 89 Resources (INRs) of each certificate in the validation path are 90 "encompassed" by INRs on the issuing certificate. The first 91 certificate in the path is required to be a trust anchor, and its 92 resources are considered valid by definition. 94 For example, in the following sequence: 96 Certificate 1 (trust anchor): 97 Issuer TA, 98 Subject TA, 99 Resources 192.0.2.0/24, 198.51.100.0/24, 100 2001:db8::/32, AS64496-AS64500 102 Certificate 2: 103 Issuer TA, 104 Subject CA1, 105 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 107 Certificate 3: 108 Issuer CA1, 109 Subject CA2, 110 Resources 192.0.2.0/24, 2001:db8::/32 112 ROA 1: 113 Embedded Certificate 4 (EE certificate): 114 Issuer CA2, 115 Subject R1, 116 Resources 192.0.2.0/24 118 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 120 All certificates in this scenario are considered valid since the INRs 121 of each certificate are encompassed by those of the issuing 122 certificate. ROA1 is valid because the specified prefix is 123 encompassed by the embedded EE certificate, as required by [RFC6482]. 125 3. Operational Considerations 127 The allocations recorded in the RPKI change as a result of resource 128 transfers. For example, the CAs involved in transfer might choose to 129 modify CA certificates in an order that causes some of these 130 certificates to "over-claim" temporarily. A certificate is said to 131 "over-claim" if it includes INRs not contained in the INRs of the CA 132 that issued the certificate in question. 134 It may also happen that a child CA does not voluntarily request a 135 shrunk resource certificate when resources are being transferred or 136 reclaimed by the parent. Furthermore operational errors that may 137 occur during management of RPKI databases also may create CA 138 certificates that, temporarily, no longer encompass all of the INRs 139 of subordinate certificates. 141 Consider the following sequence: 143 Certificate 1 (trust anchor): 144 Issuer TA, 145 Subject TA, 146 Resources 192.0.2.0/24, 198.51.100.0/24, 147 2001:db8::/32, AS64496-AS64500 149 Certificate 2: 150 Issuer TA, 151 Subject CA1, 152 Resources 192.0.2.0/24, 2001:db8::/32 154 Certificate 3 (invalid): 155 Issuer CA1, 156 Subject CA2, 157 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 159 ROA 1 (invalid): 160 Embedded Certificate 4 (EE certificate): 161 Issuer CA2, 162 Subject R1, 163 Resources 192.0.2.0/24 165 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 167 Here Certificate 2 from the previous example was re-issued by TA to 168 CA1 and the prefix 198.51.100.0/24 was removed. However, CA1 failed 169 to re-issue a new Certificate 3 to CA2. As a result Certificate 3 is 170 now over-claiming and considered invalid; by recursion the embedded 171 Certificate 4 used for ROA1 is also invalid. And ROA1 is invalid 172 because the specified prefix contained in the ROA is no longer 173 encompassed by a valid embedded EE certificate, as required by 174 [RFC6482] 176 However, it should be noted that ROA1 does not make use of any of the 177 address resources that were removed from CA1's certificate, and thus 178 it would be desirable if ROA1 could still be viewed as valid. 179 Technically CA1 should re-issue a Certificate 3 to CA2 without 180 198.51.100.0/24, and then ROA1 would be considered valid according to 181 [RFC6482]. But as long as CA1 does not take this action, ROA1 182 remains invalid. It would be preferable if ROA1 could be considered 183 valid, since the assertion it makes was not affected by the reduced 184 scope of CA1's certificate. 186 4. An Amended RPKI Certification Validation Process 187 4.1. Verified Resource Sets 189 The problem described above can be considered as a low probability 190 problem today. However the potential impact on routing security 191 would be high if an over-claiming occurred near the apex of the RPKI 192 hierarchy, as this would invalidate the entirety of the sub-tree 193 located below this point. 195 The changes proposed here to the validation procedure in [RFC6487] do 196 not change the probability of this problem, but they do limit the 197 impact to just the over-claimed resources. This revised validation 198 algorithm is intended to avoid causing CA certificates to be treated 199 as completely invalid as a result of over-claims. However, these 200 changes are designed to not degrade the security offered by the RPKI. 201 Specifically, ROAs and router certificates will be treated as valid 202 only if all of the resources contained in them are encompassed by all 203 superior certificates along a path to a trust anchor. 205 The way this is achieved conceptually is by maintaining Verified 206 Resource Set (VRS) for each certificate that is separate from the 207 INRs found in the [RFC3779] resource extension in the certificate. 209 4.2. Changes to existing standards 211 The following is an amended specification to be used in place of 212 section 7.2 of [RFC6487]. 214 The following algorithm is employed to validate CA and EE resources 215 certificates. It is modeled on the path validation algorithm from 216 [RFC5280], but modified to make use of the IP Address Delegation and 217 AS Identifier Delegation Extensions from [RFC3779]. 219 There are two inputs to the validation algorithm: 221 1. a trust anchor 223 2. a certificate to be validated 225 The algorithm is initialized with two new variables for use in the 226 RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set- 227 AS (VRS-AS). These sets are used to track the set of INRs (IP 228 address space and AS Numbers) that are considered valid for each CA 229 certificate. The VRS-IP and VRS-AS sets are initially set to the IP 230 Address Delegation and AS Identifier Delegation values, respectively, 231 from the trust anchor used to perform validation. 233 This path validation algorithm verifies, among other things, that a 234 prospective certification path (a sequence of n certificates) 235 satisfies the following conditions: 237 a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is 238 the issuer of certificate ('x' + 1); 240 b. certificate '1' is issued by a trust anchor; 242 c. certificate 'n' is the certificate to be validated; and 244 d. for all 'x' in {1, ..., n}, certificate 'x' is valid. 246 Certificate validation requires verifying that all of the following 247 conditions hold, in addition to the certification path validation 248 criteria specified in Section 6 of [RFC5280]. 250 1. The signature of certificate x (x>1) is verified using the public 251 key of the issuer's certificate (x-1), using the signature 252 algorithm specified for that public key (in certificate x-1). 254 2. The current time lies within the interval defined by the 255 NotBefore and NotAfter values in the Validity field of 256 certificate x. 258 3. The Version, Issuer, and Subject fields of certificate x satisfy 259 the constraints established in Section 4.1-4.7 of this 260 specification. 262 4. Certificate x contains all the extensions that MUST be present, 263 as defined in Section 4.8 of this specification. The value(s) 264 for each of these extensions MUST be satisfy the constraints 265 established for each extension in the respective sections. Any 266 extension not identified in Section 4.8 MUST NOT appear in 267 certificate x. 269 5. Certificate x MUST NOT have been revoked, i.e., it MUST NOT 270 appear on a CRL issued by the CA represented by certificate x-1 272 6. If certificate x is an EE certificate, then the INRs of this 273 certificate MUST be "encompassed" by the values of VRS-IP and 274 VRS-AS for certificate x-1. 276 7. If certificate x is a CA certificate, compute the VRS-IP and VRS- 277 AS set values as indicated below: 279 * If the IP Address Delegation extension is present in 280 certificate x, compute the intersection of the resources 281 between this extension and the value of the VRS-IP computed 282 for certificate x-1. 284 * If the IP Address Delegation extension is absent in 285 certificate x, set the VRS-IP to NULL. 287 * If the AS Identifier Delegation extension is present in 288 certificate x, compute the intersection of the resources 289 between this extension and the value of the VRS-AS computed 290 for certificate x-1 292 * If the AS Identifier Delegation extension is absent in 293 certificate x, set the VRS-AS to NULL. 295 * If x = n (i.e., this is the certificate being validated), 296 then: 298 1. If IP Address Delegation extension is present, it is 299 replaced with the intersection of the values from that 300 extension and the current value of the VRS-IP. 302 2. If an AS Identifier Delegation extension is present, it is 303 replaced with the intersection of the values from that 304 extension and the current value of the VRS-IP. 306 * If an RP is caching the results of validation, these values 307 MAY be stored along with the certificate, to facilitate 308 incremental validation based on cached results. 310 These rules allow a CA certificate to contain resources that are not 311 present in (all of) the certificates along the path from the trust 312 anchor to the CA certificate. If none of the resources in the CA 313 certificate are present in all certificates along the path, no 314 subordinate certificates could be valid. However, the certificate is 315 not immediately rejected as this may be a transient condition. Not 316 immediately rejecting the certificate does not result in a security 317 problem because the associated VRS sets accurately reflect the 318 resources validly associated with the certificate in question. 320 The INRs of an EE certificate being validated MUST always be 321 encompassed by all certificates along the path to the trust anchor 322 used to verify that certificate. The algorithm described above 323 ensures this. 325 Note that ROAs [RFC6482] and BGPSec router (EE) certificates 326 [I-D.ietf-sidr-bgpsec-pki-profiles] can contain multiple prefixes or 327 ASNs respectively, and an over-claim of any of these would result in 328 the ROA or BGPSec EE certificates being considered invalid. However, 329 operators MAY issue separate ROAs or BGPSec router certificates to 330 avoid this type of fate sharing. 332 4.3. An example 334 Consider the following example under the amended approach: 336 Certificate 1 (trust anchor): 337 Issuer TA, 338 Subject TA, 339 Resources 192.0.2.0/24, 198.51.100.0/24, 340 2001:db8::/32, AS64496-AS64500 342 Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24, 343 2001:db8::/32, AS64496-AS64500 344 Warnings: none 346 Certificate 2: 347 Issuer TA, 348 Subject CA1, 349 Resources 192.0.2.0/24, 2001:db8::/32, AS64496 351 Verified Resource Set: 192.0.2.0/24, 352 2001:db8::/32, AS64496 353 Warnings: none 355 Certificate 3: 356 Issuer CA1, 357 Subject CA2, 358 Resources 192.0.2.0/24, 198.51.100.0/24, AS64496 360 Verified Resource Set: 192.0.2.0/24, AS64496 361 Warnings: over-claim for 198.51.100.0/24 363 ROA 1 (valid): 364 Embedded Certificate 4 (EE certificate): 365 Issuer CA2, 366 Subject R1, 367 Resources 192.0.2.0/24 369 Verified resources: 192.0.2.0/24 370 Warnings: none 372 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 374 ROA1 is considered valid because the prefix matches the Verified 375 Resource Set on the embedded EE certificate, as required by 376 RFC 6482. 378 ROA 2 (invalid): 379 Embedded Certificate 5 (EE certificate invalid): 380 Issuer CA2, 381 Subject R2, 382 Resources 198.51.100.0/24 384 EE certificate is invalid due to over-claim for 198.51.100.0/24 386 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 388 ROA2 is considered invalid because he embedded EE certificate is 389 considered invalid. 391 BGPSec Certificate 1 (valid): 392 Issuer CA2 393 Subject ROUTER-64496 394 Resources AS64496 396 Verified resources: AS64496 397 Warnings: none 399 BGPSec Certificate 2 (invalid): 400 Issuer CA2 401 Subject ALL-ROUTERS 402 Resources AS64496-AS64497 404 EE certificate is invalid due to over-claim for AS64497 406 This problem can be mitigated by issuing separate certificates 407 for each AS number. 409 5. Security Considerations 411 The authors believe that the revised validation algorithm introduces 412 no new security vulnerabilities into the RPKI. 414 6. IANA Considerations 416 No updates to the registries are suggested by this document. 418 7. Acknowledgements 420 TBA. 422 8. References 424 8.1. Normative References 426 [I-D.ietf-sidr-bgpsec-pki-profiles] 427 Reynolds, M., Turner, S., and S. Kent, "A Profile for 428 BGPsec Router Certificates, Certificate Revocation Lists, 429 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 430 profiles-17 (work in progress), June 2016. 432 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 433 Addresses and AS Identifiers", RFC 3779, 434 DOI 10.17487/RFC3779, June 2004, 435 . 437 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 438 Housley, R., and W. Polk, "Internet X.509 Public Key 439 Infrastructure Certificate and Certificate Revocation List 440 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 441 . 443 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 444 Origin Authorizations (ROAs)", RFC 6482, 445 DOI 10.17487/RFC6482, February 2012, 446 . 448 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 449 X.509 PKIX Resource Certificates", RFC 6487, 450 DOI 10.17487/RFC6487, February 2012, 451 . 453 8.2. Informative References 455 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 456 Reserved for Documentation", RFC 3849, 457 DOI 10.17487/RFC3849, July 2004, 458 . 460 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 461 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 462 December 2008, . 464 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 465 Reserved for Documentation", RFC 5737, 466 DOI 10.17487/RFC5737, January 2010, 467 . 469 Authors' Addresses 471 Geoff Huston 472 Asia Pacific Network Information Centre 473 6 Cordelia St 474 South Brisbane, QLD 4101 475 Australia 477 Phone: +61 7 3858 3100 478 Email: gih@apnic.net 480 George Michaelson 481 Asia Pacific Network Information Centre 482 6 Cordelia St 483 South Brisbane, QLD 4101 484 Australia 486 Phone: +61 7 3858 3100 487 Email: ggm@apnic.net 489 Carlos M. Martinez 490 Latin American and Caribbean IP Address Regional Registry 491 Rambla Mexico 6125 492 Montevideo 11400 493 Uruguay 495 Phone: +598 2604 2222 496 Email: carlos@lacnic.net 498 Tim Bruijnzeels 499 RIPE Network Coordination Centre 500 Singel 258 501 Amsterdam 1016 AB 502 The Netherlands 504 Email: tim@ripe.net 506 Andrew Lee Newton 507 American Registry for Internet Numbers 508 3635 Concorde Parkway 509 Chantilly, VA 20151 510 USA 512 Email: andy@arin.net 513 Alain Aina 514 African Network Information Centre (AFRINIC) 515 11th Floor, Raffles Tower 516 Cybercity, Ebene 517 Mauritius 519 Phone: +230 403 51 00 520 Email: aalain@afrinic.net