From 7e5c5bf25ef50b3b09a5af6f3d173a187ee31c5a Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Thu, 21 May 2020 12:56:49 -0700 Subject: [PATCH] Steve Kent rewrite --- draft-ymbk-sidrops-6486bis.txt | 542 ++++++++++++--------------------- draft-ymbk-sidrops-6486bis.xml | 472 +++++++++------------------- 2 files changed, 335 insertions(+), 679 deletions(-) diff --git a/draft-ymbk-sidrops-6486bis.txt b/draft-ymbk-sidrops-6486bis.txt index 0d73bf8..16c0fb5 100644 --- a/draft-ymbk-sidrops-6486bis.txt +++ b/draft-ymbk-sidrops-6486bis.txt @@ -6,11 +6,11 @@ Network Working Group R. Austein Internet-Draft Arrcus, Inc. Updates: 6486 (if approved) G. Huston Intended status: Standards Track APNIC -Expires: November 6, 2020 S. Kent +Expires: November 22, 2020 S. Kent Independent M. Lepinski New College Florida - May 5, 2020 + May 21, 2020 Manifests for the Resource Public Key Infrastructure (RPKI) @@ -48,12 +48,12 @@ Status of This Memo 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 November 6, 2020. + This Internet-Draft will expire on November 22, 2020. -Austein, et al. Expires November 6, 2020 [Page 1] +Austein, et al. Expires November 22, 2020 [Page 1] Internet-Draft RPKI Manifests May 2020 @@ -89,27 +89,27 @@ Table of Contents 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 5.2. Considerations for Manifest Generation . . . . . . . . . 9 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . 9 - 6.1. Tests for Determining Manifest State . . . . . . . . . . 10 - 6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 11 - 6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 12 - 6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 13 - 6.5. Mismatch between Manifest and Publication Point . . . . . 14 - 6.6. Hash Values Not Matching Manifests . . . . . . . . . . . 14 - 7. Publication Repositories . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 11.2. Informative References . . . . . . . . . . . . . . . . . 17 - Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 10 + 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 + 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11 + 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 11 + 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 + 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 + 6.7. Termination of Processing . . . . . . . . . . . . . . . . 12 + 7. Publication Repositories . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 11.2. Informative References . . . . . . . . . . . . . . . . . 15 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 - -Austein, et al. Expires November 6, 2020 [Page 2] +Austein, et al. Expires November 22, 2020 [Page 2] Internet-Draft RPKI Manifests May 2020 @@ -165,7 +165,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 3] +Austein, et al. Expires November 22, 2020 [Page 3] Internet-Draft RPKI Manifests May 2020 @@ -221,7 +221,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 4] +Austein, et al. Expires November 22, 2020 [Page 4] Internet-Draft RPKI Manifests May 2020 @@ -277,7 +277,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 5] +Austein, et al. Expires November 22, 2020 [Page 5] Internet-Draft RPKI Manifests May 2020 @@ -333,7 +333,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 6] +Austein, et al. Expires November 22, 2020 [Page 6] Internet-Draft RPKI Manifests May 2020 @@ -389,7 +389,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 7] +Austein, et al. Expires November 22, 2020 [Page 7] Internet-Draft RPKI Manifests May 2020 @@ -445,7 +445,7 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 8] +Austein, et al. Expires November 22, 2020 [Page 8] Internet-Draft RPKI Manifests May 2020 @@ -495,325 +495,168 @@ Internet-Draft RPKI Manifests May 2020 6. Relying Party Use of Manifests - The goal of an RP is to determine which signed objects to use for + Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to - use in the construction of route filters). Ultimately, this + use in the construction of route filters). Manifests are designed to -Austein, et al. Expires November 6, 2020 [Page 9] +Austein, et al. Expires November 22, 2020 [Page 9] Internet-Draft RPKI Manifests May 2020 - selection is a matter of local policy. However, in the following - sections, we describe a sequence of tests that the RP SHOULD perform - to determine the manifest state of the given publication point. We - then discuss the risks associated with using signed objects in the - publication point, given the manifest state; we also provide suitable - warning text that SHOULD be placed in a user-accessible log file. It - is the responsibility of the RP to weigh these risks against the risk - of routing failure that could occur if valid data is rejected, and to - implement a suitable local policy. Note that if a certificate is - deemed unfit for use due to local policy, then any signed object that - is validated using this certificate also SHOULD be deemed unfit for - use (regardless of the status of the manifest at its own publication - point). + allow an RP to detect manipulation of repository data and/or errors + by a CA or repository manager. Unless _all_ of the files enumerated + in a manifest can be obtained by an RP (either from a publication + point or from a local cache), an RP MUST ignore the data associated + with the publication point. This stringent response is needed to + prevent an RP from misinterpreting data associated with a publication + point, and thus possibly treating invalid routes as valid, or vice + versa. -6.1. Tests for Determining Manifest State + The processing described below is designed to cause all RPs with + access to the same local cache and RPKI repository data to achieve + the same results with regard to validation of RPKI data. However, in + operation, different RPs will access repositories at different times, + and some RPs may experience local cache failures, so there is no + guarantee that all RPs will achieve the same results with regard to + validation of RPKI data - For a given publication point, the RP SHOULD perform the following - tests to determine the manifest state of the publication point: + Note that there is a "chicken and egg" relationship between the + manifest and the CRL for a given CA instance. If the EE certificate + for the current manifest is revoked, i.e., it appears in the current + CRL, then the CA or publication point manager has made a serious + error. In this case all signed objects associated with the CA + instance MUST be ignored. Similarly, if the CRL is not listed on a + valid, current manifest, all signed objects associated with the CA + instance MUST be ignored, because the CRL is considered missing. - 1. For each CA using this publication point, select the CA's current - manifest (the "current" manifest is the manifest issued by this - CA having the highest manifestNumber among all valid manifests, - and where manifest validity is defined in Section 4.4). +6.1. Manifest Processing Overview - If the publication point does not contain a valid manifest, see - Section 6.2. Lacking a valid manifest, the following tests - cannot be performed. + For a given publication point, an RP MUST perform a series of tests + to determine which signed object files at the publication point are + acceptable. The tests described below are to be performed using the + manifest identified by the id-ad-rpkiManifest URI extracted from a CA + certificate's SIA. - 2. To verify completeness, an RP MAY check that every file at each - publication point appears in one and only one current manifest, - and that every file listed in a current manifest is published at - the same publication point as the manifest. + 1. All of the files referenced by the manifest MUST be be located at + the publication point specified by the id-ad-caRepository URI + from the (same) certificate's SIA. If the manifest and the files + it references do not reside at the same publication point, an RP + MUST *???* - If there exist files at the publication point that do not appear - on any manifest, or files listed in a manifest that do not appear - at the publication point, then see Section 6.5, but still - continue with the following test. + 2. A manifest SHOULD contain exactly one CRL (.crl) file and it MUST + be at the location specified in the CRLDP in the manifest's EE + certificate. - 3. Check that the current time (translated to UTC) is between - thisUpdate and nextUpdate. + 3. If more than one .crl file appears in the manifest, only file + names matching the CRL specified by the CRLDP will be processed. + If more than one .crl entry appears in the manifest, and matches - If the current time does not lie within this interval, then see - Section 6.4, but still continue with the following tests. - 4. Verify that the listed hash value of every file listed in each - manifest matches the value obtained by hashing the file at the + + +Austein, et al. Expires November 22, 2020 [Page 10] + +Internet-Draft RPKI Manifests May 2020 + + + the CRLDP, the first one encountered MUST be used. Any other + .crl files MUST be ignored and a warning MUST be issued. + + 4. Note that, during CA key rollover [RFC6489], signed objects for + two or more different CA instances will appear at the same publication point. + 5. Manifest processing is to be performed separately for each CA + instance, guided by the SIA id-ad-rpkiManifest URI in each CA + certificate. + + 6. Note also that the processing described here will be performed + using locally cached files if an RP does not detect newer + versions of the files in the RPKI repository system. + +6.2. Acquiring a Manifest for a CA + + Acquire the manifest identified by the SIA id-ad-rpkiManifest URI in + the CA certificate. If an RP cannot retrieve a manifest using this + URI, or if the manifest is not valid (Section 4.4), an RP SHOULD + examine the most recent, cached manifest matching this URI. If that + manifest is current (Section 4.4) proceed to Section 6.3. If the + publication point does not contain a valid manifest, and the cached + manifest is not current, proceed to Section 6.7. + +6.3. Detecting Stale and or Prematurely-issued Manifests + + Check that the current time (translated to UTC) is between thisUpdate + and nextUpdate. If the current time lies within this interval, + proceed to Section 6.4. If the current time is earlier than + thisUpdate, the CA has made an error. If the RP cache contains a + current manifest, use that manifest instead and issue a warning. If + an RP has no access to a current manifest, processing stops and a + warning MUST be issued. If the current time is later than + nextUpdate, then the manifest is stale. If the RP cache contains a + current manifest, use that manifest instead and issue a warning.If no + current manifest is available, proceed to Section 6.7. + +6.4. Acquiring Files Referenced by a Manifest + + Acquire all files enumerated in the manifest (fileList) from the + publication point. This includes the CRL, each object containing an + EE certificate issued by the C, and all subordinate CA and EE + certificates. If there are files listed in the manifest that cannot + be retrieved from the publication point, or if they fail the validity + tests specified in [RFC6488], the RP SHOULD examine its cache to + determine if these files are available locally. If all of the + missing/invalid files are available from the RP's cache, i.e., each -Austein, et al. Expires November 6, 2020 [Page 10] +Austein, et al. Expires November 22, 2020 [Page 11] Internet-Draft RPKI Manifests May 2020 - If the computed hash value of a file listed on the manifest does - not match the hash value contained in the manifest, then see - Section 6.6. + file name matches the list extracted from the manifest, the RP SHOULD + use the cached files to replace those missing from the publication + point, and proceed to Section 6.5. However, if _any_ of the missing/ + invalid files cannot be replaced in this fashion, then proceed to + Section 6.7. - 5. An RP MAY check that the contents of each current manifest - conforms to the manifest's scope constraints, as specified in - Section 2. +6.5. Matching File Names and Hashes - 6. If a current manifest contains entries for objects that are not - within the scope of the manifest, then the out-of-scope entries - SHOULD be disregarded in the context of this manifest. If there - is no other current manifest that describes these objects within - that other manifest's scope, then see Section 6.2. + Verify that the hash value of every file listed in the manifest + matches the value obtained by hashing the file acquired from the + publication point or local cache. If the computed hash value of a + file listed on the manifest does not match the hash value contained + in the manifest, then an RP SHOULD examine its local cache to + determine if the same file is available. The RP SHOULD use cached + files to replace any (damaged) downloaded files, so long as the hash + of the cached file matches the hash from the manifest. If any of the + files with hash mismatches cannot be replaced in this fashion, + proceed to 6.7. Otherwise proceed to Section 6.6. - For each signed object, if all of the following - conditions hold: +6.6. Out of Scope Manifest Entries + If a current manifest contains entries for objects that are not + within the scope of the manifest (Section 2), then the out-of-scope + entries MUST be disregarded. - + the manifest for its publication and the associated - publication point pass all of the above checks; +6.7. Termination of Processing - + the signed object is valid; and + If an RP cannot acquire a current, valid manifest, or acquire + current, valid instances of all of the objects enumerated in a + current valid manifest, then processing of the signed objects + associated with the CA has failed. The RP MUST issue a warning + indicating the reason(s) for termination of processing with regard to + this CA. - + the manifests for every certificate on the certification - path used to validate the signed object and the associated - publication points pass all of the above checks; - - then the RP can conclude that no attack against the repository system - has compromised the given signed object, and the signed object MUST - be treated as valid (relative to manifest checking). - -6.2. Missing Manifests - - The absence of a current manifest at a publication point could occur - due to an error by the publisher or due to (malicious or accidental) - deletion or corruption of all valid manifests. - - When no valid manifest is available, there is no protection against - attacks that delete signed objects or replay old versions of signed - objects. All signed objects at the publication point, and all - descendant objects that are validated using a certificate at this - publication point, SHOULD be viewed as suspect, but MAY be used by - the RP, as per local policy. - - The primary risk in using signed objects at this publication point is - that a superseded (but not stale) CRL would cause an RP to improperly - accept a revoked certificate as valid (and thus rely upon signed - objects that are validated using that certificate). This risk is - - - -Austein, et al. Expires November 6, 2020 [Page 11] - -Internet-Draft RPKI Manifests May 2020 - - - somewhat mitigated if the CRL for this publication point has a short - time between thisUpdate and nextUpdate (and the current time is - within this interval). The risk in discarding signed objects at this - publication point is that an RP may incorrectly discard a large - number of valid objects. This gives significant power to an - adversary that is able to delete a manifest at the publication point. - - Regardless of whether signed objects from this publication are deemed - fit for use by an RP, this situation SHOULD result in a warning to - the effect that: "No manifest is available for , and - thus there may have been undetected deletions or replay substitutions - from the publication point." - - In the case where an RP has access to a local cache of previously - issued manifests that are valid, the RP MAY use the most recently - previously issued valid manifests for this RPKI repository - publication collection for each entity that publishes at this - publication point. - -6.3. Invalid Manifests - - The presence of an invalid manifest at a publication point could - occur due to an error by the publisher or due to (malicious or - accidental) corruption of a valid manifest. An invalid manifest MUST - never be used, even if the manifestNumber of the invalid manifest is - greater than that of other (valid) manifests. - - There are no risks associated with using signed objects at a - publication point containing an invalid manifest, provided that valid - manifests that collectively cover all the signed objects are also - present. - - If an invalid manifest is present at a publication point that also - contains one or more valid manifests, this situation SHOULD result in - a warning to the effect that: "An invalid manifest was found at , this indicates an attack against the publication point - or an error by the publisher. Processing for this publication point - will continue using the most recent valid manifest(s)." - - In the case where the RP has access to a local cache of previously - issued (valid) manifests, an RP MAY make use of that locally cached - data. Specifically, the RP MAY use the locally cached, most recent, - previously issued, valid manifest issued by the entity that (appears - to have) issued the invalid manifest. - - - - - - - -Austein, et al. Expires November 6, 2020 [Page 12] - -Internet-Draft RPKI Manifests May 2020 - - -6.4. Stale Manifests - - A manifest is considered stale if the current time is after the - nextUpdate time for the manifest. This could be due to publisher - failure to promptly publish a new manifest, or due to (malicious or - accidental) corruption or suppression of a more recent manifest. - - All signed objects at the publication point issued by the entity that - has published the stale manifest, and all descendant signed objects - that are validated using a certificate issued by the entity that has - published the stale manifest at this publication point, SHOULD be - viewed as somewhat suspect, but MAY be used by the RP as per local - policy. - - The primary risk in using such signed objects is that a newer - manifest exists that, if present, would indicate that certain objects - have been removed or replaced. (For example, the new manifest might - show the existence of a newer CRL and the removal of one or more - revoked certificates). Thus, the use of objects from a stale - manifest may cause an RP to incorrectly treat invalid objects as - valid. The risk is that the CRL covered by the stale manifest has - been superseded, and thus an RP will improperly treat a revoked - certificate as valid. This risk is somewhat mitigated if the time - between the nextUpdate field of the manifest and the current time is - short. The risk in discarding signed objects at this publication - point is that the RP may incorrectly discard a large number of valid - objects. This gives significant power to an adversary that is able - to prevent the publication of a new manifest at a given publication - point. - - Regardless of whether signed objects from this publication are deemed - fit for use by an RP, this situation SHOULD result in a warning to - the effect that: "A manifest found at is no longer - current. It is possible that undetected deletions have occurred at - this publication point." - - Note that there is also the potential for the current time to be - before the thisUpdate time for the manifest. This case could be due - to publisher error or a local clock error; in such a case, this - situation SHOULD result in a warning to the effect that: "A manifest - found at has an incorrect thisUpdate field. This - could be due to publisher error, or a local clock error, and - processing for this publication point will continue using this - otherwise valid manifest." - - - - - - - -Austein, et al. Expires November 6, 2020 [Page 13] - -Internet-Draft RPKI Manifests May 2020 - - -6.5. Mismatch between Manifest and Publication Point - - If there exist valid signed objects that do not appear in any - manifest, then, provided the manifest is not stale (see Section 6.4), - it is likely that their omission is an error by the publisher. It is - also possible that this state could be the result of a (malicious or - accidental) replacement of a current manifest with an older, but - still valid, manifest. However, regarding the appropriate - interpretation of such objects, it remains the case that if the - objects were intended to be invalid, then they should have been - revoked using whatever revocation mechanism is appropriate for the - signed object in question. Therefore, there is little risk in using - such signed objects. If the publication point contains a stale - manifest, then there is a greater risk that the objects in question - were revoked, along with a missing Certificate Revocation List (CRL), - the absence of which is undetectable since the manifest is stale. In - any case, the use of signed objects not present on a manifest, or - descendant objects that are validated using such signed objects, is a - matter of local policy. - - Regardless of whether objects not appearing on a manifest are deemed - fit for use by the RP, this situation SHOULD result in a warning to - the effect that: "The following files are present in the repository - at , but are not listed on any manifest - for ." - - If there exists files listed on the manifest that do not appear in - the repository, then these objects are likely to have been improperly - (via malice or accident) deleted from the repository. A primary - purpose of manifests is to detect such deletions. Therefore, in such - a case, this situation SHOULD result in a warning to the effect that: - "The following files that should have been present in the repository - at are missing . This indicates an - attack against this publication point, or the repository, or an error - by the publisher." - -6.6. Hash Values Not Matching Manifests - - A file appearing on a manifest with an incorrect hash value could - occur because of publisher error, but it also may indicate that an - attack has occurred. - - If an object appeared on a previous valid manifest with a correct - hash value, and it now appears with an invalid hash value, then it is - likely that the object has been superseded by a new (unavailable) - version of the object. If the object is used, there is a risk that - the RP will be treating a stale object as valid. This risk is more - significant if the object in question is a CRL. If the object can be - - - -Austein, et al. Expires November 6, 2020 [Page 14] - -Internet-Draft RPKI Manifests May 2020 - - - validated using the RPKI, the use of these objects is a matter of - local policy. - - If an object appears on a manifest with an invalid hash and has never - previously appeared on a manifest, then it is unclear whether the - available version of the object is more or less recent than the - version indicated by the manifest. If the manifest is stale (see - Section 6.4), then it becomes more likely that the available version - is more recent than the version indicated on the manifest, but this - is never certain. Whether to use such objects is a matter of local - policy. However, in general, it is better to use a possibly outdated - version of the object than to discard the object completely. - - While it is a matter of local policy, in the case of CRLs, an RP - SHOULD endeavor to use the most recently issued valid CRL, even where - the hash value in the manifest matches an older CRL or does not match - any available CRL for a CA instance. The thisUpdate field of the CRL - can be used to establish the most recent CRL in the case where an RP - has more than one valid CRL for a CA instance. - - Regardless of whether objects with incorrect hashes are deemed fit - for use by the RP, this situation SHOULD result in a warning to the - effect that: "The following files at the repository - appear on a manifest with incorrect hash values . It is - possible that these objects have been superseded by a more recent - version. It is very likely that this problem is due to an attack on - the publication point, although it also could be due to a publisher - error." + Termination or processing means that all of the ROAs and subordinate + certificates (CA and EE) MUST be considered invalid. This implies + that the RP MUST not try to acquire and validate _subordinate_ signed + objects, until the next interval when the RP is scheduled to process + data for this part of the RPKI repository system. 7. Publication Repositories @@ -824,6 +667,13 @@ Internet-Draft RPKI Manifests May 2020 always contain at least one entry, namely, the CRL issued by the CA upon repository creation [RFC6481]. + + +Austein, et al. Expires November 22, 2020 [Page 12] + +Internet-Draft RPKI Manifests May 2020 + + Every published signed object in the RPKI [RFC6488] is published in the repository publication point of the CA that issued the EE certificate, and is listed in the manifest associated with that CA @@ -834,14 +684,6 @@ Internet-Draft RPKI Manifests May 2020 Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RP to determine if a repository object has been deleted, occluded, or otherwise removed from view, or if a - - - -Austein, et al. Expires November 6, 2020 [Page 15] - -Internet-Draft RPKI Manifests May 2020 - - publication of a newer version of an object has been suppressed (and an older version of the object has been substituted). @@ -877,8 +719,16 @@ Internet-Draft RPKI Manifests May 2020 Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest - validation and RP behavior. The authors also wish to thank Sean - Turner for his helpful review of this document. + validation and RP behavior. The authors also wish to thank Job + Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of + this document. + + + +Austein, et al. Expires November 22, 2020 [Page 13] + +Internet-Draft RPKI Manifests May 2020 + 11. References @@ -889,15 +739,6 @@ Internet-Draft RPKI Manifests May 2020 DOI 10.17487/RFC2119, March 1997, . - - - - -Austein, et al. Expires November 6, 2020 [Page 16] - -Internet-Draft RPKI Manifests May 2020 - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List @@ -934,6 +775,17 @@ Internet-Draft RPKI Manifests May 2020 encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002. + + + + + + +Austein, et al. Expires November 22, 2020 [Page 14] + +Internet-Draft RPKI Manifests May 2020 + + 11.2. Informative References [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) @@ -945,15 +797,6 @@ Internet-Draft RPKI Manifests May 2020 DOI 10.17487/RFC3779, June 2004, . - - - - -Austein, et al. Expires November 6, 2020 [Page 17] - -Internet-Draft RPKI Manifests May 2020 - - [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . @@ -994,18 +837,7 @@ Appendix A. ASN.1 Module - - - - - - - - - - - -Austein, et al. Expires November 6, 2020 [Page 18] +Austein, et al. Expires November 22, 2020 [Page 15] Internet-Draft RPKI Manifests May 2020 @@ -1061,7 +893,7 @@ Authors' Addresses -Austein, et al. Expires November 6, 2020 [Page 19] +Austein, et al. Expires November 22, 2020 [Page 16] Internet-Draft RPKI Manifests May 2020 @@ -1117,4 +949,4 @@ Internet-Draft RPKI Manifests May 2020 -Austein, et al. Expires November 6, 2020 [Page 20] +Austein, et al. Expires November 22, 2020 [Page 17] diff --git a/draft-ymbk-sidrops-6486bis.xml b/draft-ymbk-sidrops-6486bis.xml index 8826014..78b22c0 100644 --- a/draft-ymbk-sidrops-6486bis.xml +++ b/draft-ymbk-sidrops-6486bis.xml @@ -574,378 +574,201 @@
- The goal of an RP is to determine which signed objects to use for + Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs - to use in the construction of route filters). Ultimately, this - selection is a matter of local policy. However, in the following - sections, we describe a sequence of tests that the RP SHOULD - perform to determine the manifest state of the given publication - point. We then discuss the risks associated with using signed - objects in the publication point, given the manifest state; we - also provide suitable warning text that SHOULD be placed in a - user-accessible log file. It is the responsibility of the RP to - weigh these risks against the risk of routing failure that could - occur if valid data is rejected, and to implement a suitable local - policy. Note that if a certificate is deemed unfit for use due to - local policy, then any signed object that is validated using this - certificate also SHOULD be deemed unfit for use (regardless of the - status of the manifest at its own publication point). + to use in the construction of route filters). Manifests are + designed to allow an RP to detect manipulation of repository data + and/or errors by a CA or repository manager. Unless _all_ of the + files enumerated in a manifest can be obtained by an RP (either + from a publication point or from a local cache), an RP MUST ignore + the data associated with the publication point. This stringent + response is needed to prevent an RP from misinterpreting data + associated with a publication point, and thus possibly treating + invalid routes as valid, or vice versa. -
+ + The processing described below is designed to cause all RPs with + access to the same local cache and RPKI repository data to achieve + the same results with regard to validation of RPKI data. However, + in operation, different RPs will access repositories at different + times, and some RPs may experience local cache failures, so there + is no guarantee that all RPs will achieve the same results with + regard to validation of RPKI data + + + + Note that there is a "chicken and egg" relationship between the + manifest and the CRL for a given CA instance. If the EE + certificate for the current manifest is revoked, i.e., it appears + in the current CRL, then the CA or publication point manager has + made a serious error. In this case all signed objects associated + with the CA instance MUST be ignored. Similarly, if the CRL is + not listed on a valid, current manifest, all signed objects + associated with the CA instance MUST be ignored, because the CRL + is considered missing. + + +
- For a given publication point, the RP SHOULD perform the - following tests to determine the manifest state of the - publication point: + For a given publication point, an RP MUST perform a series of + tests to determine which signed object files at the publication + point are acceptable. The tests described below are to be + performed using the manifest identified by the + id-ad-rpkiManifest URI extracted from a CA certificate's SIA. - + - - For each CA using this publication point, select the CA's - current manifest (the "current" manifest is the manifest - issued by this CA having the highest manifestNumber among - all valid manifests, and where manifest validity is defined - in ). If - the publication point does not contain a valid manifest, see - . Lacking a valid manifest, the - following tests cannot be performed. - + + All of the files referenced by the manifest MUST be be located + at the publication point specified by the id-ad-caRepository URI + from the (same) certificate's SIA. If the manifest and the + files it references do not reside at the same publication point, + an RP MUST *???* + - - To verify completeness, an RP MAY check that every file at - each publication point appears in one and only one current - manifest, and that every file listed in a current manifest - is published at the same publication point as the - manifest. If there exist files at - the publication point that do not appear on any manifest, or - files listed in a manifest that do not appear at the - publication point, then see , but - still continue with the following test. - + + A manifest SHOULD contain exactly one CRL (.crl) file and it + MUST be at the location specified in the CRLDP in the manifest's + EE certificate. + - - Check that the current time (translated to UTC) is between - thisUpdate and nextUpdate. If the - current time does not lie within this interval, then see - , but still continue with the - following tests. - + + If more than one .crl file appears in the manifest, only file + names matching the CRL specified by the CRLDP will be + processed. If more than one .crl entry appears in the manifest, + and matches the CRLDP, the first one encountered MUST be + used. Any other .crl files MUST be ignored and a warning MUST be + issued. + - - Verify that the listed hash value of every file listed in - each manifest matches the value obtained by hashing the file - at the publication point. If the - computed hash value of a file listed on the manifest does - not match the hash value contained in the manifest, then see - . - + + Note that, during CA key rollover [RFC6489], signed objects for + two or more different CA instances will appear at the same + publication point. + - - An RP MAY check that the contents of each current manifest - conforms to the manifest's scope constraints, as specified - in . - + + Manifest processing is to be performed separately for each CA + instance, guided by the SIA id-ad-rpkiManifest URI in each CA + certificate. + - - If a current manifest contains entries for objects that are - not within the scope of the manifest, then the out-of-scope - entries SHOULD be disregarded in the context of this - manifest. If there is no other current manifest that - describes these objects within that other manifest's scope, - then see . - - - - - - - - - - the manifest for its publication and the associated - publication point pass all of the above checks; - - - - the signed object is valid; and - - - - the manifests for every certificate on the - certification path used to validate the signed - object and the associated publication points pass - all of the above checks; - - - - - - - + + Note also that the processing described here will be performed + using locally cached files if an RP does not detect newer + versions of the files in the RPKI repository system. + +
+ +
+ - then the RP can conclude that no attack against the repository - system has compromised the given signed object, and the signed - object MUST be treated as valid (relative to manifest - checking). + Acquire the manifest identified by the SIA id-ad-rpkiManifest + URI in the CA certificate. If an RP cannot retrieve a manifest + using this URI, or if the manifest is not valid (Section 4.4), + an RP SHOULD examine the most recent, cached manifest matching + this URI. If that manifest is current () proceed to . If + the publication point does not contain a valid manifest, and the + cached manifest is not current, proceed to .
-
+
- The absence of a current manifest at a publication point could - occur due to an error by the publisher or due to (malicious or - accidental) deletion or corruption of all valid manifests. - - - - - When no valid manifest is available, there is no protection - against attacks that delete signed objects or replay old - versions of signed objects. All signed objects at the - publication point, and all descendant objects that are validated - using a certificate at this publication point, SHOULD be viewed - as suspect, but MAY be used by the RP, as per local policy. - - - - The primary risk in using signed objects at this publication - point is that a superseded (but not stale) CRL would cause an RP - to improperly accept a revoked certificate as valid (and thus - rely upon signed objects that are validated using that - certificate). This risk is somewhat mitigated if the CRL for - this publication point has a short time between thisUpdate and - nextUpdate (and the current time is within this interval). The - risk in discarding signed objects at this publication point is - that an RP may incorrectly discard a large number of valid - objects. This gives significant power to an adversary that is - able to delete a manifest at the publication point. - - - - Regardless of whether signed objects from this publication are - deemed fit for use by an RP, this situation SHOULD result in a - warning to the effect that: "No manifest is available for - <pub point name>, and thus there may have been undetected - deletions or replay substitutions from the publication point." - - - - In the case where an RP has access to a local cache of - previously issued manifests that are valid, the RP MAY use the - most recently previously issued valid manifests for this RPKI - repository publication collection for each entity that publishes - at this publication point. + Check that the current time (translated to UTC) is between + thisUpdate and nextUpdate. If the current time lies within this + interval, proceed to . If the current + time is earlier than thisUpdate, the CA has made an error. If + the RP cache contains a current manifest, use that manifest + instead and issue a warning. If an RP has no access to a current + manifest, processing stops and a warning MUST be issued. If the + current time is later than nextUpdate, then the manifest is + stale. If the RP cache contains a current manifest, use that + manifest instead and issue a warning.If no current manifest is + available, proceed to .
-
+
- The presence of an invalid manifest at a publication point could - occur due to an error by the publisher or due to (malicious or - accidental) corruption of a valid manifest. An invalid manifest - MUST never be used, even if the manifestNumber of the invalid - manifest is greater than that of other (valid) manifests. + Acquire all files enumerated in the manifest (fileList) from the + publication point. This includes the CRL, each object containing + an EE certificate issued by the C, and all subordinate CA and EE + certificates. If there are files listed in the manifest that + cannot be retrieved from the publication point, or if they fail + the validity tests specified in , the RP + SHOULD examine its cache to determine if these files are + available locally. If all of the missing/invalid files are + available from the RP's cache, i.e., each file name matches the + list extracted from the manifest, the RP SHOULD use the cached + files to replace those missing from the publication point, and + proceed to . However, if _any_ of the + missing/invalid files cannot be replaced in this fashion, then + proceed to . + +
+
- There are no risks associated with using signed objects at a - publication point containing an invalid manifest, provided that - valid manifests that collectively cover all the signed objects - are also present. - - - - If an invalid manifest is present at a publication point that - also contains one or more valid manifests, this situation SHOULD - result in a warning to the effect that: "An invalid manifest was - found at <pub point name>, this indicates an attack - against the publication point or an error by the publisher. - Processing for this publication point will continue using the - most recent valid manifest(s)." - - - - In the case where the RP has access to a local cache of - previously issued (valid) manifests, an RP MAY make use of that - locally cached data. Specifically, the RP MAY use the locally - cached, most recent, previously issued, valid manifest issued by - the entity that (appears to have) issued the invalid manifest. + Verify that the hash value of every file listed in the manifest + matches the value obtained by hashing the file acquired from the + publication point or local cache. If the computed hash value of + a file listed on the manifest does not match the hash value + contained in the manifest, then an RP SHOULD examine its local + cache to determine if the same file is available. The RP SHOULD + use cached files to replace any (damaged) downloaded files, so + long as the hash of the cached file matches the hash from the + manifest. If any of the files with hash mismatches cannot be + replaced in this fashion, proceed to 6.7. Otherwise proceed to + .
-
- +
+ - A manifest is considered stale if the current time is after the - nextUpdate time for the manifest. This could be due to - publisher failure to promptly publish a new manifest, or due to - (malicious or accidental) corruption or suppression of a more - recent manifest. - - - - All signed objects at the publication point issued by the entity - that has published the stale manifest, and all descendant signed - objects that are validated using a certificate issued by the - entity that has published the stale manifest at this publication - point, SHOULD be viewed as somewhat suspect, but MAY be used by - the RP as per local policy. - - - - The primary risk in using such signed objects is that a newer - manifest exists that, if present, would indicate that certain - objects have been removed or replaced. (For example, the new - manifest might show the existence of a newer CRL and the removal - of one or more revoked certificates). Thus, the use of objects - from a stale manifest may cause an RP to incorrectly treat - invalid objects as valid. The risk is that the CRL covered by - the stale manifest has been superseded, and thus an RP will - improperly treat a revoked certificate as valid. This risk is - somewhat mitigated if the time between the nextUpdate field of - the manifest and the current time is short. The risk in - discarding signed objects at this publication point is that the - RP may incorrectly discard a large number of valid objects. - This gives significant power to an adversary that is able to - prevent the publication of a new manifest at a given publication - point. - - - - Regardless of whether signed objects from this publication are - deemed fit for use by an RP, this situation SHOULD result in a - warning to the effect that: "A manifest found at <pub point - name> is no longer current. It is possible that undetected - deletions have occurred at this publication point." - - - - Note that there is also the potential for the current time to be - before the thisUpdate time for the manifest. This case could be - due to publisher error or a local clock error; in such a case, - this situation SHOULD result in a warning to the effect that: "A - manifest found at <pub point name> has an incorrect - thisUpdate field. This could be due to publisher error, or a - local clock error, and processing for this publication point - will continue using this otherwise valid manifest." + If a current manifest contains entries for objects that are not + within the scope of the manifest (), then + the out-of-scope entries MUST be disregarded.
-
+
- If there exist valid signed objects that do not appear in any - manifest, then, provided the manifest is not stale (see ), it is likely that their omission is an - error by the publisher. It is also possible that this state - could be the result of a (malicious or accidental) replacement - of a current manifest with an older, but still valid, manifest. - However, regarding the appropriate interpretation of such - objects, it remains the case that if the objects were intended - to be invalid, then they should have been revoked using whatever - revocation mechanism is appropriate for the signed object in - question. Therefore, there is little risk in using such signed - objects. If the publication point contains a stale manifest, - then there is a greater risk that the objects in question were - revoked, along with a missing Certificate Revocation List (CRL), - the absence of which is undetectable since the manifest is - stale. In any case, the use of signed objects not present on a - manifest, or descendant objects that are validated using such - signed objects, is a matter of local policy. + If an RP cannot acquire a current, valid manifest, or acquire + current, valid instances of all of the objects enumerated in a + current valid manifest, then processing of the signed objects + associated with the CA has failed. The RP MUST issue a warning + indicating the reason(s) for termination of processing with + regard to this CA. - Regardless of whether objects not appearing on a manifest are - deemed fit for use by the RP, this situation SHOULD result in a - warning to the effect that: "The following files are present in - the repository at <pub point name>, but are not listed on - any manifest <file list> for <pub point name>." - - - - If there exists files listed on the manifest that do not appear - in the repository, then these objects are likely to have been - improperly (via malice or accident) deleted from the repository. - A primary purpose of manifests is to detect such deletions. - Therefore, in such a case, this situation SHOULD result in a - warning to the effect that: "The following files that should - have been present in the repository at <pub point name> - are missing <file list>. This indicates an attack against - this publication point, or the repository, or an error by the - publisher." - - -
- -
- - - A file appearing on a manifest with an incorrect hash value - could occur because of publisher error, but it also may indicate - that an attack has occurred. - - - - If an object appeared on a previous valid manifest with a - correct hash value, and it now appears with an invalid hash - value, then it is likely that the object has been superseded by - a new (unavailable) version of the object. If the object is - used, there is a risk that the RP will be treating a stale - object as valid. This risk is more significant if the object in - question is a CRL. If the object can be validated using the - RPKI, the use of these objects is a matter of local policy. - - - - If an object appears on a manifest with an invalid hash and has - never previously appeared on a manifest, then it is unclear - whether the available version of the object is more or less - recent than the version indicated by the manifest. If the - manifest is stale (see ), then it - becomes more likely that the available version is more recent - than the version indicated on the manifest, but this is never - certain. Whether to use such objects is a matter of local - policy. However, in general, it is better to use a possibly - outdated version of the object than to discard the object - completely. - - - - While it is a matter of local policy, in the case of CRLs, an RP - SHOULD endeavor to use the most recently issued valid CRL, even - where the hash value in the manifest matches an older CRL or - does not match any available CRL for a CA instance. The - thisUpdate field of the CRL can be used to establish the most - recent CRL in the case where an RP has more than one valid CRL - for a CA instance. - - - - Regardless of whether objects with incorrect hashes are deemed - fit for use by the RP, this situation SHOULD result in a warning - to the effect that: "The following files at the repository - <pub point name> appear on a manifest with incorrect hash - values <file list>. It is possible that these objects - have been superseded by a more recent version. It is very - likely that this problem is due to an attack on the publication - point, although it also could be due to a publisher error." + Termination or processing means that all of the ROAs and + subordinate certificates (CA and EE) MUST be considered + invalid. This implies that the RP MUST not try to acquire and + validate _subordinate_ signed objects, until the next interval + when the RP is scheduled to process data for this part of the + RPKI repository system.
@@ -1061,7 +884,8 @@ specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. The authors also wish to - thank Sean Turner for his helpful review of this document. + thank Job Snijders, Oleg Muravskiy, and Sean Turner for their + helpful review of this document.