idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-04.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 226: '...he Relying Party MUST keep a Verified ...' RFC 2119 keyword, line 248: '... certificate MUST be used. If any...' RFC 2119 keyword, line 250: '...ificate, a warning SHOULD be issued to...' RFC 2119 keyword, line 255: '... certificate MUST be considered in...' RFC 2119 keyword, line 284: '...ter Certificates MUST NOT include the ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3849' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC5398' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 433, 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: Informational APNIC 5 Expires: December 9, 2016 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 A. Aina 12 AFRINIC 13 June 7, 2016 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-04 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 December 9, 2016. 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 Set . . . . . . . . . . . . . . . . . . 4 64 4.2. Changes to existing standards . . . . . . . . . . . . . . 5 65 4.2.1. Resource Certificate Path Validation . . . . . . . . 5 66 4.2.2. ROA Validation . . . . . . . . . . . . . . . . . . . 6 67 4.2.3. BGPsec Router Certificate Validation . . . . . . . . 6 68 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document proposes an update to the certificate validation 80 procedure specified in [RFC6487] that reduces aspects of operational 81 fragility in the management of certificates in the RPKI, while 82 retaining essential security features. 84 2. Certificate Validation in the RPKI 86 As currently defined in section 7.2 of [RFC6487], validation of PKIX 87 certificates that conform to the RPKI profile relies on the use of a 88 path validation process where each certificate in the validation path 89 is required to meet the certificate validation criteria. 91 These criteria require in particular that the resources on each 92 certificate in the validation path are "encompassed" by the resources 93 on the issuing certificate. The first certificate in the path is 94 required to be a trust anchor, and its resources are considered valid 95 by definition. 97 For example, in the following sequence: 99 Certificate 1 (trust anchor): 100 Issuer TA, 101 Subject TA, 102 Resources 192.0.2.0/24, 198.51.100.0/24, 103 2001:db8::/32, AS64496-AS64500 105 Certificate 2: 106 Issuer TA, 107 Subject CA1, 108 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 110 Certificate 3: 111 Issuer CA1, 112 Subject CA2, 113 Resources 192.0.2.0/24, 2001:db8::/32 115 ROA 1: 116 Embedded Certificate 4 (EE certificate): 117 Issuer CA2, 118 Subject R1, 119 Resources 192.0.2.0/24 121 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 123 All certificates in this scenario are considered valid in that the 124 resources on each certificate are encompassed by the issuing 125 certificate. ROA1 is valid because the specified prefix is 126 encompassed by the embedded EE certificate, as required by [RFC6482]. 128 3. Operational Considerations 130 The allocations recorded in the RPKI change as a result of resource 131 transfers and some types of operational errors. For example, the CAs 132 involved in transfer might choose to modify CA certificates in an 133 order that causes some of these certificates to "over-claim" 134 temporarily. It may also happen that a child CA does not voluntarily 135 request a shrunk resource certificate when resources are being 136 transferred or reclaimed by the parent. Furthermore some types of 137 operational errors that may occur during management of RPKI databases 138 also may create CA certificates that, temporarily, no longer 139 encompass all of the resources in 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, and by recursion the 171 embedded Certificate 4 used for ROA1 is also invalid. And ROA1 is 172 invalid because the specified prefix is no longer encompassed by a 173 valid embedded EE certificate, as required by [RFC6482] 175 However, it should be noted that ROA1 does not make use of any of the 176 address resources that were removed from CA1's certificate, and thus 177 it would be desirable if ROA1 could still be viewed as valid. 178 Technically CA1 could re-issue a Certificate 3 to CA2 without 179 198.51.100.0/24, and then ROA1 would be considered valid according to 180 [RFC6482]. But as long as CA1 does not take this action, ROA1 181 remains invalid. It would be preferable if ROA1 could be considered 182 valid. 184 4. An Amended RPKI Certification Validation Process 186 4.1. Verified Resource Set 188 The problem described above can be considered as a low probability 189 problem today. However the potential impact on routing security 190 would be high if an overclaim occurred near the apex of the RPKI 191 hierarchy and would invalidate the entirety of the sub-tree located 192 below this point. 194 The changes proposed here to the validation procedure in [RFC6487] do 195 not change the probability of this problem, but limit the impact to 196 just the overclaimed resources. This approach is intended to avoid 197 causing CA certificates to be treated as completely invalid as a 198 result of overclaims. However, these changes are designed to not 199 degrade the security offered by the RPKI. Specifically, no ROAs or 200 router certificates will be treated as valid if they contain only 201 resources that are not encompassed by all superior certificates along 202 a path to a trust anchor. 204 The way this is achieved conceptually is by maintaining a set of 205 verified resources for each certificate that is separate from the set 206 of resources found in the [RFC3779] resource extension on a 207 certificate. 209 4.2. Changes to existing standards 211 4.2.1. Resource Certificate Path Validation 213 Step 6 of the Resource Certification Path Validation defined in 214 section 7.2 of [RFC6487] currently has the following on the 215 validation of resources contained in the [RFC3779] resource extension 216 of certificates: 218 o The resource extension data is "encompassed" by the resource 219 extension data contained in a valid certificate where this issuer 220 is the subject (the previous certificate in the context of the 221 ordered sequence defined by the certification path). 223 The following is an amended specification to be used in place of this 224 text. 226 o The Relying Party MUST keep a Verified Resource Set for the 227 certificate independent of the RFC3779 extension itself, that is 228 built up using the following approach: 230 * If the certificate under test is chosen as a Trust Anchor, then 231 the Verified Resource Set of this certificate is equal to the 232 RFC3779 resource extensions. 234 * If the certificate under test not chosen as a Trust Anchor, the 235 Verified Resource Set is found by comparing this certificate to 236 its parent certificate (the previous certificate in the context 237 of the ordered sequence defined by the certification path) in 238 the following way: 240 + For any of the resource extensions that use the "inherit" 241 element as described in sections 2.2.3.5 and 3.2.3.3 of RFC 242 3779, the corresponding resources of this type should be 243 taken from the parent certificate. 245 + For resource extensions that do no use the "inherit" 246 element, the intersection of the resources on this 247 certificate and the Verified Resource Set of the parent 248 certificate MUST be used. If any resources on this 249 certificate are not encompassed by the Verified Resource Set 250 of the parent certificate, a warning SHOULD be issued to 251 help operators rectify this situation. 253 + If the Verified Resource Set obtained this way is empty for 254 all resource classes (IPv4, IPv6 and AS), then the 255 certificate MUST be considered invalid. 257 4.2.2. ROA Validation 259 Section 4 of [RFC6482] currently has the following text on the 260 validation of resources on a ROA: 262 o The IP address delegation extension [RFC3779] is present in the 263 end-entity (EE) certificate (contained within the ROA), and each 264 IP address prefix(es) in the ROA is contained within the set of IP 265 addresses specified by the EE certificate's IP address delegation 266 extension. 268 The following is an amended specification to be used in place of this 269 text. 271 o The Verified Resource Set of the end-entity (EE) certificate 272 (contained within the ROA), contains each IP address prefix(es) in 273 the ROA. 275 4.2.3. BGPsec Router Certificate Validation 277 BGPsec Router Certificate Validation is defined in section 3.3 of 278 [I-D.ietf-sidr-bgpsec-pki-profiles]. Path validation defined section 279 7 of [RFC6487] is used as the first step in validation, and a number 280 of additional constraints are applied. 282 We propose that the text of the following two additions: 284 o BGPsec Router Certificates MUST NOT include the IP Resource 285 extension. 287 o BGPsec Router Certificates MUST include the AS Resource Identifier 288 Delegation extension. 290 Is updated to the following: 292 o The Validated Resource Set of BGPsec Router Certificates MUST NOT 293 include IP Resources. 295 o BGPsec Router Certificates MUST include the AS Resource Identifier 296 Delegation extension and all AS resources included on this MUST be 297 encompassed by the Validated Resource Set of the BGPsec Router 298 Certificates. 300 4.3. An example 302 Consider the following example under the amended approach: 304 Certificate 1 (trust anchor): 305 Issuer TA, 306 Subject TA, 307 Resources 192.0.2.0/24, 198.51.100.0/24, 308 2001:db8::/32, AS64496-AS64500 310 Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24, 311 2001:db8::/32, AS64496-AS64500 312 Warnings: none 314 Certificate 2: 315 Issuer TA, 316 Subject CA1, 317 Resources 192.0.2.0/24, 2001:db8::/32, AS64496 319 Verified Resource Set: 192.0.2.0/24, 320 2001:db8::/32, AS64496 321 Warnings: none 323 Certificate 3: 324 Issuer CA1, 325 Subject CA2, 326 Resources 192.0.2.0/24, 198.51.100.0/24, AS64496 328 Verified Resource Set: 192.0.2.0/24, AS64496 329 Warnings: overclaim for 198.51.100.0/24 331 ROA 1 (valid): 332 Embedded Certificate 4 (EE certificate): 333 Issuer CA2, 334 Subject R1, 335 Resources 192.0.2.0/24 337 Verified resources: 192.0.2.0/24 338 Warnings: none 340 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 342 ROA1 is considered valid because the prefix matches the Verified 343 Resource Set on the embedded EE certificate, as required by 344 RFC 6482. 346 ROA 2 (invalid): 347 Embedded Certificate 5 (EE certificate): 348 Issuer CA2, 349 Subject R2, 350 Resources 198.51.100.0/24 352 Verified resources: none 353 Warnings: overclaim for 198.51.100.0/24 355 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 357 ROA2 is considered invalid because the prefix does not match the 358 Verified Resource Set on the embedded EE certificate. The amended 359 approach therefore cannot lead to ROAs showing up as valid for 360 resources that are not verified on the full path from the Trust 361 Anchor down to the ROA. 363 BGPSec Certificate 1 (valid): 364 Issuer CA2 365 Subject ROUTER-64496 366 Resources AS64496 368 Verified resources: AS64496 369 Warnings: none 371 BGPSec Certificate 2 (invalid): 372 Issuer CA2 373 Subject ALL-ROUTERS 374 Resources AS64496-AS64497 376 Verified resources: AS64496 377 Warnings: overclaim for AS64497 379 BGPSec Certificate 2 is considered invalid because not ALL 380 resources are part of the Verified Resource Set of this 381 certificate. This problem can be mitigated by issuing separate 382 certificates for each AS number. 384 5. Security Considerations 386 As far as the authors can see there are no real new problems 387 introduced by this approach. 389 6. IANA Considerations 391 No updates to the registries are suggested by this document. 393 7. Acknowledgements 395 TBA. 397 8. References 399 8.1. Normative References 401 [I-D.ietf-sidr-bgpsec-pki-profiles] 402 Reynolds, M. and S. Kent, "A Profile for BGPsec Router 403 Certificates, Certificate Revocation Lists, and 404 Certification Requests", draft-ietf-sidr-bgpsec-pki- 405 profiles-17 (work in progress), June 2016. 407 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 408 Addresses and AS Identifiers", RFC 3779, 409 DOI 10.17487/RFC3779, June 2004, 410 . 412 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 413 Origin Authorizations (ROAs)", RFC 6482, 414 DOI 10.17487/RFC6482, February 2012, 415 . 417 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 418 X.509 PKIX Resource Certificates", RFC 6487, 419 DOI 10.17487/RFC6487, February 2012, 420 . 422 8.2. Informative References 424 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 425 Reserved for Documentation", RFC 3849, 426 DOI 10.17487/RFC3849, July 2004, 427 . 429 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 430 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 431 December 2008, . 433 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 434 Reserved for Documentation", RFC 5737, 435 DOI 10.17487/RFC5737, January 2010, 436 . 438 Authors' Addresses 440 Geoff Huston 441 Asia Pacific Network Information Centre 442 6 Cordelia St 443 South Brisbane, QLD 4101 444 Australia 446 Phone: +61 7 3858 3100 447 Email: gih@apnic.net 449 George Michaelson 450 Asia Pacific Network Information Centre 451 6 Cordelia St 452 South Brisbane, QLD 4101 453 Australia 455 Phone: +61 7 3858 3100 456 Email: ggm@apnic.net 458 Carlos M. Martinez 459 Latin American and Caribbean IP Address Regional Registry 460 Rambla Mexico 6125 461 Montevideo 11400 462 Uruguay 464 Phone: +598 2604 2222 465 Email: carlos@lacnic.net 467 Tim Bruijnzeels 468 RIPE Network Coordination Centre 469 Singel 258 470 Amsterdam 1016 AB 471 The Netherlands 473 Email: tim@ripe.net 474 Andrew Lee Newton 475 American Registry for Internet Numbers 476 3635 Concorde Parkway 477 Chantilly, VA 20151 478 USA 480 Email: andy@arin.net 482 Alain Aina 483 African Network Information Centre (AFRINIC) 484 11th Floor, Raffles Tower 485 Cybercity, Ebene 486 Mauritius 488 Phone: +230 403 51 00 489 Email: aalain@afrinic.net