draft-ietf-sidrops-rpki-tree-validation-00.txt   draft-ietf-sidrops-rpki-tree-validation-01.txt 
SIDR Operations O. Muravskiy SIDR Operations O. Muravskiy
Internet-Draft T. Bruijnzeels Internet-Draft T. Bruijnzeels
Intended status: Informational RIPE NCC Intended status: Informational RIPE NCC
Expires: July 18, 2017 January 14, 2017 Expires: January 20, 2018 July 19, 2017
RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator
draft-ietf-sidrops-rpki-tree-validation-00 draft-ietf-sidrops-rpki-tree-validation-01
Abstract Abstract
This document describes the approach to validate the content of the This document describes the approach to validate the content of the
RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This RPKI certificate tree, as it is implemented in the RIPE NCC RPKI
approach is independent of a particular object retrieval mechanism. Validator. This approach is independent of a particular object
This allows it to be used with repositories available over the rsync retrieval mechanism. This allows it to be used with repositories
protocol, the RPKI Repository Delta Protocol, and repositories that available over the rsync protocol, the RPKI Repository Delta
use a mix of both. Protocol, and repositories that use a mix of both.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2017. This Internet-Draft will expire on January 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Considerations . . . . . . . . . . . . . . . . . . . 4 3. General Considerations . . . . . . . . . . . . . . . . . . . 4
3.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 4 3.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 4
3.2. Discovery of RPKI objects issued by a CA . . . . . . . . 4 3.2. Discovery of RPKI objects issued by a CA . . . . . . . . 4
3.3. Manifest entries versus repository content . . . . . . . 4 3.3. Manifest entries versus repository content . . . . . . . 4
4. Top-down Validation of a Single Trust Anchor Certificate Tree 5 4. Top-down Validation of a Single Trust Anchor Certificate Tree 5
4.1. Fetching the Trust Anchor Certificate Using the Trust 4.1. Fetching the Trust Anchor Certificate Using the Trust
Anchor Locator . . . . . . . . . . . . . . . . . . . . . 5 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 5
4.2. CA Certificate Validation . . . . . . . . . . . . . . . . 6 4.2. CA Certificate Validation . . . . . . . . . . . . . . . . 6
4.2.1. Finding the most recent valid manifest and CRL . . . 7 4.2.1. Finding the most recent valid manifest and CRL . . . 7
4.2.2. Manifest entries validation . . . . . . . . . . . . . 7 4.2.2. Manifest entries validation . . . . . . . . . . . . . 8
4.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 8 4.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 9
5. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 9 5. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 9
5.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 9 5.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 9
5.1.1. Fetch repository objects . . . . . . . . . . . . . . 9 5.1.1. Fetch repository objects . . . . . . . . . . . . . . 10
5.1.2. Fetch single repository object . . . . . . . . . . . 10 5.1.2. Fetch single repository object . . . . . . . . . . . 10
6. Local Object Store . . . . . . . . . . . . . . . . . . . . . 11 6. Local Object Store . . . . . . . . . . . . . . . . . . . . . 11
6.1. Store Operations . . . . . . . . . . . . . . . . . . . . 11 6.1. Store Operations . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Store Repository Object . . . . . . . . . . . . . . . 11 6.1.1. Store Repository Object . . . . . . . . . . . . . . . 11
6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11 6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11
6.1.3. Get certificate objects by URI . . . . . . . . . . . 11 6.1.3. Get certificate objects by URI . . . . . . . . . . . 11
6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11 6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11
6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 11 6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12
6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 11 6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12
6.1.7. Update object's validation time . . . . . . . . . . . 11 6.1.7. Update object's validation time . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12 9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12
9.2. Mismatch between the expected and the actual location of 9.2. Mismatch between the expected and the actual location of
an object in the repository . . . . . . . . . . . . . . . 12 an object in the repository . . . . . . . . . . . . . . . 12
9.3. Manifest content versus publication point content . . . . 13 9.3. Manifest content versus publication point content . . . . 13
9.4. Storing of a TA certificate object before its complete 9.4. Storing of a TA certificate object before its complete
validation . . . . . . . . . . . . . . . . . . . . . . . 13 validation . . . . . . . . . . . . . . . . . . . . . . . 13
9.5. Possible denial of service . . . . . . . . . . . . . . . 13 9.5. Possible denial of service . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Scope of this document 1. Scope of this document
This document describes how the RIPE NCC RPKI Validator version 2.23 This document describes how the RIPE NCC RPKI Validator version 2.23
has been implemented. Source code to this software can be found has been implemented. Source code to this software can be found at
here: [github]. The purpose of this document is to provide [github]. The purpose of this document is to provide transparency to
transparency to users of (and contributors to) this software tool, as users of (and contributors to) this software tool, as well as serve
well as serve to be subjected to scrutiny by the SIDR Operations to be subjected to scrutiny by the SIDR Operations Working Group. It
Working Group. It is not intended as a document that describes a is not intended as a document that describes a standard or best
standard or best practices on how validation should be done in practices on how validation should be done in general.
general.
2. Introduction 2. Introduction
In order to use information published in RPKI repositories, Relying In order to use information published in RPKI repositories, Relying
Parties (RP) need to retrieve and validate the content of Parties (RP) need to retrieve and validate the content of
certificates, certificate revocation lists (CRLs), and other RPKI certificates, certificate revocation lists (CRLs), and other RPKI
signed objects. To validate a particular object, one must ensure signed objects. To validate a particular object, one must ensure
that all certificates in the certificate chain up to the Trust Anchor that all certificates in the certificate chain up to the Trust Anchor
(TA) are valid. Therefore the validation of a certificate tree is (TA) are valid. Therefore the validation of a certificate tree is
performed top-down, starting from the TA certificate and descending performed top-down, starting from the TA certificate and descending
skipping to change at page 6, line 43 skipping to change at page 6, line 43
step. If they are different, issue a warning, but continue step. If they are different, issue a warning, but continue
validation process using this manifest object. (This warning validation process using this manifest object. (This warning
indicates that there is a mismatch between the expected and the indicates that there is a mismatch between the expected and the
actual location of an object in a repository. See Section 9 for actual location of an object in a repository. See Section 9 for
the explanation of this mismatch and the decision taken.) the explanation of this mismatch and the decision taken.)
4. Perform manifest entries discovery and validation as described in 4. Perform manifest entries discovery and validation as described in
Section 4.2.2. Section 4.2.2.
5. Validate all resource certificate objects found on the manifest, 5. Validate all resource certificate objects found on the manifest,
using the CRL object found on the manifest, according to using the CRL object found on the manifest:
Section 7 of [RFC6487].
* 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].
(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
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].)
6. Validate all ROA objects found on the manifest, using the CRL 6. Validate all ROA objects found on the manifest, using the CRL
object found on the manifest, according to Section 4 of object found on the manifest, according to Section 4 of
[RFC6482]. [RFC6482].
7. Validate all Ghostbusters Record objects found on the manifest, 7. Validate all Ghostbusters Record objects found on the manifest,
using the CRL object found on the manifest, according to using the CRL object found on the manifest, according to
Section 7 of [RFC6493]. Section 7 of [RFC6493].
8. For every valid CA certificate object found on the manifest, 8. For every valid CA certificate object found on the manifest,
skipping to change at page 13, line 48 skipping to change at page 14, line 25
syntactically valid RPKI objects, a man-in-the-middle attack between syntactically valid RPKI objects, a man-in-the-middle attack between
a validating tool and a repository could force an implementation to a validating tool and a repository could force an implementation to
fetch and store those objects in the object store before they are 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- validated and discarded, leading to an out-of-memory or out-of-disk-
space conditions, and, subsequently, a denial of service. space conditions, and, subsequently, a denial of service.
10. References 10. References
10.1. Normative 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-08 (work in
progress), June 2017.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<http://www.rfc-editor.org/info/rfc6481>. <http://www.rfc-editor.org/info/rfc6481>.
skipping to change at page 14, line 49 skipping to change at page 15, line 39
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor "Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
<http://www.rfc-editor.org/info/rfc7730>. <http://www.rfc-editor.org/info/rfc7730>.
10.2. Informative References 10.2. Informative References
[github] "RIPE NCC RPKI Validator on GitHub", <https://github.com/ [github] "RIPE NCC RPKI Validator on GitHub", <https://github.com/
RIPE-NCC/rpki-validator>. RIPE-NCC/rpki-validator>.
[I-D.ietf-sidr-delta-protocol]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"RPKI Repository Delta Protocol", draft-ietf-sidr-delta-
protocol-04 (work in progress), September 2016.
[rsync] "Rsync home page", <https://rsync.samba.org>. [rsync] "Rsync home page", <https://rsync.samba.org>.
Authors' Addresses Authors' Addresses
Oleg Muravskiy Oleg Muravskiy
RIPE NCC RIPE NCC
Email: oleg@ripe.net Email: oleg@ripe.net
Tim Bruijnzeels Tim Bruijnzeels
 End of changes. 12 change blocks. 
33 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/