idnits 2.17.1 draft-ietf-sidr-rpki-tree-validation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-delta-protocol-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR O. Muravskiy 3 Internet-Draft T. Bruijnzeels 4 Intended status: Informational RIPE NCC 5 Expires: January 9, 2017 July 8, 2016 7 RPKI Certificate Tree Validation by a Relying Party Tool 8 draft-ietf-sidr-rpki-tree-validation-01 10 Abstract 12 This document describes the approach to validate the content of the 13 RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This 14 approach is independent of a particular object retrieval mechanism. 15 This allows it to be used with repositories available over the rsync 16 protocol, the RPKI Repository Delta Protocol, and repositories that 17 use a mix of both. 19 This algorithm does not rely on content of repository directories, 20 but uses the Authority Key Identifier (AKI) field of a manifest and a 21 certificate revocation list (CRL) objects to discover manifest and 22 CRL objects issued by a particular Certificate Authority (CA). It 23 further uses the hashes of manifest entries to discover other objects 24 issued by the CA. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. General Considerations . . . . . . . . . . . . . . . . . . . 3 62 2.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Manifest entries versus repository content . . . . . . . 4 64 3. Top-down Validation of a Single Trust Anchor Certificate Tree 4 65 3.1. Fetching the Trust Anchor Certificate Using the Trust 66 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Resource Certificate Validation . . . . . . . . . . . . . 5 68 3.2.1. Finding the most recent valid manifest and CRL . . . 6 69 3.2.2. Manifest entries validation . . . . . . . . . . . . . 7 70 3.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 7 71 4. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 8 72 4.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 8 73 4.1.1. Fetch repository objects . . . . . . . . . . . . . . 8 74 4.1.2. Fetch single repository object . . . . . . . . . . . 9 75 5. Local Object Store . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Store Operations . . . . . . . . . . . . . . . . . . . . 9 77 5.1.1. Store Repository Object . . . . . . . . . . . . . . . 9 78 5.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 9 79 5.1.3. Get certificate objects by URI . . . . . . . . . . . 10 80 5.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 10 81 5.1.5. Delete objects for a URI . . . . . . . . . . . . . . 10 82 5.1.6. Delete outdated objects . . . . . . . . . . . . . . . 10 83 5.1.7. Update object's validation time . . . . . . . . . . . 10 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 In order to use information published in RPKI repositories, Relying 95 Parties (RP) need to retrieve and validate the content of 96 certificates, CRLs, and other RPKI signed objects. To validate a 97 particular object, one must ensure that all certificates in the 98 certificate chain up to the Trust Anchor (TA) are valid. Therefore 99 the validation of a certificate tree is usually performed top-down, 100 starting from the TA certificate and descending down the certificate 101 chain, validating every encountered certificate and its products. 102 The result of this process is a list of all encountered RPKI objects 103 with a validity status attached to each of them. These results may 104 later be used by a Relying Party in taking routing decisions, etc. 106 Traditionally RPKI data is made available to RPs through the 107 repositories [RFC6481] accessible over rsync protocol. Relying 108 parties are advised to keep a local copy of repository data, and 109 perform regular updates of this copy from the repository (Section 5 110 of [RFC6481]). The RPKI Repository Delta Protocol 111 [I-D.ietf-sidr-delta-protocol] introduces another method to fetch 112 repository data and keep the local copy up to date with the 113 repository. 115 This document describes how the RIPE NCC RPKI Validator discovers 116 RPKI objects to download, builds certificate paths, and validates 117 RPKI objects, independently from what repository access protocol is 118 used. To achieve this, it puts downloaded RPKI objects in an object 119 store, where objects could be found by their URI, hash of their 120 content, value of the object's AKI field, or combination of these. 121 It also keeps track of download and validation time for every object, 122 to perform cleanups of the local copy. 124 2. General Considerations 126 2.1. Hash comparisons 128 This algorithm relies on the properties of the file hash algorithm 129 (defined in [RFC6485]) to compute the hash of repository objects. It 130 assumes that any two objects for which the hash value is the same, 131 are identical. 133 The hash comparison is used when matching objects in the repository 134 with entries on the manifest, and when looking up objects in the 135 object store (Section 5). 137 2.2. Manifest entries versus repository content 139 There are several possible ways of discovering products of a CA 140 certificate: one could use all objects located in a repository 141 directory designated as a publication point for a CA, or only objects 142 mentioned on the manifest located at that publication point (see 143 Section 6 of [RFC6486]), or use all objects whose AKI field matches 144 the SKI field of a CA certificate. 146 Since the current set of RPKI standards requires use of the manifest 147 [RFC6486] to describe the content of a publication point, this 148 implementation requires a consistency between the publication point 149 content and manifest content. Therefore it will not use in the 150 validation process objects that are found in the publication point 151 but do not match any of the entries of that publication point's 152 manifest (see Section 3.2.2). It will also issue warnings for all 153 found mismatches, so that the responsible operators could be made 154 aware of inconsistencies and fix them. 156 3. Top-down Validation of a Single Trust Anchor Certificate Tree 158 1. The validation of a Trust Anchor (TA) certificate tree starts 159 from its TA certificate. To retrieve the TA certificate, a Trust 160 Anchor Locator (TAL) object is used, as described in Section 3.1. 162 2. If the TA certificate is retrieved, it is validated according to 163 the Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. 165 3. If the TA certificate is valid, then all its subordinate objects 166 are validated as described in Section 3.2. Otherwise the 167 validation of certificate tree is aborted and an error is issued. 169 4. For all repository objects that were validated during this 170 validation run, their validation timestamp is updated in an 171 object store (see Section 5.1.7). 173 5. Outdated objects are removed from the store as described in 174 Section 3.3. This completes the validation of the TA certificate 175 tree. 177 3.1. Fetching the Trust Anchor Certificate Using the Trust Anchor 178 Locator 180 The following steps are performed in order to fetch the Trust Anchor 181 Certificate: 183 1. (Optional) If the Trust Anchor Locator contains a "prefetch.uris" 184 field, pass the URIs contained in that field to the fetcher (see 185 Section 4.1.1). (This field is a non-standard extension to the 186 TAL format. It helps fetching non-hierarchical rsync 187 repositories more efficiently.) 189 2. Extract the TA certificate URI from the TAL's URI section (see 190 Section 2.1 of [RFC7730]) and pass it to the object fetcher 191 (Section 4.1.2). 193 3. Retrieve from the object store (see Section 5.1.3) all 194 certificate objects, for which the URI matches the URI extracted 195 from the TAL in the previous step, and the public key matches the 196 subjectPublicKeyInfo field of the TAL (see Section 2.1 of 197 [RFC7730]). 199 4. If no, or more than one such objects are found, issue an error 200 and abort certificate tree validation process with an error. 201 Otherwise, use the single found object as the Trust Anchor 202 certificate. 204 3.2. Resource Certificate Validation 206 The following steps describe the validation of a single resource 207 certificate: 209 1. If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 210 id-ad-rpkiNotify (Section 3.5 of [I-D.ietf-sidr-delta-protocol]) 211 SIA pointers are present in the given resource certificate, use a 212 local policy to determine which pointer to use. Extract the URI 213 from the selected pointer and pass it to the object fetcher (see 214 Section 4.1.1). 216 2. For a given resource certificate, find its manifest and 217 certificate revocation list (CRL), using the procedure described 218 in Section 3.2.1. If no such manifest and CRL could be found, 219 stop validation of this certificate, consider it invalid, and 220 issue an error. 222 3. Compare the URI found in the given resource certificate's id-ad- 223 rpkiManifest field (Section 4.8.8.1 of [RFC6487]) with the URI of 224 the manifest found in the previous step. If they are different, 225 issue a warning. 227 4. Perform manifest entries discovery and validation as described in 228 Section 3.2.2. 230 5. Validate all resource certificate objects found on the manifest, 231 using the CRL object found on the manifest, according to 232 Section 7 of [RFC6487]. 234 6. Validate all ROA objects found on the manifest, using the CRL 235 object found on the manifest, according to the Section 4 of 236 [RFC6482]. 238 7. Validate all Ghostbusters Record objects found on the manifest, 239 using the CRL object found on the manifest, according to the 240 Section 7 of [RFC6493]. 242 8. For every valid resource certificate object found on the 243 manifest, apply the procedure described in this section 244 (Section 3.2), recursively, provided that this resource 245 certificate (identified by its SKI) has not yet been validated 246 during current repository validation run. 248 3.2.1. Finding the most recent valid manifest and CRL 250 1. Fetch from the store (see Section 5.1.4) all objects of type 251 manifest, whose certificate's AKI field matches the SKI of the 252 current CA certificate. If no such objects are found, stop 253 processing current resource certificate and issue an error. 255 2. Find among found objects the manifest object with the highest 256 manifestNumber field (Section 4.2.1 of [RFC6486]), for which all 257 following conditions are met: 259 * There is only one entry in the manifest for which the store 260 contains exactly one object of type CRL, whose hash matches 261 the hash of the entry. 263 * The manifest's certificate AKI equals the above CRL's AKI. 265 * The above CRL is a valid object according to Section 6.3 of 266 [RFC5280]. 268 * The manifest is a valid object according to Section 4.4 of 269 [RFC6486], using the CRL found above. 271 3. If there is an object that matches above criteria, consider this 272 object to be the valid manifest, and the CRL found at the 273 previous step - the valid CRL for the current CA certificate's 274 publication point. 276 4. Report an error for every other manifest with a number higher 277 than the number of the valid manifest. 279 3.2.2. Manifest entries validation 281 For every entry in the manifest object: 283 1. Construct an entry's URI by appending the entry name to the 284 current CA's publication point URI. 286 2. Get all objects from the store whose hash attribute equals 287 entry's hash (see Section 5.1.2). 289 3. If no such objects are found, issue an error for this manifest 290 entry and progress to the next entry. This case indicates that 291 the repository does not have an object at the location listed in 292 the manifest, or that the object's hash does not match the hash 293 listed in the manifest. 295 4. For every found object, compare its URI with the URI of the 296 manifest entry. 298 * For every object with non-matching URI issue a warning. This 299 case indicates that the object from the manifest entry is 300 found at a different location in a (possibly different) 301 repository. 303 * If no objects with matching URI found, issue a warning. This 304 case indicates that there is no object found in the repository 305 at the location listed in the manifest entry (but there is at 306 least one matching object found at a different location). 308 5. Use all found objects for further validation. 310 3.3. Object Store Cleanup 312 At the end of the TA tree validation the store cleanup is performed: 314 1. Given all objects that were encountered during the current 315 validation run, remove from the store (Section 5.1.6) all objects 316 whose URI attribute matches the URI of one of the encountered 317 objects, but the content's hash is different. This removes from 318 the store objects that were replaced in the repository by their 319 newer versions at the same URIs. 321 2. Remove from the store all objects that were last encountered 322 during validation long time ago (as specified by the local 323 policy). This removes objects that do not appear on any valid 324 manifest anymore (but possibly still published in a repository). 326 3. Remove from the store all objects that were downloaded recently 327 (as specified by the local policy), but have never been used in a 328 validation process. This removes objects that have never 329 appeared on any valid manifest. 331 Shortening the time interval used in step 2 will free disk space used 332 by the store, to the expense of downloading removed objects again if 333 they are still published in the repository. 335 Extending the time interval used in step 3 will prevent repeated 336 downloads of repository objects, with the risk that such objects, if 337 created massively by mistake or adversely, will fill up local disk 338 space, if they are not cleaned up promptly. 340 4. Remote Objects Fetcher 342 The fetcher is responsible for downloading objects from remote 343 repositories (described in Section 3 of [RFC6481]) using rsync 344 protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) 345 ([I-D.ietf-sidr-delta-protocol]). 347 4.1. Fetcher Operations 349 For every successfully visited URI the fetcher keeps track of the 350 last time it happened. 352 4.1.1. Fetch repository objects 354 This operation receives one parameter - a URI. For rsync protocol 355 this URI points to a directory in a remote repository. For RRDP 356 repository it points to the repository's notification file. 358 The fetcher performs following steps: 360 1. If data associated with the URI has been downloaded recently (as 361 specified by the local policy), skip following steps. 363 2. Download the remote objects using the URI provided (for an rsync 364 repository use a recursive mode). 366 3. For every new object that is downloaded, try to parse it as an 367 object of specific RPKI type (certificate, manifest, CRL, ROA, 368 Ghostbusters record), based on the object's filename extension 369 (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform 370 basic RPKI object validation (excluding resource certification 371 path validation), as specified in [RFC6487] and [RFC6488]. 373 4. Put every downloaded valid object in the object store 374 (Section 5.1.1). 376 The time interval used in the step 1 should be chosen based on the 377 acceptable delay in receiving repository updates. 379 4.1.2. Fetch single repository object 381 This operation receives one parameter - a URI that points to an 382 object in a repository. 384 The fetcher performs following operations: 386 1. If data associated with the URI has been downloaded recently (as 387 specified by the local policy), skip all following steps. 389 2. Download the remote object using the URI provided. 391 3. Try to parse the downloaded object as an object of a specific 392 RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record), 393 based on the object's filename extension (.cer, .mft, .crl, .roa, 394 and .gbr, respectively), and perform basic RPKI object validation 395 (excluding resource certification path validation), as specified 396 in [RFC6487] and [RFC6488]. 398 4. If the downloaded object is not valid, issue an error and skip 399 further steps. 401 5. Delete all objects from the object store (Section 5.1.5) whose 402 URI matches the URI given. 404 6. Put the validated object in the object store (Section 5.1.1). 406 5. Local Object Store 408 5.1. Store Operations 410 5.1.1. Store Repository Object 412 Put given object in the store, along with its type, URI, hash, and 413 AKI, if there is no record with the same hash and URI fields. 415 5.1.2. Get objects by hash 417 Retrieve all objects from the store whose hash attribute matches the 418 given hash. 420 5.1.3. Get certificate objects by URI 422 Retrieve from the store all objects of type certificate, whose URI 423 attribute matches the given URI. 425 5.1.4. Get manifest objects by AKI 427 Retrieve from the store all objects of type manifest, whose AKI 428 attribute matches the given AKI. 430 5.1.5. Delete objects for a URI 432 For a given URI, delete all objects in the store with matching URI 433 attribute. 435 5.1.6. Delete outdated objects 437 For a given URI and a list of hashes, delete all objects in the store 438 with matching URI, whose hash attribute is not in the given list of 439 hashes. 441 5.1.7. Update object's validation time 443 For all objects in the store whose hash attribute matches the given 444 hash, set the last validation time attribute to the given timestamp. 446 6. Acknowledgements 448 This document describes the algorithm as it is implemented by the 449 software development team at the RIPE NCC. The authors would also 450 like to acknowledge contributions by Carlos Martinez, Andy Newton, 451 and Rob Austein. 453 7. IANA Considerations 455 This document has no actions for IANA. 457 8. Security Considerations 459 This implementation will not detect possible hash collisions in the 460 hashes of repository objects (calculated using the file hash 461 algorithm specified in [RFC6485]), and considers objects with same 462 hash values as identical. 464 This algorithm uses the content of a manifest object to discover 465 other objects issued by a specified CA. It verifies that the 466 manifest is located in the publication point designated in the CA 467 Certificate. However, if there are other (not listed in the 468 manifest) objects located in that publication point directory, they 469 will be ignored, even if their content is correct and they are issued 470 by the same CA as the manifest. 472 In contrast, objects whose content hash matches the hash listed in 473 the manifest, but that are not located in the publication directory 474 listed in their CA certificate, will be used in the validation 475 process (although a warning will be issued in that case). 477 The store cleanup procedure described in Section 3.3 tries to 478 minimise removal and subsequent re-fetch of objects that are 479 published in a repository but not used in the validation. Once such 480 objects are removed from the remote repository, they will be 481 discarded from the local object store after a period of time 482 specified by a local policy. By generating an excessive amount of 483 syntactically valid RPKI objects, a man-in-the-middle attack between 484 a validating tool and a repository could force an implementation to 485 fetch and store those objects in the object store before they are 486 validated and discarded, leading to an out-of-memory or out-of-disk- 487 space conditions, and, subsequently, a denial of service. 489 9. References 491 9.1. Normative References 493 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 494 Housley, R., and W. Polk, "Internet X.509 Public Key 495 Infrastructure Certificate and Certificate Revocation List 496 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 497 . 499 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 500 Resource Certificate Repository Structure", RFC 6481, 501 DOI 10.17487/RFC6481, February 2012, 502 . 504 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 505 Origin Authorizations (ROAs)", RFC 6482, 506 DOI 10.17487/RFC6482, February 2012, 507 . 509 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 510 Use in the Resource Public Key Infrastructure (RPKI)", 511 RFC 6485, DOI 10.17487/RFC6485, February 2012, 512 . 514 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 515 "Manifests for the Resource Public Key Infrastructure 516 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 517 . 519 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 520 X.509 PKIX Resource Certificates", RFC 6487, 521 DOI 10.17487/RFC6487, February 2012, 522 . 524 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 525 Template for the Resource Public Key Infrastructure 526 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 527 . 529 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 530 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 531 February 2012, . 533 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 534 "Resource Public Key Infrastructure (RPKI) Trust Anchor 535 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 536 . 538 9.2. Informative References 540 [I-D.ietf-sidr-delta-protocol] 541 Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R., 542 and D. Mandelberg, "RPKI Repository Delta Protocol", 543 draft-ietf-sidr-delta-protocol-02 (work in progress), 544 March 2016. 546 [rsync] "Rsync home page", . 548 Authors' Addresses 550 Oleg Muravskiy 551 RIPE NCC 553 Email: oleg@ripe.net 555 Tim Bruijnzeels 556 RIPE NCC 558 Email: tim@ripe.net