Network Working Group G. Michaelson Internet-Draft APNIC Intended status: Experimental T. Bruijnzeels Expires: April 22, 2019 opennetlabs October 19, 2018 Deployment of Reconsidered Validation in the Resource Public Key Infrastructure (RPKI) draft-va-sidrops-deploy-reconsidered-00 Abstract This document defines a deployment model for reconsidered validation [RFC8360] in the Resource Public Key Infrastructure (RPKI). It stipulates that Relying Parties in the RPKI MUST support reconsidered validation by 1 July TBD-Year, and that Certificate Authorities MAY use the reconsidered validation OIDs in CA certificates that they issue from this date. Furthermore Certificate Authorities should monitor whether the set of resources in CA certificate they receive has shrunk, and make adjustments in the CA certificates and/or other RPKI objects when appropriate. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Michaelson & Bruijnzeels Expires April 22, 2019 [Page 1] Internet-Draft deploy-reconsidered October 2018 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Phased Deployment of the Amended Certificate Profile . . . . 3 2.1. Phase 1: Requirements for RP Software . . . . . . . . . . 4 2.2. Phase 2: Requirements for operators . . . . . . . . . . . 4 2.3. Phase 3: Requirements for Certificate Authorities . . . . 4 3. Avoid over-claiming CA certificates . . . . . . . . . . . . . 5 3.1. Avoid Invalidating Delegated CAs . . . . . . . . . . . . 5 3.1.1. Graceperiod and Check Intervals . . . . . . . . . . . 5 3.1.2. Shrinking issued CA certificates . . . . . . . . . . 5 3.2. Self monitoring and clean-up . . . . . . . . . . . . . . 6 4. Example use of the amended profile with transfers . . . . . . 6 5. RFC-EDITOR Considerations . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Overview This document defines a deployment model for reconsidered validation [RFC8360] in the Resource Public Key Infrastructure (RPKI). Reconsidered validation differs from normal validation [RFC6487] in that under reconsidered rules the intersection of resources between a child certificate and the resources contained in the (chain of) parent certificate(s) is accepted. Any resources that are contained in the child certificate only result in a warning about these resources, rather than the rejection of that certificate. Thus reconsidered validation limits the impact of over-claims in the RPKI to the set of resources under dispute. The applicability of reconsidered validation is signalled by the use of a distinct set of OIDs on a Resource Certificate [RFC8360]. Because of this reconsidered validation can only be deployed when a majority of Relying Party software is updated to support this new algorithm. This document stipulates that RP software MUST support [RFC8360] by 1 July TBD-Year. After 1 July TBD-Year Certificate Michaelson & Bruijnzeels Expires April 22, 2019 [Page 2] Internet-Draft deploy-reconsidered October 2018 Authorities MAY start to use [RFC8360] in CA certificates that they issue. Note that the use of reconsidered validation is restricted to CA Certificates only. Issuing Certificate Authorities may (be forced to) re-issue delegated CA certificates with shrunk resource pro- actively, and therefore it's at the CA certificate level that mismatches between resources actually included on such a certificate and the resources the recipient believes to be included on these certificates may occur. On the other hand, ROA and BGPSec Router Certificate reconsidered validation still requires that all resources are also held by the path of parent certificates to these objects. In other words, using the reconsidered validation here is unneccessary. Furthermore, Certificate Authorities should monitor pro-actively whether the set of resources in the CA certificate they received has been shrunk by their parent. Resource Certificates that they in turn issue that use resources no longer validly held by them should be shrunk or revoked. BGPSec Router Certificates or ROAs that use such resources should be removed. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Phased Deployment of the Amended Certificate Profile There is an existing BCP document that describes an algorithm agility procedure for the RPKI [RFC6919]. This procedure involves four distinct phases with requirements for CAs and RPs. During this process the entire RPKI tree is essentially duplicated, and two disctinct trees are maintained in paralel for some time, until the old tree can be withdrawn. The dates for each milestones are expected to be documented in a BCP. In this case however, the amended validation process is very similar to the existing validation process. Moreover, as [RFC8360] describes there is no fundamental issue in having an RPKI tree in which a mix of regular [RFC6487] and amended [RFC8360] certificates can be found. The use of the amended certificate profile communicates that over- claims for this particular certificate can occur, and if they do, Michaelson & Bruijnzeels Expires April 22, 2019 [Page 3] Internet-Draft deploy-reconsidered October 2018 that their impact should be limited to the resources that are in over-claim. Sections 4.2.5 and 4.2.6 of [RFC8360] stipulate that such over-claims on the EE certificate would invalidate ROA and BGPSec Router Certificates. In conclusion the amended certificate profile MUST only be used on CA certificates for CA organisations where an overclaim may accidentally occur, and MUST NOT be used anywhere else: e.g. on a TA CA certificate which by definition cannot overclaim, or on any specific attestation about resources other than a delegation to another CA, e.g. ROAs and BGPSec Router Certificates. So, contrary to the process described in [RFC6919] there is no desired outcome here to completely replace an existing algorithm with a new algorithm. And consequently a different approach to the deployment phases is applicable here. We recognise the following phases: 1. Relying Party software MUST support the amended profile 2. Operators MUST use updated Relying Party software; 3. Certificate Authorities MAY use the amended profile As suggested in [RFC6919] the dates for each of these phases can be documented in this BCP: 1. 1 July TBD-Year 2. 1 July TBD-Year - 1 January TBD-Year +1 3. 1 January TBD-Year +1 2.1. Phase 1: Requirements for RP Software Relying Party software MUST support [RFC8360] by 1 July TBD-Year. 2.2. Phase 2: Requirements for operators Network operators MUST update their Relying Party software between 1 July TBD-Year and 1 January TBD-Year +1. 2.3. Phase 3: Requirements for Certificate Authorities Trust Anchor CA certificates referenced in Trust Anchor Locator (TAL) files [RFC7730] MUST NOT make use of amended Resource Certificates defined in [RFC8360]. Michaelson & Bruijnzeels Expires April 22, 2019 [Page 4] Internet-Draft deploy-reconsidered October 2018 From 1 January 2020 Certificate Authorities MAY use amended Resource Certificates [RFC8360] for CA certificates that they issue to delegated Certificate Authorities. Certificate Authorities MUST NOT use the amended Resource Certificate profile for any other certificates they issue. 3. Avoid over-claiming CA certificates Even though the amended profile limits the impact of resource over- claims on CA certificates, this does not mean that such over-claims are intended to become the norm. As we will describe in the following sections: o Issuing CAs should try to avoid invalidating delegated CAs o Delegated CAs should self-monitor and take action in case resources are removed 3.1. Avoid Invalidating Delegated CAs 3.1.1. Graceperiod and Check Intervals If resources need to be removed from a delegated CA it is reasonable to observe a graceperiod that will allow a delegated CA (and recursively their delegated CAs if applicable) to clean up objects. A reasonable duration for this period depends on the following factors: o The frequency that a child CA can check with its parents about its CA certificate eligibility (Check Interval) o The depth of the tree of delegated CAs We believe that it's reasonable to require the child CAs MUST issue a Resource Class List Query [RFC6492] to their parent CA no less frequently than once per houri (Check Interval). It is not expected that the depth of delegated CA certificates will exceed 5 or 6 CA authorities. In conclusion a graceperiod of 24 hours seems reasonable. 3.1.2. Shrinking issued CA certificates When a Certificate Authority finds that it needs to shrink the set of resources held by a delegated Certificate Authority, but still holds the resources to be removed on its own CA certificate, then it SHOULD give the delegated Certificate Authority up to 24 hours to request a shrunk CA certificate, e.g. through the provision protocol [RFC6492]. Michaelson & Bruijnzeels Expires April 22, 2019 [Page 5] Internet-Draft deploy-reconsidered October 2018 The CA SHOULD issue a new CA certificate immediately using a "notAfter" time that is set to whichever is soonest: 24 hours from now, or the "notAfter" time on the CA certificate held by this issuing CA. This will alert the delegated CA of both the limited lifetime of their current CA certificate, and which resources remain eligible after this time, when the delegated CA sends a Resource Class List Query [RFC6492]. If the Certificate Authority no longer holds the resources that are to be removed, or this 24 hour period has passed, then a shrunk CA certificate MUST be issued. Such shrunk certificate SHOULD use the amended Resource Certificate profile in order to limit the impact in the validation of objects issued by the subsidiary Certificate Authority. 3.2. Self monitoring and clean-up CAs in the RPKI MUST monitor whether the CA certificate issued to them by their parent needs to be shrunk, for example by sending a Resource Class List Query [RFC6492] to their parent CA no less frequently than once per hour. If the CA finds that a reduced resource set is in order, but their current certificate is still valid, and they have issued delegated CA certificates with the resources to be reduced to delegated CAs, then they SHOULD give these delegated CAs up to 24 hours, or the time until 1 hour before their own CA certificate "notAfter" time if this period is shorter, to request a shrunk CA certificate as described above. The CA MUST now remove any other RPKI objects that it issued that reference any of the resources to be removed. If the CA issued ROAs that reference multiple prefixes, and some of these prefixes are not to be removed, then the CA SHOULD create new ROAs for these prefixes and use one ROA object per prefix rather than bundling multiple prefixes on a single ROA object. If the CA no longer issues any CA certificates or RPKI objects referencing the resources to be removed, or it finds that its current CA certificate is no longer valid or will expire within 1 hour, then the CA MUST request a new CA certificate to be issued by their parent CA. 4. Example use of the amended profile with transfers Consider the following starting situation where a Trust Anchor issues a resource certificate to Certificate Auhtority CA1, which in turn Michaelson & Bruijnzeels Expires April 22, 2019 [Page 6] Internet-Draft deploy-reconsidered October 2018 issues a ROA and delegates some resources to CA2, which in turn also issues a ROA: Michaelson & Bruijnzeels Expires April 22, 2019 [Page 7] Internet-Draft deploy-reconsidered October 2018 TA CA Certificate: Issuer: TA Subject: TA Profile: 6487 (regular) Resources: 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 CA1 CA Certificate: Issuer: TA Subject: CA1 Profile: 8360 (amended) Resources: 192.0.2.0/24, 198.51.100.0/24 2001:db8::/32, AS64496-AS64500 CA1 ROA 1: Issuer: CA1 Subject: R1 Profile: 6487 (regular) Resources: 192.0.2.0/24 ASN: 64496 Prefixes: 192.0.2.0/24 (Max 24) CA2 CA Certificate: Issuer: CA1 Subject: CA2 Profile: 8360 (amended) Resources: 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 CA2 ROA 1: Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 2001:db8::/32 ASN: 64496 Prefixes: 2001:db8::/32 (Max 48) CA2 ROA 2: Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 198.51.100.0/24 ASN: 64496 Prefixes: 198.51.100.0/24 (Max 24) Michaelson & Bruijnzeels Expires April 22, 2019 [Page 8] Internet-Draft deploy-reconsidered October 2018 Now assume that the TA decides that CA1 should no longer hold the prefix 198.51.100.0/24. However, CA1 is offline for some reason and it does not check in with TA about its CA certificate eligibility. After 24 hours TA will decided that it has waited long enough and it will now pro-actively issue an amended CA certificate for CA1. Because the amended profile is used for CA certificates the impact of this action is limited. CA2 has been unaware of the change, but only their ROA2 which is using the prefix is now invalidated: Michaelson & Bruijnzeels Expires April 22, 2019 [Page 9] Internet-Draft deploy-reconsidered October 2018 TA CA Certificate: Issuer: TA Subject: TA Profile: 6487 (regular) Resources: 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 CA1 CA Certificate: Issuer: TA Subject: CA1 Profile: 8360 (amended) Resources: 192.0.2.0/24 2001:db8::/32, AS64496-AS64500 CA1 ROA 1: Issuer: CA1 Subject: R1 Profile: 6487 (regular) Resources: 192.0.2.0/24 ASN: 64496 Prefixes: 192.0.2.0/24 (Max 24) CA2 CA Certificate: Issuer: CA1 Subject: CA2 Profile: 8360 (amended) Rejected: 198.51.100.0/24 Accepted: 2001:db8::/32, AS64496-AS64500 CA2 ROA 1: Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 2001:db8::/32 ASN: 64496 Prefixes: 2001:db8::/32 (Max 48) CA2 ROA 2 (INVALID): Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 198.51.100.0/24 ASN: 64496 Prefixes: 198.51.100.0/24 (Max 24) Michaelson & Bruijnzeels Expires April 22, 2019 [Page 10] Internet-Draft deploy-reconsidered October 2018 Now CA1 comes back online. It discovers that it lost the prefix 198.51.100.0/24. It will now re-issue the CA certificate issued to CA2 immediately: Michaelson & Bruijnzeels Expires April 22, 2019 [Page 11] Internet-Draft deploy-reconsidered October 2018 TA CA Certificate: Issuer: TA Subject: TA Profile: 6487 (regular) Resources: 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 CA1 CA Certificate: Issuer: TA Subject: CA1 Profile: 8360 (amended) Resources: 192.0.2.0/24 2001:db8::/32, AS64496-AS64500 CA1 ROA 1: Issuer: CA1 Subject: R1 Profile: 6487 (regular) Resources: 192.0.2.0/24 ASN: 64496 Prefixes: 192.0.2.0/24 (Max 24) CA2 CA Certificate: Issuer: CA1 Subject: CA2 Profile: 8360 (amended) Resources: 2001:db8::/32, AS64496-AS64500 CA2 ROA 1: Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 2001:db8::/32 ASN: 64496 Prefixes: 2001:db8::/32 (Max 48) CA2 ROA 2 (INVALID): Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 198.51.100.0/24 ASN: 64496 Prefixes: 198.51.100.0/24 (Max 24) Michaelson & Bruijnzeels Expires April 22, 2019 [Page 12] Internet-Draft deploy-reconsidered October 2018 Finally CA2, who was trying to check in with CA1 even when it was unavailable, discovers that it lost the prefix '198.51.100.0/24'. It will therefore remove its ROA2: TA CA Certificate: Issuer: TA Subject: TA Profile: 6487 (regular) Resources: 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 CA1 CA Certificate: Issuer: TA Subject: CA1 Profile: 8360 (amended) Resources: 192.0.2.0/24 2001:db8::/32, AS64496-AS64500 CA1 ROA 1: Issuer: CA1 Subject: R1 Profile: 6487 (regular) Resources: 192.0.2.0/24 ASN: 64496 Prefixes: 192.0.2.0/24 (Max 24) CA2 CA Certificate: Issuer: CA1 Subject: CA2 Profile: 8360 (amended) Resources: 2001:db8::/32, AS64496-AS64500 CA2 ROA 1: Issuer: CA2 Subject: R1 Profile: 6487 (regular) Resources: 2001:db8::/32 ASN: 64496 Prefixes: 2001:db8::/32 (Max 48) A few things to note: o In this scenario CA1 was offline, and it was not performing the actions required to the occurance of an overclaiming CA certificate to remain for CA2 and CA2 was not aware of the coming change. Michaelson & Bruijnzeels Expires April 22, 2019 [Page 13] Internet-Draft deploy-reconsidered October 2018 o The use of the amened profile for reconsidered validation rules limited the impact of this operational problem to just those resources that were being removed. o Had CA2 not only monitored its CA certificate eligibility directly with its parent, but had they performed RPKI validation to monitor their own certificate and products. Then they would have removed their ROA2 sooner. Since CA1 was offline however, they would not have been able to request a shrunk CA certificate for themselves. o Had CA1 and CA2 both been online and TA observed the 24 hour grace period, then things would have been changed without the occurance of invalid objects or warnings. CA2 would have removed ROA2, and then would have requested a shrunk CA certificate for itself. CA1 would have noticed that it was safe to reques its own CA certificate to be shrunk. The CA depth here is 2, so this would have happened within 2 hours, well within the 24 hours limit. 5. RFC-EDITOR Considerations The exact year value TBD-Year and TBD-Year +1 are to be defined in WG process and will be set before WGLC 6. Security Considerations TBD 7. Acknowledgements TBD 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, . Michaelson & Bruijnzeels Expires April 22, 2019 [Page 14] Internet-Draft deploy-reconsidered October 2018 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, . [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., Newton, A., and D. Shaw, "Resource Public Key Infrastructure (RPKI) Validation Reconsidered", RFC 8360, DOI 10.17487/RFC8360, April 2018, . Authors' Addresses George G. Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Email: ggm@apnic.net Tim Bruijnzeels Open Netlabs B.V. Science Park 400 Amsterdam 1098 XH The Netherlands Email: timb@opennetlabs.nl Michaelson & Bruijnzeels Expires April 22, 2019 [Page 15]