Network Working Group T. Bruijnzeels
Internet-Draft RIPE NCC
Intended status: Informational C. Martinez
Expires: May 13, 2013 LACNIC
A. Newton
ARIN
November 09, 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 13, 2013.

Copyright Notice

Copyright (c) 2012 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. 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] .

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.

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.

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:

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.

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:

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.

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:

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.

6. Security Considerations

TBD

7. Acknowledgements

TBD

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

Tim Bruijnzeels RIPE NCC EMail: tim@ripe.net
Carlos Martinez LACNIC EMail: carlos@lacnic.net
Andy Newton ARIN EMail: andy@arin.net