idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-10.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2017) is 2317 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) -- Looks like a reference, but probably isn't: '0' on line 351 -- Looks like a reference, but probably isn't: '1' on line 352 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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: June 24, 2018 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 D. Shaw 12 AFRINIC 13 December 21, 2017 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-10 18 Abstract 20 This document specifies an alternative 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 Where the procedure specified in RFC 6487 requires that Resource 26 Certificates are rejecting entirely if they are found to over-claim 27 any resources not contained on the issuing certificate, the 28 validation process defined here allows an issuing Certificate 29 Authority to chose to communicate that such Resource Certificates 30 should be accepted for the intersection of their resources and the 31 issuing certificate. 33 It should be noted that the validation process defined here considers 34 validation under a single Trust Anchor only. In particular, concerns 35 regarding over-claims where multiple configured Trust Anchors claim 36 overlapping resources are considered out of scope for this document. 38 This choice is signalled by form of a set of alternative Object 39 Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and 40 AS Identifiers, and certificate policy for the Resource Public Key 41 Infrastructure (RFC 6484). It should be noted that in case these 42 OIDs are not used for any certificate under a Trust Anchor, the 43 validation procedure defined here has the same outcome as the 44 procedure defined in RFC 6487 46 Furthermore this document provides an alternative to ROA (RFC 6482), 47 and BGPSec Router Certificate (BGPSec PKI Profiles - publication 48 requested) validation. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on June 24, 2018. 67 Copyright Notice 69 Copyright (c) 2017 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (https://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 85 2. Certificate Validation in the RPKI . . . . . . . . . . . . . 3 86 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 87 4. An Amended RPKI Certification Validation Process . . . . . . 5 88 4.1. Verified Resource Sets . . . . . . . . . . . . . . . . . 6 89 4.2. Differences with existing standards . . . . . . . . . . . 6 90 4.2.1. Certificate Policy (CP) for use with validation 91 reconsidered in the Resource PKI (RPKI) . . . . . . . 6 92 4.2.2. An alternative to RFC3779 X.509 Extensions for IP 93 Addresses and AS Identifiers . . . . . . . . . . . . 7 94 4.2.3. Addendum to RFC6268 . . . . . . . . . . . . . . . . . 11 95 4.2.4. An alternative to RFC6487 Profile for X.509 PKIX 96 Resource Certificates . . . . . . . . . . . . . . . . 13 97 4.2.5. An alternative ROA validation RFC6482 . . . . . . . . 16 98 4.2.6. An alternative to BGPSec Router Certificate 99 Validation . . . . . . . . . . . . . . . . . . . . . 17 100 5. Validation examples . . . . . . . . . . . . . . . . . . . . . 17 101 5.1. Example 1 - An RPKI tree using the old OIDs only . . . . 18 102 5.2. Example 2 - An RPKI tree using the new OIDs only . . . . 19 103 5.3. Example 3 - An RPKI tree using a mix of old and new OIDs 21 104 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 110 10.2. Informative References . . . . . . . . . . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Requirements notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Certificate Validation in the RPKI 121 As currently defined in section 7.2 of [RFC6487], validation of PKIX 122 certificates that conform to the RPKI profile relies on the use of a 123 path validation process where each certificate in the validation path 124 is required to meet the certificate validation criteria. 126 These criteria require, in particular, that the Internet Number 127 Resources (INRs) of each certificate in the validation path are 128 "encompassed" by INRs on the issuing certificate. The first 129 certificate in the path is required to be a trust anchor, and its 130 resources are considered valid by definition. 132 For example, in the following sequence: 134 Certificate 1 (trust anchor): 135 Issuer TA, 136 Subject TA, 137 Resources 192.0.2.0/24, 198.51.100.0/24, 138 2001:db8::/32, AS64496-AS64500 140 Certificate 2: 141 Issuer TA, 142 Subject CA1, 143 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 145 Certificate 3: 146 Issuer CA1, 147 Subject CA2, 148 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 150 ROA 1: 151 Embedded Certificate 4 (EE certificate): 152 Issuer CA2, 153 Subject R1, 154 Resources 192.0.2.0/24 156 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 158 All certificates in this scenario are considered valid since the INRs 159 of each certificate are encompassed by those of the issuing 160 certificate. ROA1 is valid because the specified prefix is 161 encompassed by the embedded EE certificate, as required by [RFC6482]. 163 3. Operational Considerations 165 The allocations recorded in the RPKI change as a result of resource 166 transfers. For example, the CAs involved in transfer might choose to 167 modify CA certificates in an order that causes some of these 168 certificates to "over-claim" temporarily. A certificate is said to 169 "over-claim" if it includes INRs not contained in the INRs of the CA 170 that issued the certificate in question. 172 It may also happen that a child CA does not voluntarily request a 173 shrunk resource certificate when resources are being transferred or 174 reclaimed by the parent. Furthermore operational errors that may 175 occur during management of RPKI databases also may create CA 176 certificates that, temporarily, no longer encompass all of the INRs 177 of subordinate certificates. 179 Consider the following sequence: 181 Certificate 1 (trust anchor): 182 Issuer TA, 183 Subject TA, 184 Resources 192.0.2.0/24, 198.51.100.0/24, 185 2001:db8::/32, AS64496-AS64500 187 Certificate 2: 188 Issuer TA, 189 Subject CA1, 190 Resources 192.0.2.0/24, 2001:db8::/32 192 Certificate 3 (invalid): 193 Issuer CA1, 194 Subject CA2, 195 Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32 197 ROA 1 (invalid): 198 Embedded Certificate 4 (EE certificate, invalid): 199 Issuer CA2, 200 Subject R1, 201 Resources 192.0.2.0/24 203 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 205 Here Certificate 2 from the previous example was re-issued by TA to 206 CA1 and the prefix 198.51.100.0/24 was removed. However, CA1 failed 207 to re-issue a new Certificate 3 to CA2. As a result Certificate 3 is 208 now over-claiming and considered invalid; by recursion the embedded 209 Certificate 4 used for ROA1 is also invalid. And ROA1 is invalid 210 because the specified prefix contained in the ROA is no longer 211 encompassed by a valid embedded EE certificate, as required by 212 [RFC6482] 214 However, it should be noted that ROA1 does not make use of any of the 215 address resources that were removed from CA1's certificate, and thus 216 it would be desirable if ROA1 could still be viewed as valid. 217 Technically CA1 should re-issue a Certificate 3 to CA2 without 218 198.51.100.0/24, and then ROA1 would be considered valid according to 219 [RFC6482]. But as long as CA1 does not take this action, ROA1 220 remains invalid. It would be preferable if ROA1 could be considered 221 valid, since the assertion it makes was not affected by the reduced 222 scope of CA1's certificate. 224 4. An Amended RPKI Certification Validation Process 225 4.1. Verified Resource Sets 227 The problem described above can be considered as a low probability 228 problem today. However the potential impact on routing security 229 would be high if an over-claiming occurred near the apex of the RPKI 230 hierarchy, as this would invalidate the entirety of the sub-tree 231 located below this point. 233 The changes specified here to the validation procedure in [RFC6487] 234 do not change the probability of this problem, but they do limit the 235 impact to just the over-claimed resources. This revised validation 236 algorithm is intended to avoid causing CA certificates to be treated 237 as completely invalid as a result of over-claims. However, these 238 changes are designed to not degrade the security offered by the RPKI. 239 Specifically, ROAs and router certificates will be treated as valid 240 only if all of the resources contained in them are encompassed by all 241 superior certificates along a path to a trust anchor. 243 The way this is achieved conceptually is by maintaining a Verified 244 Resource Set (VRS) for each certificate that is separate from the 245 INRs found in the [RFC3779] resource extension in the certificate. 247 4.2. Differences with existing standards 249 4.2.1. Certificate Policy (CP) for use with validation reconsidered in 250 the Resource PKI (RPKI) 252 Note that section 1.2 of [RFC6484] defines the "Certificate Policy 253 (CP) for the Resource PKI (RPKI)" with the following OID: 255 id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1) 256 identified-organization(3) dod(6) internet(1) 257 security(5) mechanisms(5) pkix(7) cp(14) 2 } 259 This document requests an assignment of a new OID for an alternative 260 "Certificate Policy (CP) for use with validation reconsidered in the 261 Resource PKI (RPKI)" as follows: 263 id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1) 264 identified-organization(3) dod(6) internet(1) 265 security(5) mechanisms(5) pkix(7) cp(14) TBD1 } 267 This alternative Certificate Policy is the same as the Certificate 268 Policy described in [RFC6484], except that it is used to drive the 269 decision in step 8 of the validation procedure described in 270 Section 4.2.4.4. 272 4.2.2. An alternative to RFC3779 X.509 Extensions for IP Addresses and 273 AS Identifiers 275 This document defines an alternative to [RFC3779]. All 276 specifications and procedures described in [RFC3779] apply, with the 277 following notable exceptions. 279 4.2.2.1. OID for id-pe-ipAddrBlocks-v2 281 This document request an OID for the extension id-pe-ipAddrBlocks-v2 282 (id-pe TBD2). This OID MUST only be used in conjunction with the 283 alternative Certificate Policy OID defined in Section 4.2.1. 285 The following is an amended specification to be used as an 286 alternative to the specification in section 2.2.1 of [RFC3779]. 288 The OID for this extension is id-pe-ipAddrBlocks-v2. 290 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 292 where [RFC5280] defines: 294 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 295 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 297 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 299 4.2.2.2. Syntax for id-pe-ipAddrBlocks-v2 300 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 302 IPAddrBlocks ::= SEQUENCE OF IPAddressFamily 304 IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- 305 addressFamily OCTET STRING (SIZE (2..3)), 306 ipAddressChoice IPAddressChoice } 308 IPAddressChoice ::= CHOICE { 309 inherit NULL, -- inherit from issuer -- 310 addressesOrRanges SEQUENCE OF IPAddressOrRange } 312 IPAddressOrRange ::= CHOICE { 313 addressPrefix IPAddress, 314 addressRange IPAddressRange } 316 IPAddressRange ::= SEQUENCE { 317 min IPAddress, 318 max IPAddress } 320 IPAddress ::= BIT STRING 322 Note that the descriptions of objects referenced in the syntax above 323 are defined in sections 2.2.3.1 through 2.2.3.9 of [RFC3779]. 325 4.2.2.3. OID for id-pe-autonomousSysIds-v2 327 This document request an OID for the extension id-pe- 328 autonomousSysIds-v2 ( id-pe TBD3). This OID MUST only be used in 329 conjunction with the alternative Certificate Policy OID defined in 330 Section 4.2.1. 332 The following is an amended specification to be used as an 333 alternative to the specification in section 3.2.1 of [RFC3779]. 335 The OID for this extension is id-pe-autonomousSysIds-v2. 337 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 339 where [RFC5280] defines: 341 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 342 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 344 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 346 4.2.2.4. Syntax for id-pe-autonomousSysIds-v2 348 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 350 ASIdentifiers ::= SEQUENCE { 351 asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL, 352 rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL} 354 ASIdentifierChoice ::= CHOICE { 355 inherit NULL, -- inherit from issuer -- 356 asIdsOrRanges SEQUENCE OF ASIdOrRange } 358 ASIdOrRange ::= CHOICE { 359 id ASId, 360 range ASRange } 362 ASRange ::= SEQUENCE { 363 min ASId, 364 max ASId } 366 ASId ::= INTEGER 368 4.2.2.5. Amended IP Address Delegation Extension Certification Path 369 Validation 371 Certificate path validation is performed as specified in 372 Section 4.2.4.4. 374 4.2.2.6. Amended Autonomous System Identifier Delegation Extension 375 Certification Path Validation 377 Certificate path validation is performed as specified in 378 Section 4.2.4.4. 380 4.2.2.7. Amended ASN.1 module 382 This document requests an OID for id-mod-ip-addr-and-as-ident-v2, as 383 follows: 385 IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) 386 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 387 id-mod-ip-addr-and-as-ident-v2(TBD4) } 389 The following is an amended specification to be used as an 390 alternative to the specification in section appendix A of [RFC3779]. 392 This normative appendix describes the IP address and AS identifiers 393 extensions used by conforming PKI components in ASN.1 syntax. 395 IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) 396 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 397 id-mod-ip-addr-and-as-ident-v2(TBD4) } 399 DEFINITIONS EXPLICIT TAGS ::= 401 BEGIN 403 -- EXPORTS ALL -- 405 IMPORTS 407 -- PKIX specific OIDs and arcs -- 409 id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) 410 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 411 id-mod(0) id-pkix1-explicit(18) } 413 -- IP Address Block and AS Identifiers Syntax -- 415 IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) 416 identified-organization(3) dod(6) internet(1) security(5) 417 mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } 418 ; 420 -- Validation Reconsidered IP Address Delegation Extension OID -- 422 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 424 -- Validation Reconsidered IP Address Delegation Extension Syntax -- 425 -- Syntax is imported from [RFC3779] -- 427 -- Validation Reconsidered Autonomous System Identifier -- 428 -- Delegation Extension OID -- 430 id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD3 } 432 -- Validation Reconsidered Autonomous System Identifier -- 433 -- Delegation Extension Syntax -- 435 -- Syntax is imported from [RFC3779] -- 437 END 439 4.2.3. Addendum to RFC6268 441 This document requests an OID for id-mod-ip-addr-and-as-ident-2v2 as 442 follows: 444 IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) 445 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 446 id-mod-ip-addr-and-as-ident-2v2(TBD5) } 448 [RFC6268] is an informational RFC that updates some auxiliary ASN.1 449 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 450 modules in Section 4.2.2.7 remain the normative version. 452 The following is an additional module confirming to the 2008 version 453 of ASN.1 to be used with the extensions defined in Section 4.2.2.1 454 and Section 4.2.2.3. 456 IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) 457 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 458 id-mod-ip-addr-and-as-ident-2v2(TBD5) } 460 DEFINITIONS EXPLICIT TAGS ::= 462 BEGIN 464 EXPORTS ALL; 465 IMPORTS 467 -- PKIX specific OIDs and arcs -- 469 id-pe 470 FROM PKIX1Explicit-2009 471 { iso(1) identified-organization(3) dod(6) internet(1) 472 security(5) mechanisms(5) pkix(7) id-mod(0) 473 id-mod-pkix1-explicit-02(51)} 475 EXTENSION 476 FROM PKIX-CommonTypes-2009 477 { iso(1) identified-organization(3) dod(6) internet(1) 478 security(5) mechanisms(5) pkix(7) id-mod(0) 479 id-mod-pkixCommon-02(57)} 481 -- IP Address Block and AS Identifiers Syntax -- 483 IPAddrBlocks, ASIdentifiers 484 FROM IPAddrAndASCertExtn-2010 485 { iso(1) identified-organization(3) dod(6) 486 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 487 id-mod-ip-addr-and-as-ident-2(72) } 488 ; 490 -- 491 -- Extensions contains the set of extensions defined in this 492 -- module 493 -- 494 -- These are intended to be placed in public key certificates 495 -- and thus should be added to the CertExtensions extension 496 -- set in PKIXImplicit-2009 defined for [RFC5280] 497 -- 499 Extensions EXTENSION ::= { 500 ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 501 } 503 -- Validation Reconsidered IP Address Delegation Extension OID -- 505 ext-pe-ipAddrBlocks-v2 EXTENSION ::= { 506 SYNTAX IPAddrBlocks 507 IDENTIFIED BY id-pe-ipAddrBlocks-v2 508 } 510 id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD2 } 512 -- Validation Reconsidered IP Address Delegation -- 513 -- Extension Syntax -- 515 -- Syntax is imported from [RFC6268] -- 517 -- Validation Reconsidered Autonomous System Identifier -- 518 -- Delegation Extension OID -- 520 ext-pe-autonomousSysIds-v2 EXTENSION ::= { 521 SYNTAX ASIdentifiers 522 IDENTIFIED BY id-pe-autonomousSysIds-v2 523 } 525 id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD3 } 527 -- Validation Reconsidered Autonomous System Identifier -- 528 -- Delegation Extension Syntax -- 530 -- Syntax is imported from [RFC6268] -- 532 END 534 4.2.4. An alternative to RFC6487 Profile for X.509 PKIX Resource 535 Certificates 537 This document defines an alternative Profile for X.509 PKIX Resource 538 Certificates. This profile follows all definitions and procedures 539 described in [RFC6487] with the following notable exceptions. 541 4.2.4.1. Amended Certificate Policies 543 The following is an amended specification to be used in this profile, 544 in place of section 4.8.9 of [RFC6487]. 546 This extension MUST be present and MUST be marked critical. It MUST 547 include exactly one policy of type id-cp-ipAddr-asNumber-v2, as 548 specified in the updated RPKI CP in Section 4.2.1. 550 4.2.4.2. Amended IP Resources 552 The following is an amended specification to be used in this profile, 553 in place of section 4.8.10 of [RFC6487]. 555 Either the IP Resources extension, or the AS Resources extension, or 556 both, MUST be present in all RPKI certificates, and if present, MUST 557 be marked critical. 559 This extension contains the list of IP address resources as per 560 Section 4.2.2.1. The value may specify the "inherit" element for a 561 particular Address Family Identifier (AFI) value. In the context of 562 resource certificates describing public number resources for use in 563 the public Internet, the Subsequent AFI (SAFI) value MUST NOT be 564 used. 566 This extension MUST either specify a non-empty set of IP address 567 records, or use the "inherit" setting to indicate that the IP address 568 resource set of this certificate is inherited from that of the 569 certificate's issuer. 571 4.2.4.3. Amended AS Resources 573 The following is an amended specification to be used in this profile, 574 in place of section 4.8.11 of [RFC6487]. 576 Either the AS Resources extension, or the IP Resources extension, or 577 both, MUST be present in all RPKI certificates, and if present, MUST 578 be marked critical. 580 This extension contains the list of AS number resources as per 581 Section 4.2.2.3, or it may specify the "inherit" element. Routing 582 Domain Identifier (RDI) values are NOT supported in this profile and 583 MUST NOT be used. 585 This extension MUST either specify a non-empty set of AS number 586 records, or use the "inherit" setting to indicate that the AS number 587 resource set of this certificate is inherited from that of the 588 certificate's issuer. 590 4.2.4.4. Amended Resource Certificate Path Validation 592 The following is an amended specification for path validation to be 593 used in place of section 7.2 of [RFC6487] allowing for the validation 594 of both certificates following the profile defined in [RFC6487], as 595 well as certificates following the profile described above. 597 The following algorithm is employed to validate CA and EE resources 598 certificates. It is modelled on the path validation algorithm from 599 [RFC5280], but modified to make use of the IP Address Delegation and 600 AS Identifier Delegation Extensions from [RFC3779]. 602 There are two inputs to the validation algorithm: 604 1. a trust anchor 606 2. a certificate to be validated 608 The algorithm is initialized with two new variables for use in the 609 RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set- 610 AS (VRS-AS). These sets are used to track the set of INRs (IP 611 address space and AS Numbers) that are considered valid for each CA 612 certificate. The VRS-IP and VRS-AS sets are initially set to the IP 613 Address Delegation and AS Identifier Delegation values, respectively, 614 from the trust anchor used to perform validation. 616 This path validation algorithm verifies, among other things, that a 617 prospective certification path (a sequence of n certificates) 618 satisfies the following conditions: 620 a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is 621 the issuer of certificate ('x' + 1); 623 b. certificate '1' is issued by a trust anchor; 625 c. certificate 'n' is the certificate to be validated; and 627 d. for all 'x' in {1, ..., n}, certificate 'x' is valid. 629 Certificate validation requires verifying that all of the following 630 conditions hold, in addition to the certification path validation 631 criteria specified in Section 6 of [RFC5280]. 633 1. The signature of certificate x (x>1) is verified using the public 634 key of the issuer's certificate (x-1), using the signature 635 algorithm specified for that public key (in certificate x-1). 637 2. The current time lies within the interval defined by the 638 NotBefore and NotAfter values in the Validity field of 639 certificate x. 641 3. The Version, Issuer, and Subject fields of certificate x satisfy 642 the constraints established in Section 4.1-4.7 of this 643 specification. 645 4. If certificate x uses the Certificate Policy defined in section 646 4.8.9 of [RFC6487], then the certificate MUST contain all 647 extensions defined in section 4.8 of [RFC6487] that must be 648 present. The value(s) for each of these extensions MUST satisfy 649 the constraints established for each extension in the respective 650 sections. Any extension not thus identified MUST NOT appear in 651 certificate x. 653 5. If certificate x uses the Certificate Policy defined in 654 Section 4.2.4.1, then all extensions defined in section 4.8 of 655 [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be 656 present. The certificate MUST contain an extension as defined in 657 Section 4.2.4.2 or Section 4.2.4.3, or both. The value(s) for 658 each of these extensions MUST satisfy the constraints established 659 for each extension in the respective sections. Any extension not 660 thus identified MUST NOT appear in certificate x. 662 6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT 663 appear on a CRL issued by the CA represented by certificate x-1 665 7. Compute the VRS-IP and VRS-AS set values as indicated below: 667 * If the IP Address Delegation extension is present in 668 certificate x and x=1, set the VRS-IP to the resources found 669 in this extension. 671 * If the IP Address Delegation extension is present in 672 certificate x and x>1, set the VRS-IP to the intersection of 673 the resources between this extension and the value of the VRS- 674 IP computed for certificate x-1. 676 * If the IP Address Delegation extension is absent in 677 certificate x, set the VRS-IP to NULL. 679 * If the IP Address Delegation extension is present in 680 certificate x and x=1, set the VRS-IP to the resources found 681 in this extension. 683 * If the AS Identifier Delegation extension is present in 684 certificate x and x>1, set the VRS-AS to the intersection of 685 the resources between this extension and the value of the VRS- 686 AS computed for certificate x-1 688 * If the AS Identifier Delegation extension is absent in 689 certificate x, set the VRS-AS to NULL. 691 8. If there is any difference in resources in the VRS-IP and the IP 692 Address Delegation extension on certificate x, or the VRS-AS and 693 the AS Identifier Delegation extension on certificate x, then: 695 * If certificate x uses the Certificate Policy defined in 696 Section 4.2.4.1 a warning listing the over-claiming resources 697 for certificate x SHOULD be issued. 699 * If certificate x uses the Certificate Policy defined in 700 section 4.8.9 of [RFC6487], then certificate x MUST be 701 rejected. 703 These rules allow a CA certificate to contain resources that are not 704 present in (all of) the certificates along the path from the trust 705 anchor to the CA certificate. If none of the resources in the CA 706 certificate are present in all certificates along the path, no 707 subordinate certificates could be valid. However, the certificate is 708 not immediately rejected as this may be a transient condition. Not 709 immediately rejecting the certificate does not result in a security 710 problem because the associated VRS sets accurately reflect the 711 resources validly associated with the certificate in question. 713 4.2.5. An alternative ROA validation RFC6482 715 Section 4 of [RFC6482] currently has the following text on the 716 validation of resources on a ROA: 718 o The IP address delegation extension [RFC3779] is present in the 719 end-entity (EE) certificate (contained within the ROA), and each 720 IP address prefix(es) in the ROA is contained within the set of IP 721 addresses specified by the EE certificate's IP address delegation 722 extension. 724 If the end-entity certificate uses the Certificate Policy defined in 725 Section 4.2.4.1, then the following approach must be used instead. 727 o The amended IP address delegation extension described in 728 Section 4.2.4.2 is present in the end-entity (EE) certificate 729 (contained within the ROA), and each IP address prefix(es) in the 730 ROA is contained within the VRS-IP set that is specified as an 731 outcome of EE certificate validation described in Section 4.2.4.4. 733 Note that this ensures that ROAs can be valid only, if all IP address 734 prefixes in the ROA are encompassed by the VRS-IP of all certificates 735 along the path to the trust anchor used to verify it. 737 Operators MAY issue separate ROAs for each IP address prefix, so that 738 the loss of one or more IP address prefixes from the VRS-IP of any 739 certificate along the path to the trust anchor would not invalidate 740 authorizations for other IP address prefixes. 742 4.2.6. An alternative to BGPSec Router Certificate Validation 744 If a BGPsec Router Certificate ([I-D.ietf-sidr-bgpsec-pki-profiles]) 745 uses the Certificate Policy defined in Section 4.2.4.1, then in 746 addition to the BGPsec Router Certificate Validation defined in 747 section 3.3 of [I-D.ietf-sidr-bgpsec-pki-profiles], the following 748 constraint MUST be met: 750 o The VRS-AS of BGPsec Router Certificates MUST encompass all ASNs 751 in the AS Resource Identifier Delegation extension. 753 Operators MAY issue separate BGPsec Router Certificates for different 754 ASNs, so that the loss of on ASN from the VRS-AS of any certificate 755 along the path to the trust anchor would not invalidate router keys 756 for other ASNs. 758 5. Validation examples 760 In this section we will demonstrate the outcome of RPKI validation 761 performed using the algorithm and procedures described in 762 Section 4.2.4.4, Section 4.2.5 and Section 4.2.6, under three 763 deployment scenarios: 765 o An RPKI tree consisting of certificates using the old OIDs only 767 o An RPKI tree consisting of certificates using the new OIDs only 769 o An RPKI tree consisting of a mix of certificates using either the 770 old or the new OIDs 772 In this context we refer to a certificate as using the 'old' OIDs, if 773 the certificate uses a combination of the OIDs defined in section 774 4.8.9 of [RFC6487], section 2.2.1 of [RFC3779] and/or section 3.2.1 775 od [RFC3779]. We refer to a certificate as using the 'new' OIDS, if 776 the certificate uses a combination of OIDs defined in 777 Section 4.2.4.1, Section 4.2.2.1 and/or Section 4.2.2.3. 779 5.1. Example 1 - An RPKI tree using the old OIDs only 781 Consider the following example: 783 Certificate 1 (trust anchor): 784 Issuer: TA, 785 Subject: TA, 786 OIDs: OLD, 787 Resources: 0/0, ::0, AS0-4294967295 (ALL Resources) 789 Verified Resource Set: 0/0, ::0, AS0-4294967295 (ALL Resources) 790 Warnings: none 792 Certificate 2: 793 Issuer: TA, 794 Subject: CA1, 795 OIDs: OLD, 796 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496 798 Verified Resource Set: 192.0.2.0/24, 799 2001:db8::/32, AS64496 800 Warnings: none 802 Certificate 3 (invalid): 803 Issuer: CA1, 804 Subject: CA2, 805 OIDs: OLD, 806 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496 808 Verified Resource Set: 192.0.2.0/24, AS64496 810 Certificate 3 is considered invalid because "Resources:" 811 contains 198.51.100.0/24 which is not found in the 812 Verified Resource Set. 814 ROA 1 (invalid): 815 Embedded Certificate 4 (EE certificate invalid): 816 Issuer: CA2, 817 Subject: R1, 818 OIDs: OLD, 819 Resources: 192.0.2.0/24 820 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 822 ROA1 is considered invalid because Certificate 3 is invalid. 824 ROA 2 (invalid): 825 Embedded Certificate 5 (EE certificate invalid): 826 Issuer: CA2, 827 Subject: R2, 828 OIDs: OLD, 829 Resources: 198.51.100.0/24 830 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 832 ROA2 is considered invalid because Certificate 3 is invalid. 834 BGPSec Certificate 1 (invalid): 835 Issuer: CA2, 836 Subject: ROUTER-64496, 837 OIDs: NEW, 838 Resources: AS64496 840 BGPSec Certificate 1 is invalid because Certificate 3 is invalid. 842 BGPSec Certificate 2 (invalid): 843 Issuer: CA2, 844 Subject: ALL-ROUTERS, 845 OIDs: NEW, 846 Resources: AS64496-AS64497 848 BGPSec Certificate 2 is invalid because Certificate 3 is invalid. 850 5.2. Example 2 - An RPKI tree using the new OIDs only 852 Consider the following example under the amended approach: 854 Certificate 1 (trust anchor): 855 Issuer: TA, 856 Subject: TA, 857 OIDs: NEW, 858 Resources: 0/0, ::0, AS0-4294967295 (ALL Resources) 860 Verified Resource Set: 0/0, ::0, AS0-4294967295 (ALL Resources) 861 Warnings: none 863 Certificate 2: 864 Issuer: TA, 865 Subject: CA1, 866 OIDs: NEW, 867 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496 868 Verified Resource Set: 192.0.2.0/24, 869 2001:db8::/32, AS64496 870 Warnings: none 872 Certificate 3: 873 Issuer: CA1, 874 Subject: CA2, 875 OIDs: NEW, 876 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496 878 Verified Resource Set: 192.0.2.0/24, AS64496 879 Warnings: over-claim for 198.51.100.0/24 881 ROA 1 (valid): 882 Embedded Certificate 4 (EE certificate): 883 Issuer: CA2, 884 Subject: R1, 885 OIDs: NEW, 886 Resources: 192.0.2.0/24 887 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 889 Verified Resource Set: 192.0.2.0/24 890 Warnings: none 892 ROA1 is considered valid because the prefix matches the Verified 893 Resource Set on the embedded EE certificate. 895 ROA 2 (invalid): 896 Embedded Certificate 5 (EE certificate invalid): 897 Issuer: CA2, 898 Subject: R2, 899 OIDs: NEW, 900 Resources: 198.51.100.0/24 901 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 903 Verified Resource Set: none (empty set) 904 Warnings: 198.51.100.0/24 906 ROA2 is considered invalid because the ROA prefix 198.51.100.0/24 907 is not contained in the Verified Resource Set. 909 BGPSec Certificate 1 (valid): 910 Issuer: CA2, 911 Subject: ROUTER-64496, 912 OIDs: NEW, 913 Resources: AS64496 915 Verified Resource Set: AS64496 916 Warnings: none 918 BGPSec Certificate 2 (invalid): 919 Issuer: CA2, 920 Subject: ALL-ROUTERS, 921 OIDs: NEW, 922 Resources: AS64496-AS64497 924 Verified Resource Set: AS64496 926 BGPSec Certificate 2 is invalid because not all of its Resources 927 are contained in the Verified Resource Set. 929 Note that this problem can be mitigated by issuing separate 930 certificates for each AS number. 932 5.3. Example 3 - An RPKI tree using a mix of old and new OIDs 934 In the following example new OIDs are used only for CA certificates 935 where the issuing CA anticipates that an over-claim could occur, and 936 has a desire to limit the impact of this to just the over-claimed 937 resources in question: 939 Certificate 1 (trust anchor): 940 Issuer: TA, 941 Subject: TA, 942 OIDs: OLD, 943 Resources: 0/0, ::0, AS0-4294967295 (ALL Resources) 945 Verified Resource Set: 0/0, ::0, AS0-4294967295 (ALL Resources) 946 Warnings: none 948 Note that a Trust Anchor certificate cannot be found to over-claim. 949 So, using the new OIDs here would not change anything with regards 950 to the validity of this certificate. 952 Certificate 2: 953 Issuer: TA, 954 Subject: CA1, 955 OIDs: OLD, 956 Resources: 192.0.2.0/24, 2001:db8::/32, AS64496 958 Verified Resource Set: 192.0.2.0/24, 959 2001:db8::/32, AS64496 960 Warnings: none 962 Note that since the TA certificate claims all resources, it is 963 impossible to issue a certificate below it that could be found 964 to be over-claiming. Therefore there is no benefit in using the 965 new OIDs for Certificate 2. 967 Certificate 3: 968 Issuer: CA1, 969 Subject: CA2, 970 OIDs: NEW, 971 Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496 973 Verified Resource Set: 192.0.2.0/24, AS64496 974 Warnings: over-claim for 198.51.100.0/24 976 Note that CA1 anticipated that it might invalid Certificate 3 977 issued to CA2, if its own resources on Certificate 2 were 978 modified and OLD OIDs would have been used on Certificate 3. 980 ROA 1 (valid): 981 Embedded Certificate 4 (EE certificate): 982 Issuer: CA2, 983 Subject: R1, 984 OIDs: OLD, 985 Resources: 192.0.2.0/24 986 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 988 Verified Resource Set: 192.0.2.0/24 989 Warnings: none 991 ROA1 is considered valid because the prefix matches the Verified 992 Resource Set on the embedded EE certificate. 994 ROA 2 (invalid): 995 Embedded Certificate 5 (EE certificate invalid): 996 Issuer: CA2, 997 Subject: R2, 998 OIDs: OLD, 999 Resources: 198.51.100.0/24 1000 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 1002 Verified Resource Set: none (empty set) 1004 ROA2 is considered invalid because "Resources:" on its EE certificate 1005 contains 198.51.100.0/24, which is not contained in its Verified 1006 Resource Set. 1008 Note that if new OIDs were used here (as in example 2) ROA 2 would be 1009 considered invalid because the Prefix is not contained in the 1010 Verified Resource Set. 1012 So, if there is no difference in the validity outcome one could argue 1013 that using old OIDs here is clearest, because any over-claim of ROA 1014 prefixes MUST result in it being considered invalid (as described in 1015 section 4.2.5). 1017 BGPSec Certificate 1 (valid): 1018 Issuer: CA2, 1019 Subject: ROUTER-64496, 1020 OIDs: OLD, 1021 Resources: AS64496 1023 Verified Resource Set: AS64496 1024 Warnings: none 1026 BGPSec Certificate 2 (invalid): 1027 Issuer: CA2, 1028 Subject: ALL-ROUTERS, 1029 OIDs: OLD, 1030 Resources: AS64496-AS64497 1032 Verified Resource Set: AS64496 1034 BGPSec Certificate 2 is consider invalid because "Resources:" contains 1035 AS64497, which is not contained in its Verified Resource Set. 1037 Note that if new OIDs were used here (as in example 2) BGPSec 1038 Certificate 2 would be considered invalid because the Prefix is not 1039 contained in the Verified Resource Set. 1041 So, if there is no difference in the validity outcome one could argue 1042 that using old OIDs here is the clearest, because any over-claim on 1043 this certificate MUST result in it being considered invalid (as 1044 described in section 4.2.6). 1046 Also note that as in example 2 this problem can be mitigated by 1047 issuing separate certificates for each AS number. 1049 6. Deployment Considerations 1051 This document defines an alternative RPKI validation algorithm, but 1052 it does not dictate how this algorithm will be deployed. This should 1053 be discussed as a separate effort. That said, the following 1054 observations may help this discussion. 1056 Because this document introduces new OIDs and an alternative to the 1057 Profile for X.509 PKIX Resource Certificates described in [RFC6487], 1058 the use of such certificates in the global RPKI will lead to the 1059 rejection of such certificates by Relying Party tools that do not 1060 (yet) implement the alternative profile described in this document. 1062 For this reason it is important that such tools are updated before 1063 Certificate Authorities start to use this specification. 1065 However, because the OIDs are defined in each RPKI certificate, there 1066 is no strict requirement for all Certificate Authorities to migrate 1067 to the new OIDs at the same time, or even for all the certificates 1068 they issue. The example in Section 5.3 illustrates a possible 1069 deployment where the new OIDs are used only when issuing CA 1070 certificates where an accidental over-claim may occur. 1072 7. Security Considerations 1074 The authors believe that the revised validation algorithm introduces 1075 no new security vulnerabilities into the RPKI, because it cannot lead 1076 to any ROA and/or Router Certificates to be accepted if they contain 1077 resources that are not held by the issuer. 1079 8. IANA Considerations 1081 IANA is to add the following to the SMI Security for PKIX Certificate 1082 Policies registry: 1084 Decimal Description References 1086 TBD1 id-cp-ipAddr-asNumber-v2 [section 4.2.1] 1088 IANA is to add the following to the SMI Security for PKIX Certificate 1089 Extension registry: 1091 Decimal Description References 1093 TBD2 id-pe-ipAddrBlocks-v2 [section 4.2.2.1] 1094 TBD3 id-pe-autonomousSysIds-v2 [section 4.2.2.3] 1096 IANA is to add the following to the SMI Security for PKIX Module 1097 Identifier registry: 1099 Decimal Description References 1101 TBD4 id-mod-ip-addr-and-as-ident-v2 [section 4.2.2.7] 1102 TBD5 id-mod-ip-addr-and-as-ident-2v2 [section 4.2.3] 1104 9. Acknowledgements 1106 The authors would like to thank Stephen Kent for reviewing and 1107 contributing to this document. We would like to thank Rob Austein 1108 for suggesting that separate OIDs should be used to make the 1109 behaviour of Relying Party tools deterministic, and we would like to 1110 thank Russ Hously, Sean Turner and Tom Petch for their contributions 1111 on OID and ASN.1 updates. Finally we would like to thank Tom 1112 Harrison for a general review of this document. 1114 10. References 1116 10.1. Normative References 1118 [I-D.ietf-sidr-bgpsec-pki-profiles] 1119 Reynolds, M., Turner, S., and S. Kent, "A Profile for 1120 BGPsec Router Certificates, Certificate Revocation Lists, 1121 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 1122 profiles-21 (work in progress), January 2017. 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, 1126 DOI 10.17487/RFC2119, March 1997, 1127 . 1129 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1130 Addresses and AS Identifiers", RFC 3779, 1131 DOI 10.17487/RFC3779, June 2004, 1132 . 1134 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1135 Housley, R., and W. Polk, "Internet X.509 Public Key 1136 Infrastructure Certificate and Certificate Revocation List 1137 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1138 . 1140 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1141 Origin Authorizations (ROAs)", RFC 6482, 1142 DOI 10.17487/RFC6482, February 2012, 1143 . 1145 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 1146 Policy (CP) for the Resource Public Key Infrastructure 1147 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 1148 2012, . 1150 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1151 X.509 PKIX Resource Certificates", RFC 6487, 1152 DOI 10.17487/RFC6487, February 2012, 1153 . 1155 10.2. Informative References 1157 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 1158 for the Cryptographic Message Syntax (CMS) and the Public 1159 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 1160 DOI 10.17487/RFC6268, July 2011, 1161 . 1163 Authors' Addresses 1165 Geoff Huston 1166 Asia Pacific Network Information Centre 1167 6 Cordelia St 1168 South Brisbane, QLD 4101 1169 Australia 1171 Phone: +61 7 3858 3100 1172 Email: gih@apnic.net 1174 George Michaelson 1175 Asia Pacific Network Information Centre 1176 6 Cordelia St 1177 South Brisbane, QLD 4101 1178 Australia 1180 Phone: +61 7 3858 3100 1181 Email: ggm@apnic.net 1183 Carlos M. Martinez 1184 Latin American and Caribbean IP Address Regional Registry 1185 Rambla Mexico 6125 1186 Montevideo 11400 1187 Uruguay 1189 Phone: +598 2604 2222 1190 Email: carlos@lacnic.net 1191 Tim Bruijnzeels 1192 RIPE Network Coordination Centre 1193 Singel 258 1194 Amsterdam 1016 AB 1195 The Netherlands 1197 Email: tim@ripe.net 1199 Andrew Lee Newton 1200 American Registry for Internet Numbers 1201 3635 Concorde Parkway 1202 Chantilly, VA 20151 1203 USA 1205 Email: andy@arin.net 1207 Daniel Shaw 1208 African Network Information Centre (AFRINIC) 1209 11th Floor, Standard Chartered Tower 1210 Cybercity, Ebene 1211 Mauritius 1213 Phone: +230 403 51 00 1214 Email: daniel@afrinic.net