randy/draft-6486bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Steve Kent rewrite

Browse source
This commit is contained in:
Randy Bush 2020-05-21 12:56:49 -07:00
parent bea9d48c3f
commit 7e5c5bf25e
2 changed files with 335 additions and 679 deletions
Download patch file Download diff file Expand all files Collapse all files

542
draft-ymbk-sidrops-6486bis.txt
View file

@ -6,11 +6,11 @@ Network Working Group R. Austein
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Updates: 6486 (if approved) G. Huston Updates: 6486 (if approved) G. Huston
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: November 6, 2020 S. Kent Expires: November 22, 2020 S. Kent
Independent Independent
M. Lepinski M. Lepinski
New College Florida New College Florida
May 5, 2020 May 21, 2020
Manifests for the Resource Public Key Infrastructure (RPKI) 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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Internet-Draft RPKI Manifests May 2020
@ -89,27 +89,27 @@ Table of Contents
5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8
5.2. Considerations for Manifest Generation . . . . . . . . . 9 5.2. Considerations for Manifest Generation . . . . . . . . . 9
6. Relying Party Use of Manifests . . . . . . . . . . . . . . . 9 6. Relying Party Use of Manifests . . . . . . . . . . . . . . . 9
6.1. Tests for Determining Manifest State . . . . . . . . . . 10 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 10
6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 11 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11
6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 12 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11
6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 13 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 11
6.5. Mismatch between Manifest and Publication Point . . . . . 14 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12
6.6. Hash Values Not Matching Manifests . . . . . . . . . . . 14 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12
7. Publication Repositories . . . . . . . . . . . . . . . . . . 15 6.7. Termination of Processing . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Publication Repositories . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Austein, et al. Expires November 22, 2020 [Page 2]
Austein, et al. Expires November 6, 2020 [Page 2]
Internet-Draft RPKI Manifests May 2020 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 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 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 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 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 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 Internet-Draft RPKI Manifests May 2020
@ -495,325 +495,168 @@ Internet-Draft RPKI Manifests May 2020
6. Relying Party Use of Manifests 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 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 Internet-Draft RPKI Manifests May 2020
selection is a matter of local policy. However, in the following allow an RP to detect manipulation of repository data and/or errors
sections, we describe a sequence of tests that the RP SHOULD perform by a CA or repository manager. Unless _all_ of the files enumerated
to determine the manifest state of the given publication point. We in a manifest can be obtained by an RP (either from a publication
then discuss the risks associated with using signed objects in the point or from a local cache), an RP MUST ignore the data associated
publication point, given the manifest state; we also provide suitable with the publication point. This stringent response is needed to
warning text that SHOULD be placed in a user-accessible log file. It prevent an RP from misinterpreting data associated with a publication
is the responsibility of the RP to weigh these risks against the risk point, and thus possibly treating invalid routes as valid, or vice
of routing failure that could occur if valid data is rejected, and to versa.
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).
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 Note that there is a "chicken and egg" relationship between the
tests to determine the manifest state of the publication point: 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 6.1. Manifest Processing Overview
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).
If the publication point does not contain a valid manifest, see For a given publication point, an RP MUST perform a series of tests
Section 6.2. Lacking a valid manifest, the following tests to determine which signed object files at the publication point are
cannot be performed. 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 1. All of the files referenced by the manifest MUST be be located at
publication point appears in one and only one current manifest, the publication point specified by the id-ad-caRepository URI
and that every file listed in a current manifest is published at from the (same) certificate's SIA. If the manifest and the files
the same publication point as the manifest. 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 2. A manifest SHOULD contain exactly one CRL (.crl) file and it MUST
on any manifest, or files listed in a manifest that do not appear be at the location specified in the CRLDP in the manifest's EE
at the publication point, then see Section 6.5, but still certificate.
continue with the following test.
3. Check that the current time (translated to UTC) is between 3. If more than one .crl file appears in the manifest, only file
thisUpdate and nextUpdate. 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. 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 Internet-Draft RPKI Manifests May 2020
If the computed hash value of a file listed on the manifest does file name matches the list extracted from the manifest, the RP SHOULD
not match the hash value contained in the manifest, then see use the cached files to replace those missing from the publication
Section 6.6. 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 6.5. Matching File Names and Hashes
conforms to the manifest's scope constraints, as specified in
Section 2.
6. If a current manifest contains entries for objects that are not Verify that the hash value of every file listed in the manifest
within the scope of the manifest, then the out-of-scope entries matches the value obtained by hashing the file acquired from the
SHOULD be disregarded in the context of this manifest. If there publication point or local cache. If the computed hash value of a
is no other current manifest that describes these objects within file listed on the manifest does not match the hash value contained
that other manifest's scope, then see Section 6.2. 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 6.6. Out of Scope Manifest Entries
conditions hold:
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 6.7. Termination of Processing
publication point pass all of the above checks;
+ 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 Termination or processing means that all of the ROAs and subordinate
path used to validate the signed object and the associated certificates (CA and EE) MUST be considered invalid. This implies
publication points pass all of the above checks; that the RP MUST not try to acquire and validate _subordinate_ signed
objects, until the next interval when the RP is scheduled to process
then the RP can conclude that no attack against the repository system data for this part of the RPKI 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 <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.
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 <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.
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 <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."
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 <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."
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 <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."
7. Publication Repositories 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 always contain at least one entry, namely, the CRL issued by the CA
upon repository creation [RFC6481]. 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 Every published signed object in the RPKI [RFC6488] is published in
the repository publication point of the CA that issued the EE the repository publication point of the CA that issued the EE
certificate, and is listed in the manifest associated with that CA 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 provide an additional level of protection for RPKI RPs.
Manifests can assist an RP to determine if a repository object has Manifests can assist an RP to determine if a repository object has
been deleted, occluded, or otherwise removed from view, or if a 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 publication of a newer version of an object has been suppressed (and
an older version of the object has been substituted). 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 Michelson and Randy Bush in the preparation of the manifest
specification. Additionally, the authors would like to thank Mark specification. Additionally, the authors would like to thank Mark
Reynolds and Christopher Small for assistance in clarifying manifest Reynolds and Christopher Small for assistance in clarifying manifest
validation and RP behavior. The authors also wish to thank Sean validation and RP behavior. The authors also wish to thank Job
Turner for his helpful review of this document. 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 11. References
@ -889,15 +739,6 @@ Internet-Draft RPKI Manifests May 2020
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
Austein, et al. Expires November 6, 2020 [Page 16]
Internet-Draft RPKI Manifests May 2020
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
@ -934,6 +775,17 @@ Internet-Draft RPKI Manifests May 2020
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002. (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 11.2. Informative References
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
@ -945,15 +797,6 @@ Internet-Draft RPKI Manifests May 2020
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
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 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
@ -994,18 +837,7 @@ Appendix A. ASN.1 Module
Austein, et al. Expires November 22, 2020 [Page 15]
Austein, et al. Expires November 6, 2020 [Page 18]
Internet-Draft RPKI Manifests May 2020 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 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]

466
draft-ymbk-sidrops-6486bis.xml
View file

@ -574,378 +574,201 @@
<section title="Relying Party Use of Manifests" anchor="sect-6"> <section title="Relying Party Use of Manifests" anchor="sect-6">
<t> <t>
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 validating assertions about INRs and their use (e.g., which ROAs
to use in the construction of route filters). Ultimately, this to use in the construction of route filters). Manifests are
selection is a matter of local policy. However, in the following designed to allow an RP to detect manipulation of repository data
sections, we describe a sequence of tests that the RP SHOULD and/or errors by a CA or repository manager. Unless _all_ of the
perform to determine the manifest state of the given publication files enumerated in a manifest can be obtained by an RP (either
point. We then discuss the risks associated with using signed from a publication point or from a local cache), an RP MUST ignore
objects in the publication point, given the manifest state; we the data associated with the publication point. This stringent
also provide suitable warning text that SHOULD be placed in a response is needed to prevent an RP from misinterpreting data
user-accessible log file. It is the responsibility of the RP to associated with a publication point, and thus possibly treating
weigh these risks against the risk of routing failure that could invalid routes as valid, or vice versa.
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).
</t> </t>
<section title="Tests for Determining Manifest State" anchor="sect-6.1"> <t>
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
</t>
<t>
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.
</t>
<section title="Manifest Processing Overview" anchor="sect-6.1">
<t> <t>
For a given publication point, the RP SHOULD perform the For a given publication point, an RP MUST perform a series of
following tests to determine the manifest state of the tests to determine which signed object files at the publication
publication point: 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.
</t> </t>
<t> <t>
<list style="numbers"> <list style="numbers">
<t> <t>
For each CA using this publication point, select the CA's All of the files referenced by the manifest MUST be be located
current manifest (the "current" manifest is the manifest at the publication point specified by the id-ad-caRepository URI
issued by this CA having the highest manifestNumber among from the (same) certificate's SIA. If the manifest and the
all valid manifests, and where manifest validity is defined files it references do not reside at the same publication point,
in <xref target="sect-4.4"/>).<vspace blankLines="1"/> If an RP MUST *???*
the publication point does not contain a valid manifest, see </t>
<xref target="sect-6.2"/>. Lacking a valid manifest, the
following tests cannot be performed.
</t>
<t> <t>
To verify completeness, an RP MAY check that every file at A manifest SHOULD contain exactly one CRL (.crl) file and it
each publication point appears in one and only one current MUST be at the location specified in the CRLDP in the manifest's
manifest, and that every file listed in a current manifest EE certificate.
is published at the same publication point as the </t>
manifest.<vspace blankLines="1"/> 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 <xref target="sect-6.5"/>, but
still continue with the following test.
</t>
<t> <t>
Check that the current time (translated to UTC) is between If more than one .crl file appears in the manifest, only file
thisUpdate and nextUpdate.<vspace blankLines="1"/> If the names matching the CRL specified by the CRLDP will be
current time does not lie within this interval, then see processed. If more than one .crl entry appears in the manifest,
<xref target="sect-6.4"/>, but still continue with the and matches the CRLDP, the first one encountered MUST be
following tests. used. Any other .crl files MUST be ignored and a warning MUST be
</t> issued.
</t>
<t> <t>
Verify that the listed hash value of every file listed in Note that, during CA key rollover [RFC6489], signed objects for
each manifest matches the value obtained by hashing the file two or more different CA instances will appear at the same
at the publication point.<vspace blankLines="1"/> If the publication point.
computed hash value of a file listed on the manifest does </t>
not match the hash value contained in the manifest, then see
<xref target="sect-6.6"/>.
</t>
<t> <t>
An RP MAY check that the contents of each current manifest Manifest processing is to be performed separately for each CA
conforms to the manifest's scope constraints, as specified instance, guided by the SIA id-ad-rpkiManifest URI in each CA
in <xref target="sect-2"/>. certificate.
</t> </t>
<t> <t>
If a current manifest contains entries for objects that are Note also that the processing described here will be performed
not within the scope of the manifest, then the out-of-scope using locally cached files if an RP does not detect newer
entries SHOULD be disregarded in the context of this versions of the files in the RPKI repository system.
manifest. If there is no other current manifest that </t>
describes these objects within that other manifest's scope,
then see <xref target="sect-6.2"/>.
<list style="hanging" hangIndent="3">
<t hangText="For each signed object, if all of the following
conditions hold:">
<vspace blankLines="0"/>
<list style="symbols">
<t>
the manifest for its publication and the associated
publication point pass all of the above checks;
</t>
<t>
the signed object is valid; and
</t>
<t>
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;
</t>
</list>
</t>
</list>
</t>
</list> </list>
</t> </t>
</section>
<section title="Acquiring a Manifest for a CA" anchor="sect-6.2">
<t> <t>
then the RP can conclude that no attack against the repository Acquire the manifest identified by the SIA id-ad-rpkiManifest
system has compromised the given signed object, and the signed URI in the CA certificate. If an RP cannot retrieve a manifest
object MUST be treated as valid (relative to manifest using this URI, or if the manifest is not valid (Section 4.4),
checking). an RP SHOULD examine the most recent, cached manifest matching
this URI. If that manifest is current (<xref
target="sect-4.4"/>) proceed to <xref target="sect-6.3"/>. If
the publication point does not contain a valid manifest, and the
cached manifest is not current, proceed to <xref
target="sect-6.7"/>.
</t> </t>
</section> </section>
<section title="Missing Manifests" anchor="sect-6.2"> <section title="Detecting Stale and or Prematurely-issued Manifests" anchor="sect-6.3">
<t> <t>
The absence of a current manifest at a publication point could Check that the current time (translated to UTC) is between
occur due to an error by the publisher or due to (malicious or thisUpdate and nextUpdate. If the current time lies within this
accidental) deletion or corruption of all valid manifests. interval, proceed to <xref target="sect-6.4"/>. If the current
</t> 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
<t> manifest, processing stops and a warning MUST be issued. If the
When no valid manifest is available, there is no protection current time is later than nextUpdate, then the manifest is
against attacks that delete signed objects or replay old stale. If the RP cache contains a current manifest, use that
versions of signed objects. All signed objects at the manifest instead and issue a warning.If no current manifest is
publication point, and all descendant objects that are validated available, proceed to <xref target="sect-6.7"/>.
using a certificate at this publication point, SHOULD be viewed
as suspect, but MAY be used by the RP, as per local policy.
</t>
<t>
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.
</t>
<t>
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
&lt;pub point name&gt;, and thus there may have been undetected
deletions or replay substitutions from the publication point."
</t>
<t>
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.
</t> </t>
</section> </section>
<section title="Invalid Manifests" anchor="sect-6.3"> <section title="Acquiring Files Referenced by a Manifest" anchor="sect-6.4">
<t> <t>
The presence of an invalid manifest at a publication point could Acquire all files enumerated in the manifest (fileList) from the
occur due to an error by the publisher or due to (malicious or publication point. This includes the CRL, each object containing
accidental) corruption of a valid manifest. An invalid manifest an EE certificate issued by the C, and all subordinate CA and EE
MUST never be used, even if the manifestNumber of the invalid certificates. If there are files listed in the manifest that
manifest is greater than that of other (valid) manifests. cannot be retrieved from the publication point, or if they fail
</t> the validity tests specified in <xref target="RFC6488"/>, the RP
SHOULD examine its cache to determine if these files are
available locally. If all of the missing/invalid files are
<t> available from the RP's cache, i.e., each file name matches the
There are no risks associated with using signed objects at a list extracted from the manifest, the RP SHOULD use the cached
publication point containing an invalid manifest, provided that files to replace those missing from the publication point, and
valid manifests that collectively cover all the signed objects proceed to <xref target="sect-6.5"/>. However, if _any_ of the
are also present. missing/invalid files cannot be replaced in this fashion, then
</t> proceed to <xref target="sect-6.7"/>.
<t>
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 &lt;pub point name&gt;, 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)."
</t>
<t>
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.
</t> </t>
</section> </section>
<section title="Stale Manifests" anchor="sect-6.4"> <section title="Matching File Names and Hashes" anchor="sect-6.5">
<t> <t>
A manifest is considered stale if the current time is after the Verify that the hash value of every file listed in the manifest
nextUpdate time for the manifest. This could be due to matches the value obtained by hashing the file acquired from the
publisher failure to promptly publish a new manifest, or due to publication point or local cache. If the computed hash value of
(malicious or accidental) corruption or suppression of a more a file listed on the manifest does not match the hash value
recent manifest. contained in the manifest, then an RP SHOULD examine its local
</t> cache to determine if the same file is available. The RP SHOULD
use cached files to replace any (damaged) downloaded files, so
<t> long as the hash of the cached file matches the hash from the
All signed objects at the publication point issued by the entity manifest. If any of the files with hash mismatches cannot be
that has published the stale manifest, and all descendant signed replaced in this fashion, proceed to 6.7. Otherwise proceed to
objects that are validated using a certificate issued by the <xref target="sect-6.6"/>.
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.
</t>
<t>
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.
</t>
<t>
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 &lt;pub point
name&gt; is no longer current. It is possible that undetected
deletions have occurred at this publication point."
</t>
<t>
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 &lt;pub point name&gt; 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."
</t> </t>
</section> </section>
<section title="Mismatch between Manifest and Publication Point" <section title="Out of Scope Manifest Entries" anchor="sect-6.6">
anchor="sect-6.5">
<t> <t>
If there exist valid signed objects that do not appear in any If a current manifest contains entries for objects that are not
manifest, then, provided the manifest is not stale (see <xref within the scope of the manifest (<xref target="sect-2"/>), then
target="sect-6.4"/>), it is likely that their omission is an the out-of-scope entries MUST be disregarded.
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.
</t>
<t>
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 &lt;pub point name&gt;, but are not listed on
any manifest &lt;file list&gt; for &lt;pub point name&gt;."
</t>
<t>
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 &lt;pub point name&gt;
are missing &lt;file list&gt;. This indicates an attack against
this publication point, or the repository, or an error by the
publisher."
</t> </t>
</section> </section>
<section title="Hash Values Not Matching Manifests" <section title="Termination of Processing" anchor="sect-6.7">
anchor="sect-6.6">
<t> <t>
A file appearing on a manifest with an incorrect hash value If an RP cannot acquire a current, valid manifest, or acquire
could occur because of publisher error, but it also may indicate current, valid instances of all of the objects enumerated in a
that an attack has occurred. 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.
</t> </t>
<t> <t>
If an object appeared on a previous valid manifest with a Termination or processing means that all of the ROAs and
correct hash value, and it now appears with an invalid hash subordinate certificates (CA and EE) MUST be considered
value, then it is likely that the object has been superseded by invalid. This implies that the RP MUST not try to acquire and
a new (unavailable) version of the object. If the object is validate _subordinate_ signed objects, until the next interval
used, there is a risk that the RP will be treating a stale when the RP is scheduled to process data for this part of the
object as valid. This risk is more significant if the object in RPKI repository system.
question is a CRL. If the object can be validated using the
RPKI, the use of these objects is a matter of local policy.
</t>
<t>
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 <xref target="sect-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.
</t>
<t>
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.
</t>
<t>
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
&lt;pub point name&gt; appear on a manifest with incorrect hash
values &lt;file list&gt;. 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."
</t> </t>
</section> </section>
@ -1061,7 +884,8 @@
specification. Additionally, the authors would like to thank Mark specification. Additionally, the authors would like to thank Mark
Reynolds and Christopher Small for assistance in clarifying Reynolds and Christopher Small for assistance in clarifying
manifest validation and RP behavior. The authors also wish to 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.
</t> </t>
</section> </section>