]> RIPE NCC

oleg@ripe.net https://www.ripe.net/

NLNetLabs

tim@nlnetlabs.nl https://www.nlnetlabs.nl/

rtg SIDR Operations RPKI validation RRDP This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

Introduction This document describes how the RIPE NCC RPKI Validator version 2.25 has been implemented. Source code for this software can be found at . The purpose of this document is to provide transparency to users of (and contributors to) this software tool. In order to use information published in RPKI repositories, Relying Parties (RPs) need to retrieve and validate the content of certificates, Certificate Revocation Lists (CRLs), and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is performed top-down, starting from the TA certificate and descending the certificate chain, validating every encountered certificate and its products. The result of this process is a list of all encountered RPKI objects with a validity status attached to each of them. These results may later be used by an RP in making routing decisions, etc. Traditionally, RPKI data is made available to RPs through the repositories accessible over the rsync protocol . RPs are advised to keep a local copy of repository data and perform regular updates of this copy from the repository (see Section 5 of ). The RRDP introduces another method to fetch repository data and keep the local copy up to date with the repository. This document describes how the RIPE NCC RPKI Validator discovers RPKI objects to download, builds certificate paths, and validates RPKI objects, independently of what repository access protocol is used. To achieve this, it puts downloaded RPKI objects in an object store, where each RPKI object can be found by its URI, the hash of its content, the value of its Authority Key Identifier (AKI) extension, or a combination of these. It also keeps track of the download and validation time for every object, to decide which locally stored objects are not used in the RPKI tree validation and could be removed.

General Considerations

Hash Comparisons This algorithm relies on the collision resistance properties of the hash algorithm (defined in ) to compute the hash of repository objects. It assumes that any two objects for which the hash value is the same are identical. The hash comparison is used when matching objects in the repository with entries on the manifest () and when looking up objects in the object store ().

Discovery of RPKI Objects Issued by a CA There are several possible ways of discovering potential products of a Certification Authority (CA) certificate: one could 1) use all objects located in a repository directory designated as a publication point for a CA, 2) only use objects mentioned on the manifest located at that publication point (see Section 6 of ), or 3) use all known repository objects whose AKI extension matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of ) of a CA certificate. For publication points whose content is consistent with the manifest and issuing certificate, all of these approaches should produce the same result. For inconsistent publication points, the results might be different. Section 6 of leaves the decision on how to deal with inconsistencies to a local policy. The implementation described here does not rely on content of repository directories but uses the Authority Key Identifier (AKI) extension of a manifest and a CRL to find in an object store () a manifest and a CRL issued by a particular CA (see ). It further uses the hashes of the manifest's fileList entries (Section 4.2.1 of ) to find other objects issued by the CA, as described in .

Manifest Entries versus Repository Content Since the current set of RPKI standards (see , , and ) requires use of the manifest to describe the content of a publication point, this implementation requires strict consistency between the publication point content and manifest content. (This is a more stringent requirement than established in .) Therefore, it will not process objects that are found in the publication point but do not match any of the entries of that publication point's manifest (see ). It will also issue warnings for all found mismatches, so that the responsible operators could be made aware of inconsistencies and fix them.

Top-Down Validation of a Single Trust Anchor Certificate Tree When several Trust Anchors are configured, validation of their corresponding certificate trees is performed concurrently and independently from each other. For every configured Trust Anchor, the following steps are performed:

1. The validation of a TA certificate tree starts from its TA certificate. To retrieve the TA certificate, a Trust Anchor Locator (TAL) object is used, as described in .
2. If the TA certificate is retrieved, it is validated according to Section 7 of and Section 2.2 of . Otherwise, the validation of the certificate tree is aborted and an error is issued.
3. If the TA certificate is valid, then all its subordinate objects are validated as described in . Otherwise, the validation of the certificate tree is aborted and an error is issued.
4. For each repository object that was validated during this validation run, the validation timestamp is updated in the object store (see ).
5. Outdated objects are removed from the store as described in . This completes the validation of the TA certificate tree.

Fetching the Trust Anchor Certificate Using the Trust Anchor Locator The following steps are performed in order to fetch a Trust Anchor certificate:

1. (Optional) If the TAL contains a prefetch.uris field, pass the URIs contained in that field to the fetcher (see ). (This field is a non-standard addition to the TAL format. It helps with fetching non-hierarchical rsync repositories more efficiently.)
2. Extract the first TA certificate URI from the TAL's URI section (see Section 2.1 of ) and pass it to the object fetcher (). If the fetcher returns an error, repeat this step for every URI in the URI section until no error is encountered or no more URIs are left.
3. From the object store (see ), retrieve all certificate objects for which the URI matches the URI extracted from the TAL in the previous step and the public key matches the subjectPublicKeyInfo extension of the TAL (see Section 2.1 of ).
4. If no such objects are found or if more than one such objects are found, issue an error and abort the certificate tree validation process with an error. Otherwise, use the single found object as the TA certificate.

CA Certificate Validation The following steps describe the validation of a single CA resource certificate:

1. If both the caRepository (Section 4.8.8.1 of ) and the id-ad-rpkiNotify (Section 3.2 of ) instances of an accessMethod are present in the Subject Information Access extension of the CA certificate, use a local policy to determine which pointer to use. Extract the URI from the selected pointer and pass it to the object fetcher (that will then fetch all objects available from that repository; see ).
2. For the CA certificate, find the current manifest and certificate revocation list (CRL) using the procedure described in . If no such manifest and CRL could be found, stop validation of this certificate, consider it invalid, and issue an error.
3. Compare the URI found in the id-ad-rpkiManifest field (Section 4.8.8.1 of ) of the SIA extension of the certificate with the URI of the manifest found in the previous step. If they are different, issue a warning but continue the validation process using the manifest found in the previous step. (This warning indicates that there is a mismatch between the expected and the actual location of an object in a repository. See for the explanation of this mismatch and the decision made.)
4. Perform discovery and validation of manifest entries as described in .
5. Validate all resource certificate objects found on the manifest using the CRL object:
   • If the strict validation option is enabled by the operator, the validation is performed according to Section 7 of .
   • Otherwise, the validation is performed according to Section 7 of but with the exception of the resource certification path validation, which is performed according to Section 4.2.4.4 of .
   (Note that this implementation uses the operator configuration to decide which algorithm to use for path validation. It applies the selected algorithm to all resource certificates, rather than applying an appropriate algorithm per resource certificate based on the object identifier (OID) for the Certificate Policy found in that certificate, as specified in .)
6. Validate all Route Origin Authorization (ROA) objects found on the manifest using the CRL object found on the manifest, according to Section 4 of .
7. Validate all Ghostbusters Record objects found on the manifest using the CRL object found on the manifest, according to Section 7 of .
8. For every valid CA certificate object found on the manifest, apply the procedure described in this section, recursively, provided that this CA certificate (identified by its SKI) has not yet been validated during current tree validation run.

Finding the Most Recent Valid Manifest and CRL To find the most recent issued manifest and CRL objects of a particular CA certificate, the following steps are performed:

1. From the store (see ), fetch all objects of type manifest whose certificate's AKI extension matches the SKI of the current CA certificate. If no such objects are found, stop processing the current CA certificate and issue an error.
2. Among found objects, find the manifest object with the highest manifestNumber field (Section 4.2.1 of ) for which all following conditions are met:
   • There is only one entry in the manifest for which the store contains exactly one object of type CRL, the hash of which matches the hash of the entry.
   • The manifest's certificate AKI equals the above CRL's AKI.
   • The above CRL is a valid object according to Section 6.3 of .
   • The manifest is a valid object according to Section 4.4 of , and its EE certificate is not in the CRL found above.
3. If there is an object that matches the above criteria, consider this object to be the valid manifest, and consider the CRL found at the previous step to be the valid CRL for the current CA certificate's publication point.
4. Report an error for every other manifest with a number higher than the number of the valid manifest.

Validating Manifest Entries For every entry in the manifest object:

1. Construct an entry's URI by appending the entry name to the current CA's publication point URI.
2. Get all objects from the store whose hash attribute equals the entry's hash (see ).
3. If no such objects are found, issue an error for this manifest entry and progress to the next entry. This case indicates that the repository does not have an object at the location listed in the manifest or that the object's hash does not match the hash listed in the manifest.
4. For every found object, compare its URI with the URI of the manifest entry.
   • For every object with a non-matching URI, issue a warning. This case indicates that the object from the manifest entry is (also) found at a different location in a (possibly different) repository.
   • If no objects with a matching URI are found, issue a warning. This case indicates that there is no object found in the repository at the location listed in the manifest entry (but there is at least one matching object found at a different location).
5. Use all found objects for further validation as per .

Please note that the above steps will not reject objects whose hash matches the hash listed in the manifest but whose URI does not. See for additional information.

Object Store Cleanup At the end of every TA tree validation, some objects are removed from the store using the following rules:

1. Given all objects that were encountered during the current validation run, remove from the store () all objects whose URI attribute matches the URI of one of the encountered objects but whose content's hash does not match the hash of any of the encountered objects. This removes from the store objects that were replaced in the repository by their newer versions with the same URIs.
2. Remove from the store all objects that were last encountered during validation a long time ago (as specified by the local policy). This removes objects that do not appear on any valid manifest anymore (but possibly are still published in a repository).
3. Remove from the store all objects that were downloaded recently (as specified by the local policy) but that have never been used in the validation process. This removes objects that have never appeared on any valid manifest.

Shortening the time interval used in step 2 will free more disk space used by the store, at the expense of downloading removed objects again if they are still published in the repository. Extending the time interval used in step 3 will prevent repeated downloads of unused repository objects. However, it will also extend the interval at which unused objects are removed. This creates a risk that such objects will fill up all available disk space if a large enough amount of such objects is published in the repository (either by mistake or with a malicious intent).

Remote Objects Fetcher The fetcher is responsible for downloading objects from remote repositories (described in Section 3 of ) using the rsync protocol or RRDP .

Fetcher Operations For every visited URI, the fetcher keeps track of the last time a successful fetch occurred.

Fetch Repository Objects This operation receives one parameter -- a URI. For an rsync repository, this URI points to a directory. For an RRDP repository, it points to the repository's notification file. The fetcher follows these steps:

1. If data associated with the URI has been downloaded recently (as specified by the local policy), skip the following steps.
2. Download remote objects using the URI provided (for an rsync repository, use recursive mode). If the URI contains the "https" schema and download has failed, issue a warning, replace the "https" schema in the URI with "http", and try to download objects again using the resulting URI.
3. If remote objects cannot be downloaded, issue an error and skip the following steps.
4. Perform syntactic verification of fetched objects. The type of every object (certificate, manifest, CRL, ROA, or Ghostbusters Record) is determined based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of the object is described in Section 4 of for resource certificates, step 1 of Section 3 of for signed objects, Section 4 of for manifests, for CRLs, Section 3 of for ROAs, and Section 5 of for Ghostbusters Records.
5. Put every downloaded and syntactically correct object in the object store ().

The time interval used in step 1 should be chosen based on the acceptable delay in receiving repository updates.

Fetch Single Repository Object This operation receives one parameter -- a URI that points to an object in a repository. The fetcher follows these steps:

1. Download a remote object using the URI provided. If the URI contains the "https" schema and download failed, issue a warning, replace the "https" schema in the URI with "http", and try to download the object using the resulting URI.
2. If the remote object cannot be downloaded, issue an error and skip the following steps.
3. Perform syntactic verification of the fetched object. The type of object (certificate, manifest, CRL, ROA, or Ghostbusters Record) is determined based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of the object is described in Section 4 of for resource certificates, step 1 of Section 3 of for signed objects, Section 4 of for manifests, for CRLs, Section 3 of for ROAs, and Section 5 of for Ghostbusters Records.
4. If the downloaded object is not syntactically correct, issue an error and skip further steps.
5. Delete all objects from the object store () whose URI matches the URI given.
6. Put the downloaded object in the object store ().

Local Object Store

Store Operations

Store Repository Object Put the given object in the store if there is no record with the same hash and URI fields. Note that in the (unlikely) event of hash collision, the given object will not replace the object in the store.

Get Objects by Hash Retrieve all objects from the store whose hash attribute matches the given hash.

Get Certificate Objects by URI Retrieve from the store all objects of type certificate whose URI attribute matches the given URI.

Get Manifest Objects by AKI Retrieve from the store all objects of type manifest whose AKI attribute matches the given AKI.

Delete Objects for a URI For a given URI, delete all objects in the store with a matching URI attribute.

Delete Outdated Objects For a given URI and a list of hashes, delete all objects in the store with a matching URI whose hash attribute is not in the given list of hashes.

Update Object's Validation Time For all objects in the store whose hash attribute matches the given hash, set the last validation time attribute to the given timestamp.

IANA Considerations This document has no IANA actions.

Security Considerations

Hash Collisions This implementation will not detect possible hash collisions in the hashes of repository objects (calculated using the file hash algorithm specified in ). It considers objects with same hash values to be identical.

Algorithm Agility This implementation only supports hash algorithms and key sizes specified in . Algorithm agility described in is not supported.

Mismatch between the Expected and Actual Location of an Object in the Repository According to Section 2 of , all objects issued by a particular CA certificate are expected to be located in one repository publication point, specified in the SIA extension of that CA certificate. The manifest object issued by that CA certificate enumerates all other issued objects, listing their filenames and content hashes. However, it is possible that an object whose content hash matches the hash listed in the manifest either has a different filename or is located at a different publication point in a repository. On the other hand, all RPKI objects, either explicitly or within their embedded EE certificate, have an AKI extension that contains the key identifier of their issuing CA certificate. Therefore, it is always possible to perform an RPKI validation of the object whose expected location does not match its actual location, provided that the certificate that matches the AKI of the object in question is known to the system that performs validation. In the case of a mismatch as described above, this implementation will not exclude an object from further validation merely because its actual location or filename does not match the expected location or filename. This decision was made because the actual location of a file in a repository is taken from the repository retrieval mechanism, which, in the case of an rsync repository, does not provide any cryptographic security, and in the case of an RRDP repository, provides only a transport-layer security with the fallback to unsecured transport. On the other hand, the manifest is an RPKI signed object, and its content could be verified in the context of the RPKI validation.

Manifest Content versus Publication Point Content This algorithm uses the content of a manifest object to determine other objects issued by a CA certificate. It verifies that the manifest is located in the publication point designated in the CA certificate's SIA extension. However, if there are other (not listed in the manifest) objects located in the same publication point directory, they are ignored even if they might be valid and issued by the same CA as the manifest. (This RP behavior is allowed, but not required, by .)

Possible Denial of Service The store cleanup procedure described in tries to minimize removal and subsequent re-fetch of objects that are published in a repository but not used in the validation. Once such objects are removed from the remote repository, they will be discarded from the local object store after a period of time specified by a local policy. By generating an excessive amount of syntactically valid RPKI objects, a man-in-the-middle attack between a validating tool and a repository could force an implementation to fetch and store those objects in the object store (see ) before they are validated and discarded, leading to out-of-memory or out-of-disk-space conditions and, subsequently, a denial of service.

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK] This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) 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 an 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. [STANDARDS-TRACK] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK] In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files. This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features. The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document. This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487. Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation. This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). Informative References

Acknowledgements This document describes the algorithm as it is implemented by the software development team at the RIPE NCC, which, over time, included Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn Visinescu. The authors would also like to acknowledge contributions by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.