idnits 2.17.1 draft-tbruijnzeels-sidr-validation-local-cache-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6481], [I-D.tbruijnzeels-sidr-delta-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3112 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 6490 (Obsoleted by RFC 7730) 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 T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Informational RIPE NCC 5 Expires: April 21, 2016 October 19, 2015 7 RPKI Repository Validation Using Local Cache 8 draft-tbruijnzeels-sidr-validation-local-cache-02 10 Abstract 12 This document describes the approach to validate the content of the 13 RPKI repository, which is independent of a particular object 14 retrieval mechanism. This allows it to be used with repositories 15 available over rsync protocol (see Section 3 of[RFC6481]), and delta 16 protocol ( [I-D.tbruijnzeels-sidr-delta-protocol]), as well as 17 repositories that use a mix of both. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Top-down Validation of a Single Repository . . . . . . . . . 2 55 2.1. Fetching Trust Anchor Certificate Using Trust Anchor 56 Locator . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Resource Certificate Validation . . . . . . . . . . . . . 3 58 2.2.1. Finding most recent valid manifest and CRL . . . . . 4 59 2.2.2. Manifest entries validation . . . . . . . . . . . . . 5 60 2.3. Store Cleanup . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 5 62 3.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. Fetch repository objects . . . . . . . . . . . . . . 5 64 3.1.2. Fetch single repository object . . . . . . . . . . . 6 65 4. Local Object Store . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Store Operations . . . . . . . . . . . . . . . . . . . . 7 67 4.1.1. Store Repository Object . . . . . . . . . . . . . . . 7 68 4.1.2. Update object's last fetch time . . . . . . . . . . . 7 69 4.1.3. Get objects by hash . . . . . . . . . . . . . . . . . 7 70 4.1.4. Get certificate objects by URI . . . . . . . . . . . 7 71 4.1.5. Get manifest objects by AKI . . . . . . . . . . . . . 7 72 4.1.6. Delete objects for URI . . . . . . . . . . . . . . . 7 73 4.1.7. Delete outdated objects . . . . . . . . . . . . . . . 7 74 4.1.8. Update object's validation time . . . . . . . . . . . 7 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Top-down Validation of a Single Repository 91 The validation of one repository is independent from any other 92 repository, and thus, multiple repositories could be validated 93 concurrently. 95 The validation of a repository starts from it's Trust Anchor (TA) 96 certificate. To retrieve the TA, the Trust Anchor Locator (TAL) 97 object is used, as described in Section 2.1. 99 If the TA certificate is retrieved, it is validated according to the 100 Section 2.2 of [RFC6490]. 102 Then the TA certificate is validated as a resource certificate, as 103 described in Section 2.2. 105 For all repository objects that were validated during this validation 106 run, their validation timestamp is updated in the local store (see 107 Section 4.1.8). 109 Outdated objects are removed from the store as described in 110 Section 2.3. This completes the validation of a repository. 112 2.1. Fetching Trust Anchor Certificate Using Trust Anchor Locator 114 The following steps are performed in order to fetch the Trust Anchor 115 Certificate: 117 o If the Trust Anchor Locator contains "prefetch.uris" field, pass 118 the URIs contained there to the fetcher (see Section 3.1.1). 120 o Pass to the fetcher (Section 3.1.2) the URI from the TAL (see 121 Section 2.1 of [RFC6490]). 123 o Retrieve from the local store (see Section 4.1.4) all certificate 124 objects, for which the URI matches the URI extracted from the TAL 125 in the previous step, and the public key matches the 126 subjectPublicKeyInfo field of the TAL (Section 2.1 of [RFC6490]). 128 o If no, or more than one such objects are found, issue an error and 129 stop validation process. Otherwise, use that object as a Trust 130 Anchor certificate. 132 2.2. Resource Certificate Validation 134 The following steps describe the validation of a single resource 135 certificate: 137 o If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 138 id-ad-rpkiNotify (Section 3.5 of 139 [I-D.tbruijnzeels-sidr-delta-protocol]) SIA pointers are present 140 in the given resource certificate, use a local policy to determine 141 which pointer to use. Extract the URI from the selected pointer 142 and pass it to the fetcher (see Section 3.1.1). 144 o For a given resource certificate, find it's manifest and 145 certificate revocation list (CRL), using the procedure described 146 in Section 2.2.1. If no such manifest and CRL could be found, 147 issue an error and stop processing current certificate. 149 o Compare given resource certificate's manifest URI with the URI of 150 the manifest found in the previous step. If they are different, 151 issue a warning. 153 o Get from the local store and validate repository objects that 154 correspond to the manifest entries, using the procedure described 155 in the Section 2.2.2. 157 o Validate all resource certificate objects found on the manifest, 158 using the CRL object found on the manifest, according to Section 7 159 of [RFC6487]. 161 o Validate all ROA objects found on the manifest, using the CRL 162 object found on the manifest, according to the Section 4 of 163 [RFC6482]. 165 o Validate all Ghostbusters Record objects found on the manifest, 166 using the CRL object found on the manifest, according to the 167 Section 7 of [RFC6493]. 169 o For every valid resource certificate object found on the manifest, 170 apply the procedure described in this section (Section 2.2), 171 recursively, provided that this resource certificate (identified 172 by it's SKI) has not yet been validated during current repository 173 validation run. 175 2.2.1. Finding most recent valid manifest and CRL 177 Fetch from the store (see Section 4.1.5) all objects of type 178 manifest, whose certificate's AKI field matches the SKI of the 179 current CA certificate. 181 Find the manifest object with the highest manifest number, for which 182 all following conditions are met: 184 o There is only one entry in the manifest for which the store 185 contains exactly one object of type CRL, whose hash matches the 186 hash of the entry. 188 o The manifest's certificate AKI equals the above CRL's AKI 190 o The above CRL is a valid object according to Section 6.3 of 191 [RFC5280] 193 o The manifest is a valid object according to Section 4.4 of 194 [RFC6486], using the CRL found above 196 Report an error for every invalid manifest with the number higher 197 than the number of the valid manifest. 199 2.2.2. Manifest entries validation 201 For every entry in the manifest object: 203 o Construct an entry's URI by appending the entry name to the 204 current CA's publication point URI. 206 o Get all objects from the store whose hash attribute equals entry's 207 hash (see Section 4.1.3). 209 o If no such objects found, issue an error. 211 o For every found object, compare it's URI with the URI of the 212 manifest entry. If they do not match, issue a warning. 214 o If no objects with matching URI found, issue a warning. 216 o If some objects with non-matching URI found, issue a warning. 218 2.3. Store Cleanup 220 At the end of repository validation, the store cleanup is performed. 221 Given all objects that were validated during current validation run, 222 it removes from the store (Section 4.1.7) all objects whose URI 223 attribute matches URI of validated object(s), but the hash attribute 224 is different. 226 3. Remote Objects Fetcher 228 The fetcher is responsible for downloading objects from remote 229 repositories. Currently rsync and RRDP repositories are supported. 231 3.1. Fetcher Operations 233 3.1.1. Fetch repository objects 235 This operation receives one parameter - a URI. For rsync protocol 236 this URI points to a directory in a remote rsync repository. For 237 RRDP repository it points to the repository's notification file. 239 The fetcher performs following steps: 241 o If the given URI has been downloaded recently (as specified by the 242 local policy), do nothing. 244 o Download remote objects using the URI provided (for rsync 245 repository use recursive mode). 247 o For every new object that is downloaded, try to parse it as an 248 object of specific RPKI type (certificate, manifest, CRL, ROA, 249 Ghostbusters record), based on the object's filename extension 250 (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform 251 basic RPKI object validation, as specified in [RFC6487] and 252 [RFC6488]. 254 o For every downloaded valid object, record it in the local store 255 (Section 4.1.1), and set it's last fetch time to the time it was 256 downloaded (Section 4.1.2). 258 3.1.2. Fetch single repository object 260 This operation receives one parameter - a URI that points to an 261 object in a remote repository. 263 The fetcher performs following operations: 265 o If the given URI has been downloaded recently (as specified by the 266 local policy), do nothing. 268 o Download the remote object using the URI provided. 270 o Try to parse downloaded object as an object of a specific RPKI 271 type (certificate, manifest, CRL, ROA, Ghostbusters record), based 272 on the object's filename extension (.cer, .mft, .crl, .roa, and 273 .gbr, respectively), and perform basic RPKI object validation, as 274 specified in [RFC6487] and [RFC6488]. 276 o If the downloaded object is not valid, issue an error and skip 277 further steps. 279 o Delete objects from the local store (Section 4.1.6) using given 280 URI. 282 o Put validated object in the local store (Section 4.1.1), and set 283 it's last fetch time to the time it was downloaded 284 (Section 4.1.2). 286 4. Local Object Store 288 4.1. Store Operations 290 4.1.1. Store Repository Object 292 Put given object in the store, along with it's type, URI, hash, and 293 AKI, if there is no record with the same hash and URI fields. 295 4.1.2. Update object's last fetch time 297 For all objects in the store whose URI matches the given URI, set the 298 last fetch time attribute to the given timestamp. 300 4.1.3. Get objects by hash 302 Retrieve all objects from the store whose hash attribute matches the 303 given hash. 305 4.1.4. Get certificate objects by URI 307 Retrieve from the store all objects of type certificate, whose URI 308 attribute matches the given URI. 310 4.1.5. Get manifest objects by AKI 312 Retrieve from the store all objects of type manifest, whose AKI 313 attribute matches the given AKI. 315 4.1.6. Delete objects for URI 317 For a given URI, delete all objects in the store with matching URI 318 attribute. 320 4.1.7. Delete outdated objects 322 For a given URI and a list of hashes, delete all objects in the store 323 with matching URI, whose hash attribute is not in the given list of 324 hashes. 326 4.1.8. Update object's validation time 328 For all objects in the store whose hash attribute matches the given 329 hash, set the last validation time attribute to the given timestamp. 331 5. Acknowledgements 333 6. IANA Considerations 335 7. Security Considerations 337 8. References 339 8.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 343 RFC2119, March 1997, 344 . 346 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 347 Housley, R., and W. Polk, "Internet X.509 Public Key 348 Infrastructure Certificate and Certificate Revocation List 349 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 350 . 352 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 353 Resource Certificate Repository Structure", RFC 6481, DOI 354 10.17487/RFC6481, February 2012, 355 . 357 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 358 Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/ 359 RFC6482, February 2012, 360 . 362 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 363 "Manifests for the Resource Public Key Infrastructure 364 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 365 . 367 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 368 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 369 RFC6487, February 2012, 370 . 372 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 373 Template for the Resource Public Key Infrastructure 374 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 375 . 377 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 378 "Resource Public Key Infrastructure (RPKI) Trust Anchor 379 Locator", RFC 6490, DOI 10.17487/RFC6490, February 2012, 380 . 382 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 383 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 384 February 2012, . 386 8.2. Informative References 388 [I-D.tbruijnzeels-sidr-delta-protocol] 389 Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R., 390 and D. Mandelberg, "RPKI Repository Delta Protocol", 391 draft-tbruijnzeels-sidr-delta-protocol-03 (work in 392 progress), December 2014. 394 Authors' Addresses 396 Tim Bruijnzeels 397 RIPE NCC 399 Email: tim@ripe.net 401 Oleg Muravskiy 402 RIPE NCC 404 Email: oleg@ripe.net