--- 1/draft-ietf-sidrops-rpki-tree-validation-02.txt 2018-09-16 17:13:14.119098158 -0700 +++ 2/draft-ietf-sidrops-rpki-tree-validation-03.txt 2018-09-16 17:13:14.155099024 -0700 @@ -1,19 +1,19 @@ SIDR Operations O. Muravskiy Internet-Draft RIPE NCC Intended status: Informational T. Bruijnzeels -Expires: December 30, 2018 NLNetLabs - June 28, 2018 +Expires: March 20, 2019 NLNetLabs + September 16, 2018 RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator - draft-ietf-sidrops-rpki-tree-validation-02 + draft-ietf-sidrops-rpki-tree-validation-03 Abstract This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. @@ -25,21 +25,21 @@ 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 https://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 December 30, 2018. + This Internet-Draft will expire on March 20, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,25 +74,24 @@ 6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11 6.1.3. Get certificate objects by URI . . . . . . . . . . . 11 6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11 6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12 6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12 6.1.7. Update object's validation time . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12 - 9.2. Mismatch between the expected and the actual location of - an object in the repository . . . . . . . . . . . . . . . 12 - 9.3. Manifest content versus publication point content . . . . 13 - 9.4. Storing of a TA certificate object before its complete - validation . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.2. Algorithm agility . . . . . . . . . . . . . . . . . . . . 12 + 9.3. Mismatch between the expected and the actual location of + an object in the repository . . . . . . . . . . . . . . . 13 + 9.4. Manifest content versus publication point content . . . . 13 9.5. Possible denial of service . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Scope of this document This document describes how the RIPE NCC RPKI Validator version 2.23 has been implemented. Source code to this software can be found at @@ -114,58 +113,57 @@ down 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 a Relying Party in taking routing decisions, etc. Traditionally RPKI data is made available to RPs through the repositories [RFC6481] accessible over [rsync] protocol. Relying parties are advised to keep a local copy of repository data, and perform regular updates of this copy from the repository (Section 5 - of [RFC6481]). The RPKI Repository Delta Protocol - [I-D.ietf-sidr-delta-protocol] introduces another method to fetch - repository data and keep the local copy up to date with the - repository. + of [RFC6481]). The RPKI Repository Delta Protocol [RFC8182] + 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 from 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, value of its Authority Key Identifier (AKI) extension, or a combination of these. It also keeps track of the download and the validation time for every object, to decide which locally stored objects are not used in the RPKI tree validation and could be removed. 3. General Considerations 3.1. Hash comparisons - This algorithm relies on the properties of the file hash algorithm - (defined in [RFC6485]) to compute the hash of repository objects. It - assumes that any two objects for which the hash value is the same, - are identical. + This algorithm relies on the collision resistance properties of the + file hash algorithm (defined in [RFC7935]) 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 (Section 4.2.2), and when looking up objects in the object store (Section 6). 3.2. Discovery of RPKI objects issued by a CA - There are several possible ways of discovering products of a CA - certificate: one could use all objects located in a repository + There are several possible ways of discovering potential products of + a CA certificate: one could use all objects located in a repository directory designated as a publication point for a CA, or only objects mentioned on the manifest located at that publication point (see - Section 6 of [RFC6486]), or use all objects whose AKI extension - matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of - [RFC5280]) of a CA certificate. + Section 6 of[RFC6486]), or use all known repository objects whose AKI + extension matches the Subject Key Identifier (SKI) extension + (Section 4.2.1 of[RFC5280]) 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 [RFC6486] 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 certificate revocation list (CRL) to @@ -239,68 +237,68 @@ and abort certificate tree validation process with an error. Otherwise, use the single found object as the Trust Anchor certificate. 4.2. 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 [RFC6487]), and the - id-ad-rpkiNotify (Section 3.2 of [I-D.ietf-sidr-delta-protocol]) - SIA pointers are present in the CA certificate, use a local + id-ad-rpkiNotify (Section 3.2 of [RFC8182]) SubjectInfoAccess + (SIA) pointers are present in 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 (see + the selected pointer and pass it to the object fetcher (that will + then fetch all objects available from that repository, see Section 5.1.1). 2. For the CA certificate, find the current manifest and certificate revocation list (CRL), using the procedure described in Section 4.2.1. 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 [RFC6487]) 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 - validation process using this manifest object. (This warning - indicates that there is a mismatch between the expected and the - actual location of an object in a repository. See Section 9 for - the explanation of this mismatch and the decision taken.) + 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 Section 9 for the explanation of this mismatch and the + decision taken.) 4. Perform manifest entries discovery and validation as described in Section 4.2.2. 5. Validate all resource certificate objects found on the manifest, using the CRL object found on the manifest: * if the strict validation option is enabled by the operator, the validation is performed according to Section 7 of [RFC6487], * otherwise, the validation is performed according to Section 7 of [RFC6487], with the exception of the resource certification path validation, that is performed according to - Section 4.2.4.4 of - [I-D.ietf-sidr-rpki-validation-reconsidered]. + Section 4.2.4.4 of [RFC8360]. (Note that this implementation uses the operator configuration to decide which algorithm to use for path validation. It applies - selected algorithm to all resource certificates, rather than + the selected algorithm to all resource certificates, rather than applying appropriate algorithm per resource certificate, based on the object identifier (OID) for the Certificate Policy found in - that certificate, as specified in - [I-D.ietf-sidr-rpki-validation-reconsidered].) + that certificate, as specified in [RFC8360].) - 6. Validate all ROA objects found on the manifest, using the CRL - object found on the manifest, according to Section 4 of - [RFC6482]. + 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 [RFC6482]. 7. Validate all Ghostbusters Record objects found on the manifest, using the CRL object found on the manifest, according to Section 7 of [RFC6493]. 8. For every valid CA certificate object found on the manifest, apply the procedure described in this section (Section 4.2), recursively, provided that this CA certificate (identified by its SKI) has not yet been validated during current tree validation run. @@ -364,21 +362,21 @@ * 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 Section 4.2. Please note that the above steps will not reject objects whose hash matches the hash listed in the manifest, but the URI does not. See - Section 9.2 for additional information. + Section 9.3 for additional information. 4.3. 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 (Section 6.1.6) all objects whose URI attribute matches the URI of one of the encountered objects, but the content's hash is different. This removes from @@ -403,21 +401,21 @@ Extending the time interval used in step 3 will prevent repeated downloads of repository objects, with the risk that such objects, if created massively by mistake or by an adversary, will fill up local disk space, if they are not cleaned up promptly. 5. Remote Objects Fetcher The fetcher is responsible for downloading objects from remote repositories (described in Section 3 of [RFC6481]) using rsync protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) - ([I-D.ietf-sidr-delta-protocol]). + ([RFC8182]). 5.1. Fetcher Operations For every visited URI the fetcher keeps track of the last time a successful fetch occurred. 5.1.1. 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 @@ -524,38 +522,47 @@ hashes. 6.1.7. 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. 7. Acknowledgements This document describes the algorithm as it is implemented by the - software development team at the RIPE NCC. The authors would also - like to acknowledge contributions by Carlos Martinez, Andy Newton, - Rob Austein, and Stephen Kent. + software development team at the RIPE NCC, which included over time: + 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. 8. IANA Considerations This document has no actions for IANA. 9. Security Considerations 9.1. Hash collisions This implementation will not detect possible hash collisions in the hashes of repository objects (calculated using the file hash - algorithm specified in [RFC6485]). It considers objects with same + algorithm specified in [RFC7935]). It considers objects with same hash values as identical. -9.2. Mismatch between the expected and the actual location of an object +9.2. Algorithm agility + + This implementation only supports hash algorithms and key sizes + specified in [RFC7935]). Algorithm agility described in [RFC6916] is + not supported. + +9.3. Mismatch between the expected and the actual location of an object in the repository According to Section 2 of [RFC6481], 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 file names and content hashes. However, it is possible that an object whose content hash matches the @@ -565,139 +572,131 @@ On the other hand, all RPKI objects, either explicitly or within their embedded EE certificate, have an Authority Key Identifier 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 case of a mismatch described above this implementation will not - exclude an object from further validation merely because it's actual + exclude an object from further validation merely because its actual location or file name does not match the expected location or file name. This decision was chosen because the actual location of a file in a repository is taken from the repository retrieval mechanism, which, in case of an rsync repository, does not provide any cryptographic security, and in 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. -9.3. Manifest content versus publication point content +9.4. 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 certificate as the manifest. (This behavior is - allowed, but not required, by [RFC6486].) - -9.4. Storing of a TA certificate object before its complete validation - - When fetching and storing a TA certificate to the object store, only - a syntactic validation of a downloaded object is performed before - newly downloaded object replaces the previously downloaded object in - the object store (see Section 5.1.2). If an attacker will be able to - replace a genuine TA certificate by a syntactically valid certificate - object (either by manipulating the content of a repository, or by a - man-in-the-middle attack), this implementation will discard - previously downloaded genuine object, and replace it by a false - object. Such false object will be detected later, but the validation - of the whole RPKI tree under this TA will be aborted, as described in - Section 4. + by the same CA as the manifest. (This RP behavior is allowed, but + not required, by [RFC6486].) 9.5. Possible denial of service The store cleanup procedure described in Section 4.3 tries to minimise 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 before they are - validated and discarded, leading to an out-of-memory or out-of-disk- - space conditions, and, subsequently, a denial of service. + fetch and store those objects in the object store (see Section 5.1.1) + before they are validated and discarded, leading to an out-of-memory + or out-of-disk-space conditions, and, subsequently, a denial of + service. 10. References 10.1. Normative References - [I-D.ietf-sidr-delta-protocol] - Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, - "RPKI Repository Delta Protocol (RRDP)", draft-ietf-sidr- - delta-protocol-08 (work in progress), March 2017. - - [I-D.ietf-sidr-rpki-validation-reconsidered] - Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., - Newton, A., and D. Shaw, "RPKI Validation Reconsidered", - draft-ietf-sidr-rpki-validation-reconsidered-10 (work in - progress), December 2017. - [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, DOI 10.17487/RFC5280, May 2008, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . - [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for - Use in the Resource Public Key Infrastructure (RPKI)", - RFC 6485, DOI 10.17487/RFC6485, February 2012, - . - [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . + [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility + Procedure for the Resource Public Key Infrastructure + (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April + 2013, . + [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, . + [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for + Algorithms and Key Sizes for Use in the Resource Public + Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, + August 2016, . + + [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, + "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, + DOI 10.17487/RFC8182, July 2017, + . + + [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., + Newton, A., and D. Shaw, "Resource Public Key + Infrastructure (RPKI) Validation Reconsidered", RFC 8360, + DOI 10.17487/RFC8360, April 2018, + . + 10.2. Informative References [github] "RIPE NCC RPKI Validator on GitHub", . [rsync] "Rsync home page", . Authors' Addresses - Oleg Muravskiy RIPE NCC Email: oleg@ripe.net URI: https://www.ripe.net/ + Tim Bruijnzeels NLNetLabs Email: tim@nlnetlabs.nl URI: https://www.nlnetlabs.nl/