Secure Inter-Domain Routing R. Austein
Internet-Draft ISC
Intended status: Standards Track G. Huston
Expires: April 18, 2011 APNIC
S. Kent
M. Lepinski
BBN
October 15, 2010
Manifests for the Resource Public Key Infrastructure
draft-ietf-sidr-rpki-manifests-08.txt
Abstract
This document defines a "manifest" for use in the Resource Public Key
Infrastructure (RPKI). A manifest is a signed object that contains a
listing of all the signed objects in the repository publication point
associated with an authority responsible for publishing in the
repository. For each certificate, Certificate Revocation List (CRL),
or other type of signed objects issued by the authority that are
published at this repository publication point, the manifest contains
both the name of the file containing the object, and a hash of the
file content. Manifests are intended to enable a relying party (RP)
to detect certain forms of attacks against a repository.
Specifically, if a RP checks a manifest's contents against the signed
objects retrieved from a repository publication point, then the RP
can detect "stale" (valid) data and deletion of signed objects.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2011.
Copyright Notice
Austein, et al. Expires April 18, 2011 [Page 1]
Internet-Draft RPKI Manifests October 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4
4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 5
4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. ContentType Attribute . . . . . . . . . . . . . . . . . . 7
4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7
5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7
5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 8
5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 9
5.3. Common Considerations for Manifest Generation . . . . . . 10
6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 10
6.1. Tests for Determining Manifest State . . . . . . . . . . . 11
6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 12
6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 13
6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 13
6.5. Mismatch between Manifest and Publication Point . . . . . 14
6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 15
7. Publication Repositories . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Austein, et al. Expires April 18, 2011 [Page 2]
Internet-Draft RPKI Manifests October 2010
1. Introduction
The Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch]
makes use of a distributed repository system
[ID.ietf-sidr-repos-struct] to make available a variety of objects
needed by relying parties (RPs). Because all of the objects stored
in the repository system are digitally signed by the entities that
created them, attacks that modify these published objects are
detectable by RPs. However, digital signatures provide no protection
against attacks that substitute "stale" versions of signed objects
(i.e., objects that were valid and have not expired, but have since
been superseded) or attacks that remove an object that should be
present in the repository. To assist in the detection of such
attacks, the RPKI repository system can make use of a signed object
called a "manifest".
A manifest is a signed object that enumerates all the signed objects
in the repository publication point that are associated with an
authority responsible for publishing at that publication point. Each
manifest contains both the name of the file containing the object,
and a hash of the file content, for every signed object issued by an
authority that is published at the authority's repository publication
point. A manifest is intended to allow an RP to detect unauthorized
object removal, or the substitution of "stale" versions of objects at
a publication point. A manifest also intended to allow an RP to
detect similar outcomes that may result from a man-in-the middle
attack on the retrieval of objects from the repository. Manifests
are intended to be used both in Certification Authority (CA)
publication points in repositories (containing subordinate
certificates, Certificate Revocation Lists (CRLs) and other signed
objects) and in End Entity (EE) publication points in repositories
(containing only signed objects).
Manifests are modelled on CRLs, as the issues involved in detecting
stale manifests, and detection of potential attacks using manifest
replays, etc are similar to those for CRLs. The syntax of the
manifest payload differs from CRLs, since RPKI repositories contain
objects not covered by CRLs,e.g., digitally signed objects, such as
Route Origination Authorizations (ROAs).
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Austein, et al. Expires April 18, 2011 [Page 3]
Internet-Draft RPKI Manifests October 2010
2. Manifest Scope
A manifest associated with a CA's repository publication point
contains:
* the set of (non-expired, non-revoked) certificates issued and
published by this CA,
* the most recent CRL issued by this CA, and
* all signed objects that are verifiable using a "single-use" EE
certificate [I-D.sidr-res-certs], issued by this CA.
Where multiple CA instances share a common publication point, as can
occur when an entity performs a key-rollover operation
[ID.sidr-keyroll], the repository publication point will contain
multiple manifests. In this case, each manifest describes only the
collection of published products of its associated CA instance.
A manifest associated with a "multi-use" EE certificate
[I-D.sidr-res-certs] where an EE has a defined repository publication
point (i.e., the SIA extension of the EE certificate has an
accessMethod OID of id-ad-signedObjectRepository), contains all
published objects that are verifiable using this EE certificate, and
the accessMethod id-as-rpkiManifest points to the publication point
of the EE's manifest.
3. Manifest Signing
A CA's manifest is verified using an EE certificate that is
designated in [I-D.sidr-res-certs] as a "single-use" EE certificate.
The SIA field of the "single-use" EE certificate contains the access
method OID of id-ad-signedObject.
The CA MAY chose to sign only one manifest with the private key of
the EE certificate, and generate a new EE certificate for each new
version of the manifest. This form of use of a "single-use" EE
certificate is termed a "one-time-use" EE certificate.
Alternatively, the CA MAY chose to use the same EE certificate's
private key to sign a sequence of manifests. Because only a single
manifest (issued under a single CA instance) is current at any point
in time, the EE certificate is used to verify only a single object at
a time. As long as the sequence of objects verified by this EE
certificate are published using the same file name, then this
sequential, multiple use of this "single-use" EE certificate is also
valid. This form of use of a "single-use" EE certificate is termed a
"sequential-use" EE certificate.
Austein, et al. Expires April 18, 2011 [Page 4]
Internet-Draft RPKI Manifests October 2010
A "multi-use" EE's manifest of it's publication repository is signed
with the EE's private key.
4. Manifest Definition
A manifest is a RPKI signed object, as specified in
[ID.sidr-signed-object]. The RPKI signed object template requires
specification of the following data elements in the context of the
manifest structure.
4.1. eContentType
The eContentType for a Manifest is defined as id-ct-rpkiManifest, and
has the numerical value of 1.2.840.113549.1.9.16.1.26.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
4.2. eContent
The content of a Manifest is defined as follows:
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE (SIZE 0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
4.2.1. Manifest
The manifestNumber, thisUpdate, and nextUpdate fields are modelled
after the corresponding fields in X.509 CRLs (see [RFC5280]).
Analogous to CRLs, a manifest is nominally current until the time
specified in nextUpdate or until a manifest is issued with a greater
manifest number, whichever comes first.
Austein, et al. Expires April 18, 2011 [Page 5]
Internet-Draft RPKI Manifests October 2010
If a "one-time-use" EE certificate is employed to verify a manifest,
the EE certificate MUST have an validity period that coincides with
the interval from thisUpdate to nextUpdate, to prevent needless
growth of the CA's CRL.
If a "sequential-use" EE certificate is employed to verify a
manifest, the EE certificate's validity period needs to be no shorter
than the nextUpdate time of the current manifest. The extended
validity time raises the possibility of a substitution attack using a
stale manifest, as described in Section 6.4.
The data elements of the Manifest structure are defined as follows:
version:
The version number of this version of the manifest specification
MUST be 0.
manifestNumber:
This field is an integer that is incremented each time a new
manifest is issued for a given publication point. This field
allows a RP to detect gaps in a sequence of published manifest.
As the manifest is modelled on the CRL specification, the
ManifestNumber is analogous to the CRLNumber, and the guidance in
[RFC5280] for CRLNumber values is appropriate as to the range of
number values that can be used for the manifestNumber. Manifest
numbers can be expected to contain long integers. Manifest
verifiers MUST be able to handle number values up to 20 octets.
Conforming Manifest issuers MUST NOT use number values longer than
20 octets
thisUpdate:
This field contains the time when the manifest was created. This
field has the same format constraints as specified in [RFC5280]
for the CRL field of the same name.
nextUpdate:
This field contains the time at which the next scheduled manifest
will be issued. The value of nextUpdate MUST be later than the
value of thisUpdate. The specification of the GeneralizedTime
value is the same as required for the thisUpdate field.
If the authority alters any of the items that it has published in
the repository publication point, then the authority MUST issue a
new manifest before the nextUpdate time. If a manifest
encompasses a CRL, the nextUpdate field of the manifest MUST match
that of the CRL's nextUpdate field, as the manifest will be
reissued when a new CRL is published. If a "one-time-use" EE
Austein, et al. Expires April 18, 2011 [Page 6]
Internet-Draft RPKI Manifests October 2010
certificate is used to verify the manifest, then when a new
manifest is issued before the time specified in nextUpdate of the
current manifest, the CA MUST also issue a new CRL that includes
the EE certificate corresponding to the old manifest.
fileHashAlg:
This field contains the OID of the hash algorithm used to hash the
files that the authority has placed into the repository. The hash
algorithm used MUST conform to the RPKI Algorithms and Key Size
Profile specification [ID.ietf-sidr-rpki-algs].
fileList:
This field is a sequence of FileAndHash objects. There is one
FileAndHash entry for each currently valid signed object that has
been published by the authority (at this publication point). Each
FileAndHash is an ordered pair consisting of the name of the file
in the repository that contains the object in question, and a hash
of the file's contents.
4.3. ContentType Attribute
The mandatory Content-Type Attribute MUST have its attrValues field
set to the same OID as eContentType. This OID is id-ct-rpkiManifest,
and has the numerical value of 1.2.840.113549.1.9.16.1.26.
4.4. Manifest Validation
To determine whether a manifest is valid, the RP MUST perform the
following checks in addition to those specified in
[ID.sidr-signed-object]:
1. The eContentType in the EncapsulatedContentInfo is id-ad-
rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
2. The version of the rpkiManifest is 0.
3. In the rpkiManifest, thisUpdate precedes nextUpdate.
If the above procedure indicates that the manifest is invalid, then
the manifest MUST be discarded and treated as though no manifest were
present.
5. Manifest Generation
Austein, et al. Expires April 18, 2011 [Page 7]
Internet-Draft RPKI Manifests October 2010
5.1. CA Manifest Generation
For a CA publication point in the RPKI repository system, a CA MUST
perform the following steps to generate a manifest:
1. If no key pair exists, or if using a "one-time-use" EE
certificate with a new key pair, generate a key pair.
2. If using a "one-time-use" EE certificate, or if a key pair was
generated in step 1, issue a "single-use" EE certificate for this
key pair.
This EE certificate has an SIA extension access description
field with an accessMethod OID value of id-ad-signedobject
where the associated accessLocation references the publication
point of the manifest as an object URL.
This EE certificate MUST describe its Internet Number
Resources (INRs) using the "inherit" attribute, rather than
explicit description of a resource set (see [RFC3779]).
In the case of a "one-time-use" EE certificate, the validity
times of the EE certificate MUST exactly match the thisUpdate
and nextUpdate times of the manifest.
In the case of a "sequential-use" EE certificate the validity
times of the EE certificate MUST encompass the time interval
from thisUpdate to nextUpdate.
3. The EE certificate MUST NOT be published in the authority's
repository publication point.
4. Construct the manifest content. Note that the manifest does not
include a self reference (i.e., its own file name and hash),
since it would be impossible to compute the hash of the manifest
itself prior to it being signed. The manifest content is
described in Section 4.2.1. The manifest's fileList includes the
file name and hash pair for each object issued by this CA that
has been published at this repository publication point. The
collection of objects to be included in the manifest includes all
certificates issued by this CA that are published at the CA's
repository publication point, the most recent CRL issued by the
CA, and all objects verified by "single-use" EE certificates that
were issued by this CA that are published at this repository
publication point.
Austein, et al. Expires April 18, 2011 [Page 8]
Internet-Draft RPKI Manifests October 2010
5. Encapsulate the Manifest content using the CMS SignedData content
type (as specified Section 4), sign the manifest using the
private key corresponding to the subject key contained in the EE
certificate, and publish the manifest in repository system
publication point that is described by the manifest.
6. In the case of a key pair that is to be used only once, in
conjunction with a "one-time-use" EE certificate, the private key
associated with this key pair SHOULD now be destroyed.
5.2. End Entity Manifest Generation
EE repository publication points are used only in conjunction with
"multi-use" EE Certificates. In this case the EE Certificate has two
accessMethods specified in its SIA field. The accessDescription
element that contains an accessMethod value of id-ad-
signedObjectRepository has an associated accessLocation directory URL
that points to the repository publication point of the objects
verifiable using this EE certificate, as specified in
[I-D.sidr-res-certs]. The accessDescription element that contains an
accessMethod value of id-ad-rpkiManifest has an associated
accessLocation that points to the EE's published manifest object as
an object URL. This manifest enumerates every signed object to be
found in that publication point (that can be verified using this EE
certificate), and the hash value of each object (excluding the
manifest itself).
To create a manifest, each "multi-use" EE MUST perform the following
steps:.
1. Construct the Manifest content. Note that the manifest does not
include a self reference (i.e., its own file name and hash),
since it would be impossible to compute the hash of the manifest
itself prior to it being signed. The manifest content is
described in Section 4.2.1. The manifest's fileList includes the
file names and hash pair for each object that is verifiable using
that EE certificate that has been published at this repository
publication point.
2. Encapsulate the Manifest content using the CMS SignedData content
type (as specified in Section 4), sign the manifest using the
private key corresponding to the subject key contained in the EE
certificate, and publish the manifest in repository system
publication point that is described by the manifest.
"Single Use" EE certificates (EE certificates with an SIA
Austein, et al. Expires April 18, 2011 [Page 9]
Internet-Draft RPKI Manifests October 2010
accessMethod OID of id-as-signedObject) do not have repository
publication points. The object that is verifiable using the "Single
Use" EE certificate is published in the repository publication point
of the CA certificate that issued the EE certificate, and is listed
in the corresponding manifest for this CA certificate.
5.3. Common Considerations for Manifest Generation
A new manifest MUST be issued on or before the nextUpdate time.
An authority MUST issue a new manifest in conjunction with the
finalization of changes made to objects in the publication point. An
authority MAY perform a number of object operations on a publication
repository within the scope of a repository change before issuing a
single manifest that covers all the operations within the scope of
this change. Repository operators SHOULD implement some form of
repository update procedure that mitigates, to the extent possible,
the risk that RPs who are performing retrieval operations on the
repository are exposed to inconsistent transient intermediate states
during updates to the repository and the associated manifest.
Since the manifest object URL is included in the SIA of issued
Certificates, a new manifest MUST NOT invalidate the manifest object
URL of previously issued certificates. This implies that the
manifest's publication name in the repository, in the form of an
object URL, is unchanged across manifest generation cycles.
In the case of a CA publication point manifest, when the CA entity is
performing a key rollover, the entity MAY chose to have two CAs
instances simultaneously publishing at the same publication point.
In this case there will be one manifest associated with each active
CA instance that is publishing into the common repository publication
point.
In the case of an EE publication point, the manifest lists all
published objects verified using that EE certificate. Multiple EEs
MAY share a common repository publication point, in which case there
will be one manifest associated with each active EE that is
publishing into the common repository publication point.
6. Relying Party Use of Manifests
The goal of an RP is to determine which signed objects to 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
Austein, et al. Expires April 18, 2011 [Page 10]
Internet-Draft RPKI Manifests October 2010
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 validatable 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
For a given publication point, the RP SHOULD perform the following
tests to determine the manifest state of the publication point:
1. For each entity using this publication point, select the entity's
current manifest (The "current" manifest is the manifest issued
by this CA having highest manifestNumber among all valid
manifests, and where manifest validity is defined in
Section 4.4).
1. If the publication point does not contain a valid manifest,
see Section Section 6.2. Lacking a valid manifest, the
following tests cannot be performed.
2. Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate.
1. If the current time does not lie within this interval then
see Section 6.4, but still continue with the following tests.
3. Check that every file at the publication point appears in one and
only one current manifest, and that every file listed in each
current manifest that is published at this publication point also
is published at the publication point.
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 Section 6.5, but
still continue with the following test.
4. Verify that listed hash value of every file listed in each
manifest matches the value obtained by hashing the file at the
publication point.
Austein, et al. Expires April 18, 2011 [Page 11]
Internet-Draft RPKI Manifests October 2010
1. 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.
5. Check that the contents of each current manifest conforms to the
manifest's scope constraints, as specified in Section 2.
1. 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.
For each signed object, if all of the following conditions hold:
* 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;
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.
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
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
Austein, et al. Expires April 18, 2011 [Page 12]
Internet-Draft RPKI Manifests October 2010
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 in this case for each entity that publishes at
his 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 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 use use the locally cached, most recent,
previously issued. valid manifest issued by the entity that (appears
to have) issued the invalid manifest.
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.
Austein, et al. Expires April 18, 2011 [Page 13]
Internet-Draft RPKI Manifests October 2010
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
are 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 to improperly treat 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, and 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."
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 such objects, it remains the case that if the objects
were intended to be invalid, then they should have been revoked using
Austein, et al. Expires April 18, 2011 [Page 14]
Internet-Draft RPKI Manifests October 2010
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
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 that the version indicated on the manifest, but this
is never certain. Whether to use such objects is a matter of local
Austein, et al. Expires April 18, 2011 [Page 15]
Internet-Draft RPKI Manifests October 2010
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 endeavour 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
The RPKI publication system model requires that every publication
point be associated with one or more CAs or one or more EEs, and be
non-empty. Upon creation of the publication point associated with a
CA, the CA MUST create and publish a manifest as well as a CRL. The
manifest will contain at least one entry, the CRL issued by the CA
upon repository creation. Upon the creation of the publication point
associated with an EE, the EE MUST create and publish a manifest.
The manifest in an otherwise empty repository publication point
associated with an EE will contain no entries in the manifest's
fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of
zero) [ID.ietf-sidr-repos-struct].
For each signed object, the EE certificate used to verify the
object's signature is either a single-use certificate, or a multi-use
certificate. In the case of a single-use EE certificate, the signed
object is published in the repository publication point of the CA
that issued the single use EE certificate, and is listed in the
manifest associated with that CA certificate. In the case where an
EE certificate is used to verify multiple objects, each signed object
is published in the EE certificate's repository publication point and
listed in the manifest associated with the EE certificate.
8. Security Considerations
Manifests provide an additional level of protection for RPKI RPs.
Austein, et al. Expires April 18, 2011 [Page 16]
Internet-Draft RPKI Manifests October 2010
Manifests can assist a RP to determine if a repository object has
been deleted, occluded or otherwise removed from view, or if a
publication of a newer version of an object has been suppressed (and
an older version of the object has been substituted).
Manifests cannot repair the effects of such forms of corruption of
repository retrieval operations. However, a manifest enables an RP
to determine if a locally maintained copy of a repository is a
complete and up to date copy, even when the repository retrieval
operation is conducted over an insecure channel. In cases where the
manifest and the retrieved repository contents differ, the manifest
can assist in determining which repository objects form the
difference set in terms of missing, extraneous or superseded objects.
The signing structure of a manifest and the use of the nextUpdate
value allows an RP to determine if the manifest itself is the subject
of attempted alteration. The requirement for every repository
publication point to contain at least one manifest allows a RP to
determine is the manifest itself has been occluded from view. Such
attacks against the manifest are detectable within the time frame of
the regular schedule of manifest updates. Forms of replay attack
within finer-grained time frames are not necessarily detectable by
the manifest structure .
9. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.]
10. Acknowledgements
The authors would like to acknowledge the contributions from George
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 behaviour. The authors also wish to thank Sean
Turner for his helpful of this document.
11. References
11.1. Normative References
[I-D.sidr-res-certs]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
Austein, et al. Expires April 18, 2011 [Page 17]
Internet-Draft RPKI Manifests October 2010
draft-ietf-sidr-res-certs-16.txt (work in progress),
February 2009.
[ID.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaleson, "A Profile for
Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-04.txt (work in progress),
May 2010.
[ID.ietf-sidr-rpki-algs]
Huston, G., "A Profile for Algorithms and Key Sizes for
use in the Resource Public Key Infrastructure",
draft-huston-sidr-rpki-algs-00.txt (work in progress),
July 2009.
[ID.sidr-signed-object]
Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-01.txt (work in progress),
October 2010.
[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
(CRL) Profile", RFC 5280, May 2008.
11.2. Informative References
[ID.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11.txt
(work in progress), September 2010.
[ID.sidr-keyroll]
Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in
progress), October 2010.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
Austein, et al. Expires April 18, 2011 [Page 18]
Internet-Draft RPKI Manifests October 2010
Appendix A. ASN.1 Module
RPKIManifest { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) smime(7)
mod(0) TBD }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- Manifest Content Type: OID
yid-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
-- Manifest Content Type: eContent
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
Austein, et al. Expires April 18, 2011 [Page 19]
Internet-Draft RPKI Manifests October 2010
Authors' Addresses
Rob Austein
Internet Systems Consortium
950 Charter St.
Redwood City, CA 94063
USA
Email: sra@isc.org
Geoff Huston
Asia Pacific Network Information Centre
33 Park Rd.
Milton, QLD 4064
Australia
Email: gih@apnic.net
URI: http://www.apnic.net
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Email: kent@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Email: mlepinski@bbn.com
Austein, et al. Expires April 18, 2011 [Page 20]
