Internet DRAFT - draft-va-sidrops-deploy-reconsidered
draft-va-sidrops-deploy-reconsidered
Network Working Group G. Michaelson
Internet-Draft APNIC
Intended status: Experimental T. Bruijnzeels
Expires: September 8, 2019 opennetlabs
March 7, 2019
Deployment of Reconsidered Validation in the Resource Public Key
Infrastructure (RPKI)
draft-va-sidrops-deploy-reconsidered-01
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 September 8, 2019.
Copyright Notice
Copyright (c) 2019 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 & BruijnzeelsExpires September 8, 2019 [Page 1]
Internet-Draft deploy-reconsidered March 2019
(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 . . . . 5
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 . . . . . . . . . . 6
3.2. Self monitoring and clean-up . . . . . . . . . . . . . . 6
4. Mixed mode operations . . . . . . . . . . . . . . . . . . . . 7
5. Example use of the amended profile with transfers . . . . . . 7
6. RFC-EDITOR Considerations . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Revision History . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. 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
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 2]
Internet-Draft deploy-reconsidered March 2019
algorithm. This document stipulates that RP software MUST support
[RFC8360] by 1 July TBD-Year. After 1 July TBD-Year Certificate
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.
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 3]
Internet-Draft deploy-reconsidered March 2019
The use of the amended certificate profile communicates that over-
claims for this particular certificate can occur, and if they do,
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.
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 4]
Internet-Draft deploy-reconsidered March 2019
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].
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.
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 5]
Internet-Draft deploy-reconsidered March 2019
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].
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
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 6]
Internet-Draft deploy-reconsidered March 2019
the CA MUST request a new CA certificate to be issued by their parent
CA.
4. Mixed mode operations
Since there is no clear intention to have a "flag day" and move all
RP systems to a new OID and a new mode of operation the question
arises: what is the mode of operation of an RPKI system where both
OID exist concurrently?
In mixed-mode, the application of the OID is taken to refer to the CA
certificate itself: The value is set by the issuer, and might
represent a default inherited value.
Should a CA be signed over with the old OID, its validation MUST
follow the old OID. if a certficate is signed over with the new OID,
its validation MUST follow the new OID. Therefore, ether situation
can be expected but the intent is understood to apply to that
certificate in the path.
The application of the OID applies to the certificate in hand, not
the children. This permits a "strict" OID to have a "lax" OID child,
which is the only pattern of issuance which has a risk of mis-
interpretation.
+-----+--------------+---------------------------+
| OID | State | Consequence in tree below |
+-----+--------------+---------------------------+
| old | no overclaim | tree is valid |
| old | overclaiming | tree is invalid |
| new | no overclaim | tree is valid |
| new | overclaiming | tree is valid when pruned |
+-----+--------------+---------------------------+
5. 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
issues a ROA and delegates some resources to CA2, which in turn also
issues a ROA:
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 7]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 8]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 9]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 10]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 11]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 12]
Internet-Draft deploy-reconsidered March 2019
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 & BruijnzeelsExpires September 8, 2019 [Page 13]
Internet-Draft deploy-reconsidered March 2019
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.
6. 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
7. Security Considerations
TBD
8. Revision History
01 - mixed-mode operation text. 2019 00 - Initial draft. 2018
9. Acknowledgements
This draft is a product of conversations in the RIR/NRO Engineering
Coordination Group.
10. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
Michaelson & BruijnzeelsExpires September 8, 2019 [Page 14]
Internet-Draft deploy-reconsidered March 2019
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates",
RFC 6492, DOI 10.17487/RFC6492, February 2012,
<https://www.rfc-editor.org/info/rfc6492>.
[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,
<https://www.rfc-editor.org/info/rfc6919>.
[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,
<https://www.rfc-editor.org/info/rfc7730>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8360>.
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 & BruijnzeelsExpires September 8, 2019 [Page 15]
