idnits 2.17.1 draft-huston-rpki-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 381: '...ns all fields that MUST be present, as...' RFC 2119 keyword, line 387: '... MUST NOT be present is used ...' RFC 2119 keyword, line 407: '...dation algorithm MAY perform these tes...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2014) is 3729 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Informational APNIC 5 Expires: August 13, 2014 February 9, 2014 7 RPKI Validation Reconsidered 8 draft-huston-rpki-validation-01.txt 10 Abstract 12 This document reviews the certificate validation procedure specified 13 in RFC6487 and highlights aspects of operational management of 14 certificates in the RPKI in response to the movement of resources 15 across registries, and the associated actions of Certification 16 Authorities to maintain certification of resources during this 17 movement. The document describes an alternative validation procedure 18 that reduces the operational impact of certificate management during 19 resource movement. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 13, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Operational Considerations . . . . . . . . . . . . . . . . . . 4 54 3. A Specific Resource RPKI Certificate Validation Process . . . 6 55 3.1. Resource Transfers and Specific Resource Certificate 56 Validation . . . . . . . . . . . . . . . . . . . . . . . . 8 57 3.2. A Specification of Specific Resource Validation . . . . . 8 58 4. Local Repository Cache Maintenance . . . . . . . . . . . . . . 10 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 This document reviews the certificate validation procedure specified 70 in [RFC6487] and highlights aspects of operational management of 71 certificates in the RPKI in response to the movement of resources 72 across registries, and the associated actions of Certification 73 Authorities to maintain certification of resources during this 74 movement. The document describes an alternative validation procedure 75 that reduces the operational impact of certificate management during 76 resource movement. The alternative validation procedure also offers 77 a higher level of robustness in the face of resource inconsistencies 78 in a putative certificate validation path. 80 As currently defined in section 7.2 of [RFC6487], validation of PKIX 81 certificates that conform to the RPKI profile relies on the use of a 82 path validation process where each certificate in the validation path 83 is required to meet the certificate validation criteria. This can be 84 considered to be a recursive validation process where, in the context 85 of an ordered sequence of certificates, as defined by common Issuer 86 and Subject Name pairs, a certificate is defined as valid if it 87 satisfies basic validation criteria relating to the syntactic 88 correctness, currency of validity dates and similar properties of the 89 certificate itself, as described in [RFC5280], and also that it 90 satisfies certain additional criteria with respect to the previous 91 certificate in the sequence, and that this previous certificate is 92 itself a valid certificate using the same criteria. This definition 93 applies recursively to all certificates in the sequence apart from 94 the initial sequence element, which is required to be a Trust Anchor. 96 For RPKI certificates, the additional criteria relating to the 97 previous certificate in this sequence is that the certificate's 98 number resource set, as defined in [RFC3779], is "encompassed" by the 99 number resource set contained in the previous certificate. 101 Because [RFC6487] validation demands that all resources in a 102 certificate be valid under the parent (and recursively, to the root), 103 a digitally signed attestation, such as a Route Origin Authorization 104 (ROA) object [RFC6482], which refers only to a subset of RFC3779- 105 specified resources from that certificate chain can be concluded to 106 be invalid, but not by virtue of the relationship between the RFC3779 107 extensions of the certificates on the putative certificate validation 108 path and the resources in the ROA, but by other resources described 109 in these certificates where the "encompassing" relationship of the 110 resources does not hold. Any such invalidity along the certificate 111 validation path can cause this outcome, not just at the immediate 112 parent of the end entity certificate that attests to the key used to 113 sign the ROA. 115 For example, in the certificate sequence: 117 Certificate 1: 118 Issuer A, Subject B, Resources 192.0.2.0/24, AS64496-AS64500 120 Certificate 2: 121 Issuer B, Subject C, Resources 192.0.2.0/24/24, AS64496-AS64511 123 Certificate 3: 124 Issuer C, Subject D, Resources 192.0.2.0/24 126 Certificate 3 is considered to be an invalid certificate, because the 127 resources in Certificate 2 are not encompassed by the resources in 128 Certificate 1, by virtue of certificate 2 holding the resources of 129 the range AS64501 - AS64511 in this RFC3779 resource extension. 130 Obviously, these Autonomous Systems numbers are not related to the 131 IPv4 resources contained in Certificate 3. 133 2. Operational Considerations 135 There are two areas of operational concern with the current RPKI 136 validation definition. 138 The first is that of the robustness of the operatinal management 139 procesures in the issuance of certificates. If a subordinate CA 140 issues a certificate that contains an Internet Number Resource (INR) 141 collection that is not either exactly equal to, or a strict subset 142 of, its parent CA, then this issued certificate, and all subordinate 143 certificates of this issued certificate are invalid. These 144 certificates are not only defined as invalid when being considered to 145 validate an INR that is not in the parent CA certificate, but are 146 defined as invalid for all INRs in the certificate. This creates a 147 degree of operational fragility in the issuance of certificates, as 148 all CA's are now required to exercise extreme care in the issuance 149 and reissuance of certificates that they do not overclaim on the 150 resources described in the parent CA, as the consequences of an 151 operational lapse or oversight implies that all the subordinate 152 certificates from the point of mismatch are invalid. It would be 153 preferred if the consequences of such an operational lapse were 154 limited in scope to the specific INRs that formed the mismatch, 155 rather than including the sntire set of INRs within the scope of 156 damage from this oversight. 158 The second operational consideration described here relates to the 159 situation where a registry withdraws a resource from the current 160 holder, and the resource to transferred to another registry, to be 161 registered to a new holder in that registry. The reason why this is 162 a consideration in operational deployments of the RPKI lies in the 163 movement of the "home" registry of number resources during cases of 164 mergers, acquisitions, business re-alignments, and resource transfers 165 and the desire to ensure that during this movement all other 166 resources can continue to be validated. 168 If the original registry's certification actions are simply to issue 169 a new certificate for the current holder with a reduced resource set, 170 and to revoke the original certificate, then there is a distinct 171 possibility of encountering the situation illustrated by the example 172 in the previous section. This is a result of an operational process 173 for certificate issuance by the parent CA being de-coupled from the 174 certificate operations of child CA. 176 This de-coupled operation of CAs introduces a risk of unintended 177 third party damage: since a CA certificate can refer to holdings 178 which relate to two or more unrelated subordinate certificates, if 179 this CA certificate becomes invalid due to the reduction in the 180 resources allocated to this CA relating to one subordinate resource 181 set, all other subordinate certificates are invalid until the CA 182 certificate is reissued with a reduced resource set. 184 In the above example, all subordinate certificates issued by CA C are 185 invalid until CA B issues a new certificate for CA C with a reduced 186 resource set. 188 At the lover levels of the RPKI hierarchy the resource sets affected 189 by such movements of resources may not encompass significantly large 190 pools of resources. However, as one ascends through this hierarchy 191 towards the apex, the larger the resource set that is going to be 192 affected by a period of invalidity by virtue of such uncoordinated 193 certificate management actions. In the case of a Regional Internet 194 Registry (RIR) or National Internet Registry (NIR), the potential 195 risk arising from uncoordinated certification actions relating to a 196 transfer of resources is that the entire set of subordinate 197 certificates that refer to resources administered by the RIR or the 198 NIR cannot be validated during this period. 200 Avoiding such situations requires that CA's adhere to a very specific 201 ordering of certificate issuance. In this framework, the common 202 registry CA that describes (directly or indirectly) the resources 203 being shifted from one registry to the other, and also contains in 204 subordinate certificates (direct or indirect) the certificates for 205 both registries who are parties to the resource transfer has to 206 coordinate a specific sequence of actions. 208 This common registry CA has to first issue a new certificate towards 209 the "receiving" registry that adds to the RFC3779 extension resource 210 set the specific resource being transferred into this receiving 211 registry. The common registry CA then has to wait until all 212 registries in the subordinate certificate chain to the receiving 213 registry have also performed a similar issuance of new certificates, 214 and in each case a registry must await the issuance of the immediate 215 superior certificate with the augmented resource set before it, in 216 turn, can issue its own augmented certificate to its subordinate CA. 217 This is a "top down" issuance sequence." 219 It is possible for the common registry to issue a certificate to the 220 "sending" registry with the reduced resource set at any time, but it 221 should not revoke the previously issued certificate, nor overwrite 222 this previously issued certificate in its repository publication 223 point without specific coordination. Only when the common registry 224 is assured that the top down certificate issuance process to the 225 receiving registry CA chain has been completed can the common 226 registry commence the revocation of the original certificate for the 227 sending registry, However, it should not so until it is assured that 228 the immediate subordinate registry CA in the path to the sending 229 registry has issued a certificate with a reduced resource set, and so 230 on. This implies that on the sending side the certificate issuance 231 and revocation is a "bottom up" process. 233 If this process is not carefully followed, then the risk is that some 234 or all or the subordinate certificates of this common registry CA 235 will be unable to be validated until the entire process of 236 certificate issuance and revocation has been completed. While this 237 sequenced process is intended to preserve validity of certificates in 238 the RPKI, it is a complex and operationally cumbersome process. 240 The underlying consideration here is that the operational 241 coordination of these certificate issuance and revocation actions to 242 effect a smooth resource transfer across registries is mandated by 243 the nature of the certificate validation process described in 244 [RFC6487]. 246 3. A Specific Resource RPKI Certificate Validation Process 248 The question considered here is: Is there an alternate definition of 249 RPKI certificate validity that could remove the requirement for such 250 careful orchestration of certification actions across the RPKI to 251 support resource transfers? 253 The general definition of certificate validity as defined in 254 [RFC5280] assumes a validation question relating to the relying 255 party's (RP's) level of trust in a subject's signed material, given 256 knowledge of a subject's name, the subject's public key, the RP's 257 chosen trust anchor(s) and an overall PKI to define the domain of 258 discourse. 260 The validation question assumed by the [RFC6487] RPKI certificate 261 validation process relates to a RP's level of trust in the 262 combination of some signed material, a certificate that attests to 263 the public key used to sign this material and the set of all number 264 resources that have been assigned or allocated to the subject of the 265 certificate, given knowledge of the certificate, the RP's chosen 266 trust anchor(s), the RPKI, and the application of the same test 267 applied to the superior certificate in the RPKI hierarchy, and so on 268 to a Trust Anchor. 270 There is a alternative certificate validation procedure that starts 271 with an attestation containing the subject's signed material and an 272 explicit enumeration of a set of number resources. The associated 273 validation question relates to whether a RPKI validation process can 274 attest to the validity of a subject's signed attestation relating to 275 a particular set of number resources, rather than a signed 276 attestation relating to all number resources held by this subject. 277 We will term this alternate certificate validation process "specific 278 resource" validation. 280 If the certificate validation procedure is specifically restricted to 281 a question of ascertaining the validity of a particular set of number 282 resources in the context of the RPKI, the RPKI validation procedure 283 need not be as strict as a recursive "encompassing" condition for the 284 resources contained in each pair of certificates in the validation 285 path. It would be sufficient in the context of this "specific 286 resource" validation procedure to require only that each certificate 287 in the validation path has a number resource extension that 288 "encompasses" the specific resources described in the original 289 validation question. Rather than a validation test for all possible 290 questions, this is a specific validation question in the context of 291 specific resources. 293 This validation question can be informally described as: Given a 294 certificate and a given resource set, is there an Issuer-Subject 295 ordered sequence of certificates from a Trust Anchor to the 296 certificate being validated, where each certificate on this sequence 297 is well-formed, not revoked by a valid CRL, where the certificate's 298 lifetimes are valid, and where the RFC3779 resource extension in the 299 certificate encompass the given resource set? 301 In the example from Section 1, using a this alternate certificate 302 validation process, a validation question of certificate 3 and the 303 resource 10.0.1.0/24, the validation outcome would be positive, in 304 that certificates 1, 2 and 3 all encompass the specific resource 305 10.0.1.0/24, assuming that the certificates are valid in all other 306 respects. 308 3.1. Resource Transfers and Specific Resource Certificate Validation 310 When considering the transfer of resources across registries, and the 311 associated certification actions, then if the validation process was 312 one of "specific resource" validation, then there is no requirement 313 for synchronized orchestration of the process of certificate issuance 314 and revocation by the CAs involved in this transfer in order to 315 preserve the validity of resources described in these certificates. 317 Along the chain of the "sending" registry CA hierarchy each registry 318 CA can issue a certificate with a reduced resource set that removes 319 the resource being transferred, and revoke the previously issued 320 certificate without regard to the specific timing of similar actions 321 by either it's superior or its subordinate registry CA. 323 Similarly, in the "receiving" registry hierarchy each CA can issue a 324 certificate with an augmented resource set that includes the resource 325 being transferred without particular regard to the timing of similar 326 actions by the other superior or subordinate registry CAs. 328 Validation questions relating to the migrating resource made against 329 certificates on the "sending registry" will return an invalid outcome 330 as soon as any registry CA in this chain has performed revocation of 331 the original certificate. Validation questions relating to the 332 migrating resource made against certificates on the "receiving 333 registry" will return an valid outcome only when all the registries 334 in this chain have performed certificate re-issuance and included the 335 resource in the new certificate. 337 Critically, at all times validation questions relating to any other 338 resource using the "specific resource" validation approach will 339 return the same outcomes throughout this issuance and revocation 340 process. This "specific resource" validation process engenders a 341 more robust outcome in RPKI certificate management. Validation 342 questions relating to resources which are not being transferred from 343 one registry to another cannot be compromised by any failure to 344 adhere to a strict process of issuance and revocation relating to the 345 certification of the resources being transferred. 347 3.2. A Specification of Specific Resource Validation 349 The following is a amended specification of certificate validation as 350 described in [RFC6487] that describes the proposed "specific 351 resource" certificate validation process. 353 Validation of signed resource data using a target resource 354 certificate and a specific set of number resources consists of 355 verifying that the digital signature of the signed resource data is 356 valid, using the public key of the target resource certificate, and 357 also validating the resource certificate in the context of the RPKI, 358 using the path validation process. This path validation process 359 verifies, among other things, that a prospective certification path 360 (a sequence of n certificates) satisfies the following conditions: 362 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' 363 is the Issuer of certificate ('x' + 1); 365 2. certificate '1' is issued by a trust anchor; 367 3. certificate 'n' is the certificate to be validated; and 369 4. for all 'x' in {1, ..., n}, certificate 'x' is valid. 371 Certificate validation entails verifying that all of the following 372 conditions hold, in addition to the Certification Path Validation 373 criteria specified in Section 6 of [RFC5280]: 375 1. The certificate can be verified using the Issuer's public key 376 and the signature algorithm 378 2. The current time lies within the certificate's Validity From 379 and To values. 381 3. The certificate contains all fields that MUST be present, as 382 defined by this specification, and contains values for 383 selected fields that are defined as allowable values by this 384 specification. 386 4. No field, or field value, that this specification defines as 387 MUST NOT be present is used in the certificate. 389 5. The Issuer has not revoked the certificate. A revoked 390 certificate is identified by the certificate's serial number 391 being listed on the Issuer's current CRL, as identified by the 392 CRLDP of the certificate, the CRL is itself valid, and the 393 public key used to verify the signature on the CRL is the same 394 public key used to verify the certificate itself. 396 6. The resource extension data contained in this certificate 397 "encompasses" the entirety of the resources in the specific 398 resource set. 400 7. The Certification Path originates with a certificate issued by 401 a trust anchor, and there exists a signing chain across the 402 Certification Path where the Subject of Certificate 'x' in the 403 Certification Path matches the Issuer in Certificate 'x + 1' 404 in the Certification Path, and the public key in Certificate 405 'x' can verify the signature value in Certificate 'x+1'. 407 A certificate validation algorithm MAY perform these tests in any 408 chosen order. 410 4. Local Repository Cache Maintenance 412 This change in the validation process would have some impact on the 413 operation of a local cache of validated RPKI certificates. Given 414 that the validation process requires the specification of a specific 415 resource set, it would appear that it would not be possible to 416 validate an RPKI certificate without also specifying a specific 417 resource set. 419 However, using a top-down validation process, and an additional local 420 data structure associated with each locally held validated RPKI 421 certificate, it is possible to maintain a local cache of validated 422 certificates, and the set of valid and invalid resources for each 423 certificate. 425 The additional data structures are the certificate's validated and 426 invalidated resource set. These sets are defined as follows: 428 o If the certificate is used as a Trust Anchor, then the local 429 validated resource set is copied from the certificate's RFC3779 430 resource set. There is no invalid resource set. 432 o Otherwise, the certificate's local validated resource set is 433 defined as the intersection of this certificate's RFC3779 resource 434 set and the parent certificate's local validated resource set. 435 The certificate's invalid resource set is the difference between 436 this set and the certificate's RFC3779 resource set. 438 If the certificate's validated resource set is empty then the 439 certificate is not valid. 441 If the invalid resource set is not empty, then any resources that are 442 contained in this invalid resource set cannot be valid by virtue of 443 this certificate. 445 In all operations on the local repository cache, local applications 446 should use the certificate's local validated resource set in place of 447 the resources described in the certificate's RFC3779 extension. 449 The invalid resource set can be used as a diagnostic aide in local 450 cache management. 452 5. Security Considerations 454 The Security Considerations of [RFC6487] apply to the validation 455 procedure described here. 457 6. IANA Considerations 459 No updates to the registries are suggested by this document. 461 7. Acknowledgements 463 TBA. 465 8. References 467 8.1. Normative References 469 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 470 Addresses and AS Identifiers", RFC 3779, June 2004. 472 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 473 Housley, R., and W. Polk, "Internet X.509 Public Key 474 Infrastructure Certificate and Certificate Revocation List 475 (CRL) Profile", RFC 5280, May 2008. 477 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 478 X.509 PKIX Resource Certificates", RFC 6487, 479 February 2012. 481 8.2. Informative References 483 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 484 Origin Authorizations (ROAs)", RFC 6482, February 2012. 486 Authors' Addresses 488 Geoff Huston 489 Asia Pacific Network Information Centre (APNIC) 490 6 Cordelia St 491 South Brisbane, QLD 4101 492 Australia 494 Phone: +61 7 3858 3100 495 Email: gih@apnic.net 497 George Michaelson 498 Asia Pacific Network Information Centre (APNIC) 499 6 Cordelia St 500 South Brisbane, QLD 4101 501 Australia 503 Phone: +61 7 3858 3100 504 Email: ggm@apnic.net