idnits 2.17.1 draft-va-sidrops-deploy-reconsidered-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 19, 2018) is 2009 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: April 22, 2019 opennetlabs 6 October 19, 2018 8 Deployment of Reconsidered Validation in the Resource Public Key 9 Infrastructure (RPKI) 10 draft-va-sidrops-deploy-reconsidered-00 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 April 22, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . 4 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 . . . . . . . . . . 5 69 3.2. Self monitoring and clean-up . . . . . . . . . . . . . . 6 70 4. Example use of the amended profile with transfers . . . . . . 6 71 5. RFC-EDITOR Considerations . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Overview 79 This document defines a deployment model for reconsidered validation 80 [RFC8360] in the Resource Public Key Infrastructure (RPKI). 82 Reconsidered validation differs from normal validation [RFC6487] in 83 that under reconsidered rules the intersection of resources between a 84 child certificate and the resources contained in the (chain of) 85 parent certificate(s) is accepted. Any resources that are contained 86 in the child certificate only result in a warning about these 87 resources, rather than the rejection of that certificate. Thus 88 reconsidered validation limits the impact of over-claims in the RPKI 89 to the set of resources under dispute. 91 The applicability of reconsidered validation is signalled by the use 92 of a distinct set of OIDs on a Resource Certificate [RFC8360]. 93 Because of this reconsidered validation can only be deployed when a 94 majority of Relying Party software is updated to support this new 95 algorithm. This document stipulates that RP software MUST support 96 [RFC8360] by 1 July TBD-Year. After 1 July TBD-Year Certificate 97 Authorities MAY start to use [RFC8360] in CA certificates that they 98 issue. 100 Note that the use of reconsidered validation is restricted to CA 101 Certificates only. Issuing Certificate Authorities may (be forced 102 to) re-issue delegated CA certificates with shrunk resource pro- 103 actively, and therefore it's at the CA certificate level that 104 mismatches between resources actually included on such a certificate 105 and the resources the recipient believes to be included on these 106 certificates may occur. 108 On the other hand, ROA and BGPSec Router Certificate reconsidered 109 validation still requires that all resources are also held by the 110 path of parent certificates to these objects. In other words, using 111 the reconsidered validation here is unneccessary. 113 Furthermore, Certificate Authorities should monitor pro-actively 114 whether the set of resources in the CA certificate they received has 115 been shrunk by their parent. Resource Certificates that they in turn 116 issue that use resources no longer validly held by them should be 117 shrunk or revoked. BGPSec Router Certificates or ROAs that use such 118 resources should be removed. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Phased Deployment of the Amended Certificate Profile 130 There is an existing BCP document that describes an algorithm agility 131 procedure for the RPKI [RFC6919]. This procedure involves four 132 distinct phases with requirements for CAs and RPs. During this 133 process the entire RPKI tree is essentially duplicated, and two 134 disctinct trees are maintained in paralel for some time, until the 135 old tree can be withdrawn. The dates for each milestones are 136 expected to be documented in a BCP. 138 In this case however, the amended validation process is very similar 139 to the existing validation process. Moreover, as [RFC8360] describes 140 there is no fundamental issue in having an RPKI tree in which a mix 141 of regular [RFC6487] and amended [RFC8360] certificates can be found. 143 The use of the amended certificate profile communicates that over- 144 claims for this particular certificate can occur, and if they do, 145 that their impact should be limited to the resources that are in 146 over-claim. Sections 4.2.5 and 4.2.6 of [RFC8360] stipulate that 147 such over-claims on the EE certificate would invalidate ROA and 148 BGPSec Router Certificates. 150 In conclusion the amended certificate profile MUST only be used on CA 151 certificates for CA organisations where an overclaim may accidentally 152 occur, and MUST NOT be used anywhere else: e.g. on a TA CA 153 certificate which by definition cannot overclaim, or on any specific 154 attestation about resources other than a delegation to another CA, 155 e.g. ROAs and BGPSec Router Certificates. 157 So, contrary to the process described in [RFC6919] there is no 158 desired outcome here to completely replace an existing algorithm with 159 a new algorithm. And consequently a different approach to the 160 deployment phases is applicable here. 162 We recognise the following phases: 164 1. Relying Party software MUST support the amended profile 166 2. Operators MUST use updated Relying Party software; 168 3. Certificate Authorities MAY use the amended profile 170 As suggested in [RFC6919] the dates for each of these phases can be 171 documented in this BCP: 173 1. 1 July TBD-Year 175 2. 1 July TBD-Year - 1 January TBD-Year +1 177 3. 1 January TBD-Year +1 179 2.1. Phase 1: Requirements for RP Software 181 Relying Party software MUST support [RFC8360] by 1 July TBD-Year. 183 2.2. Phase 2: Requirements for operators 185 Network operators MUST update their Relying Party software between 1 186 July TBD-Year and 1 January TBD-Year +1. 188 2.3. Phase 3: Requirements for Certificate Authorities 190 Trust Anchor CA certificates referenced in Trust Anchor Locator (TAL) 191 files [RFC7730] MUST NOT make use of amended Resource Certificates 192 defined in [RFC8360]. 194 From 1 January 2020 Certificate Authorities MAY use amended Resource 195 Certificates [RFC8360] for CA certificates that they issue to 196 delegated Certificate Authorities. Certificate Authorities MUST NOT 197 use the amended Resource Certificate profile for any other 198 certificates they issue. 200 3. Avoid over-claiming CA certificates 202 Even though the amended profile limits the impact of resource over- 203 claims on CA certificates, this does not mean that such over-claims 204 are intended to become the norm. As we will describe in the 205 following sections: 207 o Issuing CAs should try to avoid invalidating delegated CAs 209 o Delegated CAs should self-monitor and take action in case 210 resources are removed 212 3.1. Avoid Invalidating Delegated CAs 214 3.1.1. Graceperiod and Check Intervals 216 If resources need to be removed from a delegated CA it is reasonable 217 to observe a graceperiod that will allow a delegated CA (and 218 recursively their delegated CAs if applicable) to clean up objects. 219 A reasonable duration for this period depends on the following 220 factors: 222 o The frequency that a child CA can check with its parents about its 223 CA certificate eligibility (Check Interval) 225 o The depth of the tree of delegated CAs 227 We believe that it's reasonable to require the child CAs MUST issue a 228 Resource Class List Query [RFC6492] to their parent CA no less 229 frequently than once per houri (Check Interval). It is not expected 230 that the depth of delegated CA certificates will exceed 5 or 6 CA 231 authorities. In conclusion a graceperiod of 24 hours seems 232 reasonable. 234 3.1.2. Shrinking issued CA certificates 236 When a Certificate Authority finds that it needs to shrink the set of 237 resources held by a delegated Certificate Authority, but still holds 238 the resources to be removed on its own CA certificate, then it SHOULD 239 give the delegated Certificate Authority up to 24 hours to request a 240 shrunk CA certificate, e.g. through the provision protocol [RFC6492]. 242 The CA SHOULD issue a new CA certificate immediately using a 243 "notAfter" time that is set to whichever is soonest: 24 hours from 244 now, or the "notAfter" time on the CA certificate held by this 245 issuing CA. This will alert the delegated CA of both the limited 246 lifetime of their current CA certificate, and which resources remain 247 eligible after this time, when the delegated CA sends a Resource 248 Class List Query [RFC6492]. 250 If the Certificate Authority no longer holds the resources that are 251 to be removed, or this 24 hour period has passed, then a shrunk CA 252 certificate MUST be issued. Such shrunk certificate SHOULD use the 253 amended Resource Certificate profile in order to limit the impact in 254 the validation of objects issued by the subsidiary Certificate 255 Authority. 257 3.2. Self monitoring and clean-up 259 CAs in the RPKI MUST monitor whether the CA certificate issued to 260 them by their parent needs to be shrunk, for example by sending a 261 Resource Class List Query [RFC6492] to their parent CA no less 262 frequently than once per hour. 264 If the CA finds that a reduced resource set is in order, but their 265 current certificate is still valid, and they have issued delegated CA 266 certificates with the resources to be reduced to delegated CAs, then 267 they SHOULD give these delegated CAs up to 24 hours, or the time 268 until 1 hour before their own CA certificate "notAfter" time if this 269 period is shorter, to request a shrunk CA certificate as described 270 above. 272 The CA MUST now remove any other RPKI objects that it issued that 273 reference any of the resources to be removed. If the CA issued ROAs 274 that reference multiple prefixes, and some of these prefixes are not 275 to be removed, then the CA SHOULD create new ROAs for these prefixes 276 and use one ROA object per prefix rather than bundling multiple 277 prefixes on a single ROA object. 279 If the CA no longer issues any CA certificates or RPKI objects 280 referencing the resources to be removed, or it finds that its current 281 CA certificate is no longer valid or will expire within 1 hour, then 282 the CA MUST request a new CA certificate to be issued by their parent 283 CA. 285 4. Example use of the amended profile with transfers 287 Consider the following starting situation where a Trust Anchor issues 288 a resource certificate to Certificate Auhtority CA1, which in turn 289 issues a ROA and delegates some resources to CA2, which in turn also 290 issues a ROA: 292 TA CA Certificate: 293 Issuer: TA 294 Subject: TA 295 Profile: 6487 (regular) 296 Resources: 192.0.2.0/24, 198.51.100.0/24, 297 2001:db8::/32, AS64496-AS64500 299 CA1 CA Certificate: 300 Issuer: TA 301 Subject: CA1 302 Profile: 8360 (amended) 303 Resources: 192.0.2.0/24, 198.51.100.0/24 304 2001:db8::/32, AS64496-AS64500 306 CA1 ROA 1: 307 Issuer: CA1 308 Subject: R1 309 Profile: 6487 (regular) 310 Resources: 192.0.2.0/24 312 ASN: 64496 313 Prefixes: 192.0.2.0/24 (Max 24) 315 CA2 CA Certificate: 316 Issuer: CA1 317 Subject: CA2 318 Profile: 8360 (amended) 319 Resources: 198.51.100.0/24, 320 2001:db8::/32, AS64496-AS64500 322 CA2 ROA 1: 323 Issuer: CA2 324 Subject: R1 325 Profile: 6487 (regular) 326 Resources: 2001:db8::/32 328 ASN: 64496 329 Prefixes: 2001:db8::/32 (Max 48) 331 CA2 ROA 2: 332 Issuer: CA2 333 Subject: R1 334 Profile: 6487 (regular) 335 Resources: 198.51.100.0/24 337 ASN: 64496 338 Prefixes: 198.51.100.0/24 (Max 24) 340 Now assume that the TA decides that CA1 should no longer hold the 341 prefix 198.51.100.0/24. However, CA1 is offline for some reason and 342 it does not check in with TA about its CA certificate eligibility. 344 After 24 hours TA will decided that it has waited long enough and it 345 will now pro-actively issue an amended CA certificate for CA1. 346 Because the amended profile is used for CA certificates the impact of 347 this action is limited. CA2 has been unaware of the change, but only 348 their ROA2 which is using the prefix is now invalidated: 350 TA CA Certificate: 351 Issuer: TA 352 Subject: TA 353 Profile: 6487 (regular) 354 Resources: 192.0.2.0/24, 198.51.100.0/24, 355 2001:db8::/32, AS64496-AS64500 357 CA1 CA Certificate: 358 Issuer: TA 359 Subject: CA1 360 Profile: 8360 (amended) 361 Resources: 192.0.2.0/24 362 2001:db8::/32, AS64496-AS64500 364 CA1 ROA 1: 365 Issuer: CA1 366 Subject: R1 367 Profile: 6487 (regular) 368 Resources: 192.0.2.0/24 370 ASN: 64496 371 Prefixes: 192.0.2.0/24 (Max 24) 373 CA2 CA Certificate: 374 Issuer: CA1 375 Subject: CA2 376 Profile: 8360 (amended) 377 Rejected: 198.51.100.0/24 378 Accepted: 2001:db8::/32, AS64496-AS64500 380 CA2 ROA 1: 381 Issuer: CA2 382 Subject: R1 383 Profile: 6487 (regular) 384 Resources: 2001:db8::/32 386 ASN: 64496 387 Prefixes: 2001:db8::/32 (Max 48) 389 CA2 ROA 2 (INVALID): 390 Issuer: CA2 391 Subject: R1 392 Profile: 6487 (regular) 393 Resources: 198.51.100.0/24 395 ASN: 64496 396 Prefixes: 198.51.100.0/24 (Max 24) 398 Now CA1 comes back online. It discovers that it lost the prefix 399 198.51.100.0/24. It will now re-issue the CA certificate issued to 400 CA2 immediately: 402 TA CA Certificate: 403 Issuer: TA 404 Subject: TA 405 Profile: 6487 (regular) 406 Resources: 192.0.2.0/24, 198.51.100.0/24, 407 2001:db8::/32, AS64496-AS64500 409 CA1 CA Certificate: 410 Issuer: TA 411 Subject: CA1 412 Profile: 8360 (amended) 413 Resources: 192.0.2.0/24 414 2001:db8::/32, AS64496-AS64500 416 CA1 ROA 1: 417 Issuer: CA1 418 Subject: R1 419 Profile: 6487 (regular) 420 Resources: 192.0.2.0/24 422 ASN: 64496 423 Prefixes: 192.0.2.0/24 (Max 24) 425 CA2 CA Certificate: 426 Issuer: CA1 427 Subject: CA2 428 Profile: 8360 (amended) 429 Resources: 2001:db8::/32, AS64496-AS64500 431 CA2 ROA 1: 432 Issuer: CA2 433 Subject: R1 434 Profile: 6487 (regular) 435 Resources: 2001:db8::/32 437 ASN: 64496 438 Prefixes: 2001:db8::/32 (Max 48) 440 CA2 ROA 2 (INVALID): 441 Issuer: CA2 442 Subject: R1 443 Profile: 6487 (regular) 444 Resources: 198.51.100.0/24 446 ASN: 64496 447 Prefixes: 198.51.100.0/24 (Max 24) 449 Finally CA2, who was trying to check in with CA1 even when it was 450 unavailable, discovers that it lost the prefix '198.51.100.0/24'. It 451 will therefore remove its ROA2: 453 TA CA Certificate: 454 Issuer: TA 455 Subject: TA 456 Profile: 6487 (regular) 457 Resources: 192.0.2.0/24, 198.51.100.0/24, 458 2001:db8::/32, AS64496-AS64500 460 CA1 CA Certificate: 461 Issuer: TA 462 Subject: CA1 463 Profile: 8360 (amended) 464 Resources: 192.0.2.0/24 465 2001:db8::/32, AS64496-AS64500 467 CA1 ROA 1: 468 Issuer: CA1 469 Subject: R1 470 Profile: 6487 (regular) 471 Resources: 192.0.2.0/24 473 ASN: 64496 474 Prefixes: 192.0.2.0/24 (Max 24) 476 CA2 CA Certificate: 477 Issuer: CA1 478 Subject: CA2 479 Profile: 8360 (amended) 480 Resources: 2001:db8::/32, AS64496-AS64500 482 CA2 ROA 1: 483 Issuer: CA2 484 Subject: R1 485 Profile: 6487 (regular) 486 Resources: 2001:db8::/32 488 ASN: 64496 489 Prefixes: 2001:db8::/32 (Max 48) 491 A few things to note: 493 o In this scenario CA1 was offline, and it was not performing the 494 actions required to the occurance of an overclaiming CA 495 certificate to remain for CA2 and CA2 was not aware of the coming 496 change. 498 o The use of the amened profile for reconsidered validation rules 499 limited the impact of this operational problem to just those 500 resources that were being removed. 502 o Had CA2 not only monitored its CA certificate eligibility directly 503 with its parent, but had they performed RPKI validation to monitor 504 their own certificate and products. Then they would have removed 505 their ROA2 sooner. Since CA1 was offline however, they would not 506 have been able to request a shrunk CA certificate for themselves. 508 o Had CA1 and CA2 both been online and TA observed the 24 hour grace 509 period, then things would have been changed without the occurance 510 of invalid objects or warnings. CA2 would have removed ROA2, and 511 then would have requested a shrunk CA certificate for itself. CA1 512 would have noticed that it was safe to reques its own CA 513 certificate to be shrunk. The CA depth here is 2, so this would 514 have happened within 2 hours, well within the 24 hours limit. 516 5. RFC-EDITOR Considerations 518 The exact year value TBD-Year and TBD-Year +1 are to be defined in WG 519 process and will be set before WGLC 521 6. Security Considerations 523 TBD 525 7. Acknowledgements 527 TBD 529 8. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, 534 . 536 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 537 X.509 PKIX Resource Certificates", RFC 6487, 538 DOI 10.17487/RFC6487, February 2012, 539 . 541 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 542 Protocol for Provisioning Resource Certificates", 543 RFC 6492, DOI 10.17487/RFC6492, February 2012, 544 . 546 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 547 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 548 DOI 10.17487/RFC6919, April 2013, 549 . 551 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 552 "Resource Public Key Infrastructure (RPKI) Trust Anchor 553 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 561 Newton, A., and D. Shaw, "Resource Public Key 562 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 563 DOI 10.17487/RFC8360, April 2018, 564 . 566 Authors' Addresses 568 George G. Michaelson 569 Asia Pacific Network Information Centre 570 6 Cordelia St 571 South Brisbane, QLD 4101 572 Australia 574 Email: ggm@apnic.net 576 Tim Bruijnzeels 577 Open Netlabs B.V. 578 Science Park 400 579 Amsterdam 1098 XH 580 The Netherlands 582 Email: timb@opennetlabs.nl