idnits 2.17.1 draft-ietf-sidr-rpki-tree-validation-00.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 (March 21, 2016) is 2955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: 2 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: September 22, 2016 March 21, 2016 7 RPKI Certificate Tree Validation by a Relying Party Tool 8 draft-ietf-sidr-rpki-tree-validation-00 10 Abstract 12 This document currently describes the approach to validate the 13 content of the RPKI certificate tree, as used by the RIPE NCC RPKI 14 Validator. This approach is independent of a particular object 15 retrieval mechanism. This allows it to be used with repositories 16 available over the rsync protocol, the RPKI Repository Delta 17 Protocol, and repositories that 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 If the working group finds that algorithm outlined here is useful for 27 other implementations, we may either update future revisions of this 28 document to be less specific to the RIPE NCC RPKI Validator 29 implementation, or we may use this document as a starting point of a 30 generic validation document and keep this as a detailed description 31 of the actual RIPE NCC RPKI Validator implementation. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 22, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Top-down Validation of a Single Trust Anchor Certificate Tree 3 69 2.1. Fetching the Trust Anchor Certificate Using the Trust 70 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Resource Certificate Validation . . . . . . . . . . . . . 4 72 2.2.1. Finding most recent valid manifest and CRL . . . . . 5 73 2.2.2. Manifest entries validation . . . . . . . . . . . . . 6 74 2.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 6 75 3. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 6 76 3.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 7 77 3.1.1. Fetch repository objects . . . . . . . . . . . . . . 7 78 3.1.2. Fetch single repository object . . . . . . . . . . . 7 79 4. Local Object Store . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Store Operations . . . . . . . . . . . . . . . . . . . . 8 81 4.1.1. Store Repository Object . . . . . . . . . . . . . . . 8 82 4.1.2. Update object's last fetch time . . . . . . . . . . . 8 83 4.1.3. Get objects by hash . . . . . . . . . . . . . . . . . 8 84 4.1.4. Get certificate objects by URI . . . . . . . . . . . 8 85 4.1.5. Get manifest objects by AKI . . . . . . . . . . . . . 8 86 4.1.6. Delete objects for URI . . . . . . . . . . . . . . . 8 87 4.1.7. Delete outdated objects . . . . . . . . . . . . . . . 8 88 4.1.8. Update object's validation time . . . . . . . . . . . 9 89 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 94 8.2. Informative References . . . . . . . . . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 97 1. Introduction 99 In order to use information published in RPKI repositories, Relying 100 Parties (RP) need to retrieve and validate the content of 101 certificates, CRLs, and other RPKI signed objects. To validate a 102 particular object, one must ensure that all certificates in the 103 certificate chain up to the Trust Anchor (TA) are valid. Therefore 104 the validation of a certificate tree is usually performed top-down, 105 starting from the TA certificate and descending down the certificate 106 chain, validating every encountered certificate and its products. 107 The result of this process is a list of all encountered RPKI objects 108 with a validity status attached to each of them. These results may 109 later be used by a Relying Party in taking routing decisions, etc. 111 Traditionally RPKI data is made available to RPs through the 112 repositories [RFC6481] accessible over rsync protocol. Relying 113 parties are advised to keep a local copy of repository data, and 114 perform regular updates of this copy from the repository (Section 5 115 of[RFC6481]). The RPKI Repository Delta Protocol 116 [I-D.ietf-sidr-delta-protocol] introduces another method to fetch 117 repository data and keep the local copy up to date with the 118 repository. 120 This document describes how a Relying Party tool could discover RPKI 121 objects to download, build certificate path, and validate RPKI 122 objects, independently from what repository access protocol is used. 123 To achieve this, it puts downloaded RPKI objects in an object store, 124 where objects could be found by their URI, hash of their content, 125 value of the object's AKI field, or combination of these. It also 126 keeps track of download and validation time for every object, to 127 perform cleanups of the local copy. 129 2. Top-down Validation of a Single Trust Anchor Certificate Tree 131 The validation of a Trust Anchor (TA) certificate tree starts from 132 its TA certificate. To retrieve the TA certificate, a Trust Anchor 133 Locator (TAL) object is used, as described in Section 2.1. 135 If the TA certificate is retrieved, it is validated according to the 136 Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. 138 Then the TA certificate and all its subordinate objects are validated 139 as described in Section 2.2. 141 For all repository objects that were validated during this validation 142 run, their validation timestamp is updated in an object store (see 143 Section 4.1.8). 145 Outdated objects are removed from the store as described in 146 Section 2.3. This completes the validation of the TA certificate 147 tree. 149 2.1. Fetching the Trust Anchor Certificate Using the Trust Anchor 150 Locator 152 The following steps are performed in order to fetch the Trust Anchor 153 Certificate: 155 o (Optional) If the Trust Anchor Locator contains a "prefetch.uris" 156 field, pass the URIs contained there to the fetcher (see 157 Section 3.1.1). (This field is a non-standard extension to the 158 TAL format supported by the RIPE NCC Validator. It helps fetching 159 non-hierarchical rsync repositories more efficiently.) 161 o Extract the TA certificate URI from the TAL's URI section (see 162 Section 2.1 of[RFC7730]) and pass to the object fetcher 163 (Section 3.1.2). 165 o Retrieve from the object store (see Section 4.1.4) all certificate 166 objects, for which the URI matches the URI extracted from the TAL 167 in the previous step, and the public key matches the 168 subjectPublicKeyInfo field of the TAL (see Section 2.1 of 169 [RFC7730]). 171 o If no, or more than one such objects are found, issue an error and 172 stop validation process. Otherwise, use that object as the Trust 173 Anchor certificate. 175 2.2. Resource Certificate Validation 177 The following steps describe the validation of a single resource 178 certificate: 180 o If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 181 id-ad-rpkiNotify (Section 3.5 of [I-D.ietf-sidr-delta-protocol]) 182 SIA pointers are present in the given resource certificate, use a 183 local policy to determine which pointer to use. Extract the URI 184 from the selected pointer and pass it to the object fetcher (see 185 Section 3.1.1). 187 o For a given resource certificate, find its manifest and 188 certificate revocation list (CRL), using the procedure described 189 in Section 2.2.1. If no such manifest and CRL could be found, 190 issue an error and stop processing current certificate. 192 o Compare the URI found in the given resource certificate's id-ad- 193 rpkiManifest field (Section 4.8.8.1 of [RFC6487]) with the URI of 194 the manifest found in the previous step. If they are different, 195 issue a warning. 197 o Perform manifest entries validation as described in Section 2.2.2. 199 o Validate all resource certificate objects found on the manifest, 200 using the CRL object found on the manifest, according to Section 7 201 of [RFC6487]. 203 o Validate all ROA objects found on the manifest, using the CRL 204 object found on the manifest, according to the Section 4 of 205 [RFC6482]. 207 o Validate all Ghostbusters Record objects found on the manifest, 208 using the CRL object found on the manifest, according to the 209 Section 7 of [RFC6493]. 211 o For every valid resource certificate object found on the manifest, 212 apply the procedure described in this section (Section 2.2), 213 recursively, provided that this resource certificate (identified 214 by its SKI) has not yet been validated during current repository 215 validation run. 217 2.2.1. Finding most recent valid manifest and CRL 219 Fetch from the store (see Section 4.1.5) all objects of type 220 manifest, whose certificate's AKI field matches the SKI of the 221 current CA certificate. 223 Find the manifest object with the highest manifestNumber field 224 (Section 4.2.1 of [RFC6486]), for which all following conditions are 225 met: 227 o There is only one entry in the manifest for which the store 228 contains exactly one object of type CRL, whose hash matches the 229 hash of the entry. 231 o The manifest's certificate AKI equals the above CRL's AKI 233 o The above CRL is a valid object according to Section 6.3 of 234 [RFC5280] 236 o The manifest is a valid object according to Section 4.4 of 237 [RFC6486], using the CRL found above 239 Report an error for every invalid manifest with the number higher 240 than the number of the valid manifest. 242 2.2.2. Manifest entries validation 244 For every entry in the manifest object: 246 o Construct an entry's URI by appending the entry name to the 247 current CA's publication point URI. 249 o Get all objects from the store whose hash attribute equals entry's 250 hash (see Section 4.1.3). 252 o If no such objects found, issue an error. 254 o For every found object, compare its URI with the URI of the 255 manifest entry. If they do not match, issue a warning. 257 o If no objects with matching URI found, issue a warning. 259 o If some objects with non-matching URI found, issue a warning. 261 2.3. Object Store Cleanup 263 At the end of the TA tree validation the store cleanup is performed: 265 o Given all objects that were validated during the current 266 validation run, remove from the store (Section 4.1.7) all objects 267 whose URI attribute matches the URI of one of the validated 268 objects, but the content's hash is different. 270 o Remove from the store all objects that were last validated more 271 than 7 days ago. 273 o Remove from the store all objects that were downloaded more than 2 274 hours ago and have never been used in a validation process. 276 The time intervals used in the steps above are a matter of local 277 policy. 279 3. Remote Objects Fetcher 281 The fetcher is responsible for downloading objects from remote 282 repositories (described in Section 3 of [RFC6481]) using rsync 283 protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) 284 ([I-D.ietf-sidr-delta-protocol]). 286 3.1. Fetcher Operations 288 3.1.1. Fetch repository objects 290 This operation receives one parameter - a URI. For rsync protocol 291 this URI points to a directory in a remote repository. For RRDP 292 repository it points to the repository's notification file. 294 The fetcher performs following steps: 296 o If the given URI has been downloaded recently (as specified by the 297 local policy), skip all following steps. 299 o Download the remote objects using the URI provided (for an rsync 300 repository use a recursive mode). 302 o For every new object that is downloaded, try to parse it as an 303 object of specific RPKI type (certificate, manifest, CRL, ROA, 304 Ghostbusters record), based on the object's filename extension 305 (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform 306 basic RPKI object validation, as specified in [RFC6487] and 307 [RFC6488]. 309 o For every downloaded valid object, record it in the object store 310 (Section 4.1.1), and set its last fetch time to the time it was 311 downloaded (Section 4.1.2). 313 3.1.2. Fetch single repository object 315 This operation receives one parameter - a URI that points to an 316 object in a remote repository. 318 The fetcher performs following operations: 320 o If the given URI has been downloaded recently (as specified by the 321 local policy), skip all following steps. 323 o Download the remote object using the URI provided. 325 o Try to parse the downloaded object as an object of a specific RPKI 326 type (certificate, manifest, CRL, ROA, Ghostbusters record), based 327 on the object's filename extension (.cer, .mft, .crl, .roa, and 328 .gbr, respectively), and perform basic RPKI object validation, as 329 specified in [RFC6487] and [RFC6488]. 331 o If the downloaded object is not valid, issue an error and skip 332 further steps. 334 o Delete objects from the object store (Section 4.1.6) whose URI 335 matches the URI given. 337 o Put validated object in the object store (Section 4.1.1), and set 338 its last fetch time to the time it was downloaded (Section 4.1.2). 340 4. Local Object Store 342 4.1. Store Operations 344 4.1.1. Store Repository Object 346 Put given object in the store, along with its type, URI, hash, and 347 AKI, if there is no record with the same hash and URI fields. 349 4.1.2. Update object's last fetch time 351 For all objects in the store whose URI matches the given URI, set the 352 last fetch time attribute to the given timestamp. 354 4.1.3. Get objects by hash 356 Retrieve all objects from the store whose hash attribute matches the 357 given hash. 359 4.1.4. Get certificate objects by URI 361 Retrieve from the store all objects of type certificate, whose URI 362 attribute matches the given URI. 364 4.1.5. Get manifest objects by AKI 366 Retrieve from the store all objects of type manifest, whose AKI 367 attribute matches the given AKI. 369 4.1.6. Delete objects for URI 371 For a given URI, delete all objects in the store with matching URI 372 attribute. 374 4.1.7. Delete outdated objects 376 For a given URI and a list of hashes, delete all objects in the store 377 with matching URI, whose hash attribute is not in the given list of 378 hashes. 380 4.1.8. Update object's validation time 382 For all objects in the store whose hash attribute matches the given 383 hash, set the last validation time attribute to the given timestamp. 385 5. Acknowledgements 387 This document describes the algorithm as it is implemented by the 388 software development team at the RIPE NCC. The original idea behind 389 it was outlined by Tim Bruijnzeels. The authors would also like to 390 acknowledge contributions by Carlos Martinez, Andy Newton, and Rob 391 Austein. 393 6. IANA Considerations 395 This document has no actions for IANA. 397 7. Security Considerations 399 This algorithm uses the content of a manifest object to discover 400 other objects issued by a particular CA. It verifies that the 401 manifest is located in the publication point designated in the CA 402 Certificate. However, if there are other (not enlisted in the 403 manifest) objects located in that publication point directory, they 404 will be ignored, even if their content is correct and they are issued 405 by the same CA as the manifest. 407 In contrast, objects whose content hash matches the hash listed in 408 the manifest, but that are not located in the publication directory 409 listed in their CA certificate, will be used in the validation 410 process (although a warning will be issued in that case). 412 The store cleanup procedure described in Section 2.3 tries to 413 minimise removal and subsequent re-fetch of objects that are 414 published in some repository but not used in the validation. Once 415 such objects are removed from the remote repository, they will be 416 discarded from the local object store after a period of time 417 specified by a local policy. By generating an excessive amount of 418 syntactically valid RPKI objects, a man-in-the-middle attack rendered 419 between a validating tool and a repository could force an 420 implementation to fetch and store those objects in the object store 421 before they are being validated and discarded, leading to an out-of- 422 memory or out-of-disk-space conditions, and, subsequently, a denial 423 of service. 425 8. References 427 8.1. Normative References 429 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 430 Housley, R., and W. Polk, "Internet X.509 Public Key 431 Infrastructure Certificate and Certificate Revocation List 432 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 433 . 435 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 436 Resource Certificate Repository Structure", RFC 6481, 437 DOI 10.17487/RFC6481, February 2012, 438 . 440 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 441 Origin Authorizations (ROAs)", RFC 6482, 442 DOI 10.17487/RFC6482, February 2012, 443 . 445 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 446 "Manifests for the Resource Public Key Infrastructure 447 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 448 . 450 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 451 X.509 PKIX Resource Certificates", RFC 6487, 452 DOI 10.17487/RFC6487, February 2012, 453 . 455 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 456 Template for the Resource Public Key Infrastructure 457 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 458 . 460 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 461 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 462 February 2012, . 464 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 465 "Resource Public Key Infrastructure (RPKI) Trust Anchor 466 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 467 . 469 8.2. Informative References 471 [I-D.ietf-sidr-delta-protocol] 472 Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R., 473 and D. Mandelberg, "RPKI Repository Delta Protocol", 474 draft-ietf-sidr-delta-protocol-02 (work in progress), 475 March 2016. 477 [rsync] "Rsync home page", . 479 Authors' Addresses 481 Oleg Muravskiy 482 RIPE NCC 484 Email: oleg@ripe.net 486 Tim Bruijnzeels 487 RIPE NCC 489 Email: tim@ripe.net