Network Working Group T. Bruijnzeels
Internet-Draft RIPE NCC
Intended status: Informational C. Martinez
Expires: May 12, 2013 LACNIC
A. Newton
ARIN
November 8, 2012
RPKI validation using a local cache
draft-tbruijnzeels-sidr-validation-local-cache-00
Abstract
This documents specifies validation of rpki using a local cache that
is independent of any particular retrieval mechanism of the objects
in this cache. This is useful because it allows for agility in the
RPKI to define alternative fetch algorithms and/or multiple
publication points of RPKI data.
This document lists requirements for the local cache, but since there
is more than one way to meet these requirements this document does
not specify how it must be built. However, a separate informational
document on this subject will be provided as a reference to
implementers.
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 May 12, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bruijnzeels, et al. Expires May 12, 2013 [Page 1]
Internet-Draft RPKI validation using a local cache November 2012
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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Local cache . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Maintaining the Local Cache . . . . . . . . . . . . . . . 5
3.2. Local Cache Requirements . . . . . . . . . . . . . . . . . 5
4. Top-down Validation Algorithm . . . . . . . . . . . . . . . . 6
4.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Processing a Validated CA Certificate . . . . . . . . . . 6
4.4. Finding the Current Manifest . . . . . . . . . . . . . . . 6
4.5. Finding the Current CRL . . . . . . . . . . . . . . . . . 7
4.6. Finding and Validating Signed Objects . . . . . . . . . . 7
4.7. Recursion Down the PKI Tree . . . . . . . . . . . . . . . 7
5. Impact on existing RFCs . . . . . . . . . . . . . . . . . . . 8
5.1. Resource Certificate Repository Structure (RFC6481) . . . 8
5.2. Manifests (RFC6486) . . . . . . . . . . . . . . . . . . . 8
5.2.1. Missing Manifests . . . . . . . . . . . . . . . . . . 9
5.2.2. Mismatch between Manifest and Publication Point . . . 9
5.2.3. Hash Values Not Matching Manifest . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Bruijnzeels, et al. Expires May 12, 2013 [Page 2]
Internet-Draft RPKI validation using a local cache November 2012
1. Requirements notation
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 [RFC2119] .
Bruijnzeels, et al. Expires May 12, 2013 [Page 3]
Internet-Draft RPKI validation using a local cache November 2012
2. Introduction
It has been suggested by various people that in order to mitigate
availability issues in the RPKI repositories, it would be good to
support alternative fetch algorithms (easier to maintain by
publication servers), multiplepublication points (use multiple
publication servers) and sharing of unvalidated objects between
validating caches (less dependence on a central publication server).
All these approaches share in common that unvalidated RPKI objects
can potentially be retrieved in a number of different ways, separate
from the actual validation process. And all these approaches face
the same challenge: how to perform a top-down validation process if
the SIA, AIA and CRLDP pointers don't necessarily point to the
locations where the Relying Party retrieved the objects.
In this document we propose a validation algorithm that does not rely
on these pointers. In particular we will be using a local object
cache that allows SKI and AKI fields in certificates and SHA-256
hashes of objects to be used to perform top-down validation.
Bruijnzeels, et al. Expires May 12, 2013 [Page 4]
Internet-Draft RPKI validation using a local cache November 2012
3. Local cache
3.1. Maintaining the Local Cache
There is more than one way to do this, and to keep the focus of this
document clear we will not go into details on this here. However, a
separate informational document on this subject will be provided as a
reference to implementers. For the remainder of this document we
will assume that we have access to a local cache that satisfies the
requirements documented below.
3.2. Local Cache Requirements
The local cache MUST support object retrieval by SHA-256 hash.
The local cache MUST support manifest retrieval by the AKI of the
manifest EE certificate.
The local cache MUST pro-actively retrieve objects for the
publication points known to it. The local cache MUST support some
mechanisms to communicate these publication points. E.g. by
requiring the Relying Party to supply the CA certificate for which
objects are being sought so that the SIA field can be used to
(de-)register publication points.
In case of cache misses (no manifest or object by that hash found)
the local cache SHOULD attempt re-fetching objects.
Bruijnzeels, et al. Expires May 12, 2013 [Page 5]
Internet-Draft RPKI validation using a local cache November 2012
4. Top-down Validation Algorithm
4.1. Outline
We validate a trust anchor certificate and note the SKI. Then we
search for the most recent manifest in our cache that has an AKI that
matches this SKI and has a valid signature. We expect that this MFT
contains one CRL entry that we will use to check for revocations. We
will retrieve all objects mentioned on the manifest from our cache,
by using their hash as a key. We then validate all objects as
described in the current standards, with some minor caveats detailed
below. We will then recursively find manifests, crls and validate
signed objects for any certificate we validated this way.
4.2. Trust Anchors
The validation process starts with downloading and validating a the
Trust Anchor certificate as described in RFC6490.
The validated certificate we obtain this way will be used as the
first validated certificate in the recursive algorithm outlined
below.
4.3. Processing a Validated CA Certificate
A validated CA certificate has a unique SKI that we can use to
identify it. This SKI will be used as the AKI in any certificates
signed by this CA certificate and the CRL it publishes.
4.4. Finding the Current Manifest
We retrieve the manifest with the most recent "this update time" that
has an EE certificate with an AKI that matches the SKI of the CA
certificate we are processing.
The RP MUST validate that the manifest lists exactly one CRL and that
this CRL can be retrieved from the cache as described in the next
section. This manifest is then validated using the same criteria as
described in RFC6486 section 4.4. With the exception that:
o The CRLDP is ignored and the CRL retrieved above is used
o The SIA and AIA fields are not used for validation
Furthermore if all manifests found this way have invalid signatures
then the Relying Party MUST conclude that the SKI on the CA
certificate was faked and the CA does not hold the private key, and
therefore MUST reject this CA certificate.
Bruijnzeels, et al. Expires May 12, 2013 [Page 6]
Internet-Draft RPKI validation using a local cache November 2012
Note that this situation is extremely unlikely to arise by accident
as the normal Certificate Sign Request as described in RFC6492
includes proof of possession of the private key by the certificate
requester to the issuing CA.
4.5. Finding the Current CRL
The manifest MUST list only one CRL that can be retrieved from the
local cache by it SHA-256 hash. This CRL MUST pass all validation
checks described in RFC5280. This CRL MUST not revoke the EE
certificate of the manifest.
If no such CRL can be found then the Relying Party MUST fall back to
the next most recent manifest in the previous step.
4.6. Finding and Validating Signed Objects
All other objects listed on the manifest can be retrieved from the
cache by the SHA-256 hash. They are each validated according to the
validation rules stipulated for their object type, which we can
deduce from the extension in the name, with the exception that:
o The CRLDP is ignored and the CRL retrieved above is used
o The SIA and AIA fields are not used for validation
Because Prefix Origin Validation (RFC Editor queue) needs to loop
over *all* the relevant Validated ROA Prefixes to determine Route
validity it is RECOMMENDED that Relying Parties first check that all
objects listed on the manifest can be retrieved from the cache, and
if any objects are missing fall back to the next most recent manifest
for processing. If this would result in rejecting a publication
point altogether, e.g. because the previous manifest EE certificate
has expired, then it's RECOMMENDED that the latest manifest is used
despite the missing objects. All these conditions MUST result in
warnings to the users of Relying Party software.
4.7. Recursion Down the PKI Tree
Any valid CA certificates found in the previous step can now be
processed recursively starting at step 4.3.
Bruijnzeels, et al. Expires May 12, 2013 [Page 7]
Internet-Draft RPKI validation using a local cache November 2012
5. Impact on existing RFCs
5.1. Resource Certificate Repository Structure (RFC6481)
This is all in line with the Resource Certificate Repository
Structure as described in RFC6481. However, it could be useful to
add the following normative wording to section 2.2:
"A CA's publication repository MUST contain the current (non-expired
and non-revoked) certificates issued by this CA, the most recent CRL
issued by this CA, the current manifest, and all other current signed
objects that can be verified using an EE certificate [RFC6487] issued
by this CA.
A CA MUST list all objects that it desires to be considered for top-
down validation on a single manifest, and it MUST NOT divide this
list of products over multiple manifests. A CA MUST publish all the
objects listed on this manifest. A CA MAY sign other objects that
are not intended for publication in the RPKI repository. Such
objects MUST NOT appear on the manifest and SHOULD not be published
in the repository"
5.2. Manifests (RFC6486)
Section 1 of RFC6486 has the following on the main purpose of
manifests in the RPKI: "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."
RFC6486 was written in the context of an rpki repository that assumes
single publication points for CAs that can support recursive fetching
of all published objects over rsync. Because RPs can get all objects
that a CA publishes this way there was no need for any object that
lists these objects explicitly for retrieval purposes, and therefore
the manifest was not thought to carry this responsibility.
Having said that, however, there are a number use cases that warrant
that manifests MUST be useful in this way:
o The validation process described in this document is independent
of the location where objects are retrieved. Manifests are used
to determine which objects are currently published by a CA.
o BGP Prefix Origin Validation (RFC editor queue) section 2
describes a process for determining route validity that loops over
all Validated Roa Prefixes. Therefore it is very desirable to
have an authoritative source of information that instructs the RP
which objects MUST be validated.
Bruijnzeels, et al. Expires May 12, 2013 [Page 8]
Internet-Draft RPKI validation using a local cache November 2012
o Other transport protocols, such as http, may be added in the
future. These protocols do not necessarily support recursive
fetching and therefore they need an authoritative list to
determine what to fetch.
For this reason we propose to change the standards so that manifests
MAY be used as the authoritative list of objects that a CA desires to
publish. In the next sections we describe the implications this has
on the use of manifests by RPs as currently described in section 6 of
RFC6486.
5.2.1. Missing Manifests
A missing manifest may be the result of an error by the CA or the
publisher. It is most strongly RECOMMENDED that CAs and publishers
monitor this and fix the situation should problems arise.
If no current manifest can be found by the Relying Party then they
SHOULD use the most recent old manifest in their possession, as
described in section 4.4 in this document.
5.2.2. Mismatch between Manifest and Publication Point
Relying Parties that find that objects listed on the manifest are
missing MAY decide to use the most recent manifest in their
possession for which all objects could be found, as described in
section 4.6 in this document.
As described in RFC6481 CAs MUST publish all objects that MUST be
considered for top-down validation, and they SHOULD NOT publish any
other objects. Therefore Relying Parties MAY ignore any objects
found in a repository that are not listed on a manifest.
5.2.3. Hash Values Not Matching Manifest
Relying Parties MUST reject current published objects with hash
values not matching the validated current manifest.
Bruijnzeels, et al. Expires May 12, 2013 [Page 9]
Internet-Draft RPKI validation using a local cache November 2012
6. Security Considerations
TBD
Bruijnzeels, et al. Expires May 12, 2013 [Page 10]
Internet-Draft RPKI validation using a local cache November 2012
7. Acknowledgements
TBD
Bruijnzeels, et al. Expires May 12, 2013 [Page 11]
Internet-Draft RPKI validation using a local cache November 2012
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Bruijnzeels, et al. Expires May 12, 2013 [Page 12]
Internet-Draft RPKI validation using a local cache November 2012
Authors' Addresses
Tim Bruijnzeels
RIPE NCC
Email: tim@ripe.net
Carlos Martinez
LACNIC
Email: carlos@lacnic.net
Andy Newton
ARIN
Email: andy@arin.net
Bruijnzeels, et al. Expires May 12, 2013 [Page 13]