idnits 2.17.1 draft-va-sidrops-deploy-reconsidered-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8360]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2019) is 1876 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Michaelson 3 Internet-Draft APNIC 4 Intended status: Experimental T. Bruijnzeels 5 Expires: September 8, 2019 opennetlabs 6 March 7, 2019 8 Deployment of Reconsidered Validation in the Resource Public Key 9 Infrastructure (RPKI) 10 draft-va-sidrops-deploy-reconsidered-01 12 Abstract 14 This document defines a deployment model for reconsidered validation 15 [RFC8360] in the Resource Public Key Infrastructure (RPKI). 17 It stipulates that Relying Parties in the RPKI MUST support 18 reconsidered validation by 1 July TBD-Year, and that Certificate 19 Authorities MAY use the reconsidered validation OIDs in CA 20 certificates that they issue from this date. Furthermore Certificate 21 Authorities should monitor whether the set of resources in CA 22 certificate they receive has shrunk, and make adjustments in the CA 23 certificates and/or other RPKI objects when appropriate. 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 https://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 September 8, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 (https://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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Phased Deployment of the Amended Certificate Profile . . . . 3 62 2.1. Phase 1: Requirements for RP Software . . . . . . . . . . 4 63 2.2. Phase 2: Requirements for operators . . . . . . . . . . . 4 64 2.3. Phase 3: Requirements for Certificate Authorities . . . . 5 65 3. Avoid over-claiming CA certificates . . . . . . . . . . . . . 5 66 3.1. Avoid Invalidating Delegated CAs . . . . . . . . . . . . 5 67 3.1.1. Graceperiod and Check Intervals . . . . . . . . . . . 5 68 3.1.2. Shrinking issued CA certificates . . . . . . . . . . 6 69 3.2. Self monitoring and clean-up . . . . . . . . . . . . . . 6 70 4. Mixed mode operations . . . . . . . . . . . . . . . . . . . . 7 71 5. Example use of the amended profile with transfers . . . . . . 7 72 6. RFC-EDITOR Considerations . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 14 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Overview 81 This document defines a deployment model for reconsidered validation 82 [RFC8360] in the Resource Public Key Infrastructure (RPKI). 84 Reconsidered validation differs from normal validation [RFC6487] in 85 that under reconsidered rules the intersection of resources between a 86 child certificate and the resources contained in the (chain of) 87 parent certificate(s) is accepted. Any resources that are contained 88 in the child certificate only result in a warning about these 89 resources, rather than the rejection of that certificate. Thus 90 reconsidered validation limits the impact of over-claims in the RPKI 91 to the set of resources under dispute. 93 The applicability of reconsidered validation is signalled by the use 94 of a distinct set of OIDs on a Resource Certificate [RFC8360]. 95 Because of this reconsidered validation can only be deployed when a 96 majority of Relying Party software is updated to support this new 97 algorithm. This document stipulates that RP software MUST support 98 [RFC8360] by 1 July TBD-Year. After 1 July TBD-Year Certificate 99 Authorities MAY start to use [RFC8360] in CA certificates that they 100 issue. 102 Note that the use of reconsidered validation is restricted to CA 103 Certificates only. Issuing Certificate Authorities may (be forced 104 to) re-issue delegated CA certificates with shrunk resource pro- 105 actively, and therefore it's at the CA certificate level that 106 mismatches between resources actually included on such a certificate 107 and the resources the recipient believes to be included on these 108 certificates may occur. 110 On the other hand, ROA and BGPSec Router Certificate reconsidered 111 validation still requires that all resources are also held by the 112 path of parent certificates to these objects. In other words, using 113 the reconsidered validation here is unneccessary. 115 Furthermore, Certificate Authorities should monitor pro-actively 116 whether the set of resources in the CA certificate they received has 117 been shrunk by their parent. Resource Certificates that they in turn 118 issue that use resources no longer validly held by them should be 119 shrunk or revoked. BGPSec Router Certificates or ROAs that use such 120 resources should be removed. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Phased Deployment of the Amended Certificate Profile 132 There is an existing BCP document that describes an algorithm agility 133 procedure for the RPKI [RFC6919]. This procedure involves four 134 distinct phases with requirements for CAs and RPs. During this 135 process the entire RPKI tree is essentially duplicated, and two 136 disctinct trees are maintained in paralel for some time, until the 137 old tree can be withdrawn. The dates for each milestones are 138 expected to be documented in a BCP. 140 In this case however, the amended validation process is very similar 141 to the existing validation process. Moreover, as [RFC8360] describes 142 there is no fundamental issue in having an RPKI tree in which a mix 143 of regular [RFC6487] and amended [RFC8360] certificates can be found. 145 The use of the amended certificate profile communicates that over- 146 claims for this particular certificate can occur, and if they do, 147 that their impact should be limited to the resources that are in 148 over-claim. Sections 4.2.5 and 4.2.6 of [RFC8360] stipulate that 149 such over-claims on the EE certificate would invalidate ROA and 150 BGPSec Router Certificates. 152 In conclusion the amended certificate profile MUST only be used on CA 153 certificates for CA organisations where an overclaim may accidentally 154 occur, and MUST NOT be used anywhere else: e.g. on a TA CA 155 certificate which by definition cannot overclaim, or on any specific 156 attestation about resources other than a delegation to another CA, 157 e.g. ROAs and BGPSec Router Certificates. 159 So, contrary to the process described in [RFC6919] there is no 160 desired outcome here to completely replace an existing algorithm with 161 a new algorithm. And consequently a different approach to the 162 deployment phases is applicable here. 164 We recognise the following phases: 166 1. Relying Party software MUST support the amended profile 168 2. Operators MUST use updated Relying Party software; 170 3. Certificate Authorities MAY use the amended profile 172 As suggested in [RFC6919] the dates for each of these phases can be 173 documented in this BCP: 175 1. 1 July TBD-Year 177 2. 1 July TBD-Year - 1 January TBD-Year +1 179 3. 1 January TBD-Year +1 181 2.1. Phase 1: Requirements for RP Software 183 Relying Party software MUST support [RFC8360] by 1 July TBD-Year. 185 2.2. Phase 2: Requirements for operators 187 Network operators MUST update their Relying Party software between 1 188 July TBD-Year and 1 January TBD-Year +1. 190 2.3. Phase 3: Requirements for Certificate Authorities 192 Trust Anchor CA certificates referenced in Trust Anchor Locator (TAL) 193 files [RFC7730] MUST NOT make use of amended Resource Certificates 194 defined in [RFC8360]. 196 From 1 January 2020 Certificate Authorities MAY use amended Resource 197 Certificates [RFC8360] for CA certificates that they issue to 198 delegated Certificate Authorities. Certificate Authorities MUST NOT 199 use the amended Resource Certificate profile for any other 200 certificates they issue. 202 3. Avoid over-claiming CA certificates 204 Even though the amended profile limits the impact of resource over- 205 claims on CA certificates, this does not mean that such over-claims 206 are intended to become the norm. As we will describe in the 207 following sections: 209 o Issuing CAs should try to avoid invalidating delegated CAs 211 o Delegated CAs should self-monitor and take action in case 212 resources are removed 214 3.1. Avoid Invalidating Delegated CAs 216 3.1.1. Graceperiod and Check Intervals 218 If resources need to be removed from a delegated CA it is reasonable 219 to observe a graceperiod that will allow a delegated CA (and 220 recursively their delegated CAs if applicable) to clean up objects. 221 A reasonable duration for this period depends on the following 222 factors: 224 o The frequency that a child CA can check with its parents about its 225 CA certificate eligibility (Check Interval) 227 o The depth of the tree of delegated CAs 229 We believe that it's reasonable to require the child CAs MUST issue a 230 Resource Class List Query [RFC6492] to their parent CA no less 231 frequently than once per houri (Check Interval). It is not expected 232 that the depth of delegated CA certificates will exceed 5 or 6 CA 233 authorities. In conclusion a graceperiod of 24 hours seems 234 reasonable. 236 3.1.2. Shrinking issued CA certificates 238 When a Certificate Authority finds that it needs to shrink the set of 239 resources held by a delegated Certificate Authority, but still holds 240 the resources to be removed on its own CA certificate, then it SHOULD 241 give the delegated Certificate Authority up to 24 hours to request a 242 shrunk CA certificate, e.g. through the provision protocol [RFC6492]. 244 The CA SHOULD issue a new CA certificate immediately using a 245 "notAfter" time that is set to whichever is soonest: 24 hours from 246 now, or the "notAfter" time on the CA certificate held by this 247 issuing CA. This will alert the delegated CA of both the limited 248 lifetime of their current CA certificate, and which resources remain 249 eligible after this time, when the delegated CA sends a Resource 250 Class List Query [RFC6492]. 252 If the Certificate Authority no longer holds the resources that are 253 to be removed, or this 24 hour period has passed, then a shrunk CA 254 certificate MUST be issued. Such shrunk certificate SHOULD use the 255 amended Resource Certificate profile in order to limit the impact in 256 the validation of objects issued by the subsidiary Certificate 257 Authority. 259 3.2. Self monitoring and clean-up 261 CAs in the RPKI MUST monitor whether the CA certificate issued to 262 them by their parent needs to be shrunk, for example by sending a 263 Resource Class List Query [RFC6492] to their parent CA no less 264 frequently than once per hour. 266 If the CA finds that a reduced resource set is in order, but their 267 current certificate is still valid, and they have issued delegated CA 268 certificates with the resources to be reduced to delegated CAs, then 269 they SHOULD give these delegated CAs up to 24 hours, or the time 270 until 1 hour before their own CA certificate "notAfter" time if this 271 period is shorter, to request a shrunk CA certificate as described 272 above. 274 The CA MUST now remove any other RPKI objects that it issued that 275 reference any of the resources to be removed. If the CA issued ROAs 276 that reference multiple prefixes, and some of these prefixes are not 277 to be removed, then the CA SHOULD create new ROAs for these prefixes 278 and use one ROA object per prefix rather than bundling multiple 279 prefixes on a single ROA object. 281 If the CA no longer issues any CA certificates or RPKI objects 282 referencing the resources to be removed, or it finds that its current 283 CA certificate is no longer valid or will expire within 1 hour, then 284 the CA MUST request a new CA certificate to be issued by their parent 285 CA. 287 4. Mixed mode operations 289 Since there is no clear intention to have a "flag day" and move all 290 RP systems to a new OID and a new mode of operation the question 291 arises: what is the mode of operation of an RPKI system where both 292 OID exist concurrently? 294 In mixed-mode, the application of the OID is taken to refer to the CA 295 certificate itself: The value is set by the issuer, and might 296 represent a default inherited value. 298 Should a CA be signed over with the old OID, its validation MUST 299 follow the old OID. if a certficate is signed over with the new OID, 300 its validation MUST follow the new OID. Therefore, ether situation 301 can be expected but the intent is understood to apply to that 302 certificate in the path. 304 The application of the OID applies to the certificate in hand, not 305 the children. This permits a "strict" OID to have a "lax" OID child, 306 which is the only pattern of issuance which has a risk of mis- 307 interpretation. 309 +-----+--------------+---------------------------+ 310 | OID | State | Consequence in tree below | 311 +-----+--------------+---------------------------+ 312 | old | no overclaim | tree is valid | 313 | old | overclaiming | tree is invalid | 314 | new | no overclaim | tree is valid | 315 | new | overclaiming | tree is valid when pruned | 316 +-----+--------------+---------------------------+ 318 5. Example use of the amended profile with transfers 320 Consider the following starting situation where a Trust Anchor issues 321 a resource certificate to Certificate Auhtority CA1, which in turn 322 issues a ROA and delegates some resources to CA2, which in turn also 323 issues a ROA: 325 TA CA Certificate: 326 Issuer: TA 327 Subject: TA 328 Profile: 6487 (regular) 329 Resources: 192.0.2.0/24, 198.51.100.0/24, 330 2001:db8::/32, AS64496-AS64500 332 CA1 CA Certificate: 333 Issuer: TA 334 Subject: CA1 335 Profile: 8360 (amended) 336 Resources: 192.0.2.0/24, 198.51.100.0/24 337 2001:db8::/32, AS64496-AS64500 339 CA1 ROA 1: 340 Issuer: CA1 341 Subject: R1 342 Profile: 6487 (regular) 343 Resources: 192.0.2.0/24 345 ASN: 64496 346 Prefixes: 192.0.2.0/24 (Max 24) 348 CA2 CA Certificate: 349 Issuer: CA1 350 Subject: CA2 351 Profile: 8360 (amended) 352 Resources: 198.51.100.0/24, 353 2001:db8::/32, AS64496-AS64500 355 CA2 ROA 1: 356 Issuer: CA2 357 Subject: R1 358 Profile: 6487 (regular) 359 Resources: 2001:db8::/32 361 ASN: 64496 362 Prefixes: 2001:db8::/32 (Max 48) 364 CA2 ROA 2: 365 Issuer: CA2 366 Subject: R1 367 Profile: 6487 (regular) 368 Resources: 198.51.100.0/24 370 ASN: 64496 371 Prefixes: 198.51.100.0/24 (Max 24) 373 Now assume that the TA decides that CA1 should no longer hold the 374 prefix 198.51.100.0/24. However, CA1 is offline for some reason and 375 it does not check in with TA about its CA certificate eligibility. 377 After 24 hours TA will decided that it has waited long enough and it 378 will now pro-actively issue an amended CA certificate for CA1. 379 Because the amended profile is used for CA certificates the impact of 380 this action is limited. CA2 has been unaware of the change, but only 381 their ROA2 which is using the prefix is now invalidated: 383 TA CA Certificate: 384 Issuer: TA 385 Subject: TA 386 Profile: 6487 (regular) 387 Resources: 192.0.2.0/24, 198.51.100.0/24, 388 2001:db8::/32, AS64496-AS64500 390 CA1 CA Certificate: 391 Issuer: TA 392 Subject: CA1 393 Profile: 8360 (amended) 394 Resources: 192.0.2.0/24 395 2001:db8::/32, AS64496-AS64500 397 CA1 ROA 1: 398 Issuer: CA1 399 Subject: R1 400 Profile: 6487 (regular) 401 Resources: 192.0.2.0/24 403 ASN: 64496 404 Prefixes: 192.0.2.0/24 (Max 24) 406 CA2 CA Certificate: 407 Issuer: CA1 408 Subject: CA2 409 Profile: 8360 (amended) 410 Rejected: 198.51.100.0/24 411 Accepted: 2001:db8::/32, AS64496-AS64500 413 CA2 ROA 1: 414 Issuer: CA2 415 Subject: R1 416 Profile: 6487 (regular) 417 Resources: 2001:db8::/32 419 ASN: 64496 420 Prefixes: 2001:db8::/32 (Max 48) 422 CA2 ROA 2 (INVALID): 423 Issuer: CA2 424 Subject: R1 425 Profile: 6487 (regular) 426 Resources: 198.51.100.0/24 428 ASN: 64496 429 Prefixes: 198.51.100.0/24 (Max 24) 431 Now CA1 comes back online. It discovers that it lost the prefix 432 198.51.100.0/24. It will now re-issue the CA certificate issued to 433 CA2 immediately: 435 TA CA Certificate: 436 Issuer: TA 437 Subject: TA 438 Profile: 6487 (regular) 439 Resources: 192.0.2.0/24, 198.51.100.0/24, 440 2001:db8::/32, AS64496-AS64500 442 CA1 CA Certificate: 443 Issuer: TA 444 Subject: CA1 445 Profile: 8360 (amended) 446 Resources: 192.0.2.0/24 447 2001:db8::/32, AS64496-AS64500 449 CA1 ROA 1: 450 Issuer: CA1 451 Subject: R1 452 Profile: 6487 (regular) 453 Resources: 192.0.2.0/24 455 ASN: 64496 456 Prefixes: 192.0.2.0/24 (Max 24) 458 CA2 CA Certificate: 459 Issuer: CA1 460 Subject: CA2 461 Profile: 8360 (amended) 462 Resources: 2001:db8::/32, AS64496-AS64500 464 CA2 ROA 1: 465 Issuer: CA2 466 Subject: R1 467 Profile: 6487 (regular) 468 Resources: 2001:db8::/32 470 ASN: 64496 471 Prefixes: 2001:db8::/32 (Max 48) 473 CA2 ROA 2 (INVALID): 474 Issuer: CA2 475 Subject: R1 476 Profile: 6487 (regular) 477 Resources: 198.51.100.0/24 479 ASN: 64496 480 Prefixes: 198.51.100.0/24 (Max 24) 482 Finally CA2, who was trying to check in with CA1 even when it was 483 unavailable, discovers that it lost the prefix '198.51.100.0/24'. It 484 will therefore remove its ROA2: 486 TA CA Certificate: 487 Issuer: TA 488 Subject: TA 489 Profile: 6487 (regular) 490 Resources: 192.0.2.0/24, 198.51.100.0/24, 491 2001:db8::/32, AS64496-AS64500 493 CA1 CA Certificate: 494 Issuer: TA 495 Subject: CA1 496 Profile: 8360 (amended) 497 Resources: 192.0.2.0/24 498 2001:db8::/32, AS64496-AS64500 500 CA1 ROA 1: 501 Issuer: CA1 502 Subject: R1 503 Profile: 6487 (regular) 504 Resources: 192.0.2.0/24 506 ASN: 64496 507 Prefixes: 192.0.2.0/24 (Max 24) 509 CA2 CA Certificate: 510 Issuer: CA1 511 Subject: CA2 512 Profile: 8360 (amended) 513 Resources: 2001:db8::/32, AS64496-AS64500 515 CA2 ROA 1: 516 Issuer: CA2 517 Subject: R1 518 Profile: 6487 (regular) 519 Resources: 2001:db8::/32 521 ASN: 64496 522 Prefixes: 2001:db8::/32 (Max 48) 524 A few things to note: 526 o In this scenario CA1 was offline, and it was not performing the 527 actions required to the occurance of an overclaiming CA 528 certificate to remain for CA2 and CA2 was not aware of the coming 529 change. 531 o The use of the amened profile for reconsidered validation rules 532 limited the impact of this operational problem to just those 533 resources that were being removed. 535 o Had CA2 not only monitored its CA certificate eligibility directly 536 with its parent, but had they performed RPKI validation to monitor 537 their own certificate and products. Then they would have removed 538 their ROA2 sooner. Since CA1 was offline however, they would not 539 have been able to request a shrunk CA certificate for themselves. 541 o Had CA1 and CA2 both been online and TA observed the 24 hour grace 542 period, then things would have been changed without the occurance 543 of invalid objects or warnings. CA2 would have removed ROA2, and 544 then would have requested a shrunk CA certificate for itself. CA1 545 would have noticed that it was safe to reques its own CA 546 certificate to be shrunk. The CA depth here is 2, so this would 547 have happened within 2 hours, well within the 24 hours limit. 549 6. RFC-EDITOR Considerations 551 The exact year value TBD-Year and TBD-Year +1 are to be defined in WG 552 process and will be set before WGLC 554 7. Security Considerations 556 TBD 558 8. Revision History 560 01 - mixed-mode operation text. 2019 00 - Initial draft. 2018 562 9. Acknowledgements 564 This draft is a product of conversations in the RIR/NRO Engineering 565 Coordination Group. 567 10. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 575 X.509 PKIX Resource Certificates", RFC 6487, 576 DOI 10.17487/RFC6487, February 2012, 577 . 579 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 580 Protocol for Provisioning Resource Certificates", 581 RFC 6492, DOI 10.17487/RFC6492, February 2012, 582 . 584 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 585 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 586 DOI 10.17487/RFC6919, April 2013, 587 . 589 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 590 "Resource Public Key Infrastructure (RPKI) Trust Anchor 591 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 592 . 594 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 595 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 596 May 2017, . 598 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 599 Newton, A., and D. Shaw, "Resource Public Key 600 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 601 DOI 10.17487/RFC8360, April 2018, 602 . 604 Authors' Addresses 606 George G. Michaelson 607 Asia Pacific Network Information Centre 608 6 Cordelia St 609 South Brisbane, QLD 4101 610 Australia 612 Email: ggm@apnic.net 614 Tim Bruijnzeels 615 Open Netlabs B.V. 616 Science Park 400 617 Amsterdam 1098 XH 618 The Netherlands 620 Email: timb@opennetlabs.nl