idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-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 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 341: '...ns all fields that MUST be present, as...' RFC 2119 keyword, line 347: '... defines as MUST NOT be present i...' RFC 2119 keyword, line 368: '...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 (October 9, 2015) is 3122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: April 11, 2016 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 A. Aina 12 AFRINIC 13 October 9, 2015 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-02.txt 18 Abstract 20 This document reviews the certificate validation procedure specified 21 in RFC6487 and highlights aspects of operational fragility in the 22 management of certificates in the RPKI. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 11, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Certificate Validation in the RPKI . . . . . . . . . . . . . . 3 60 3. Operational Considerations . . . . . . . . . . . . . . . . . . 4 61 4. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 7 62 5. An Amended RPKI Certification Validation Process . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 This document reviews the certificate validation procedure specified 74 in RFC6487 and highlights aspects of operational fragility in the 75 management of certificates. 77 2. Certificate Validation in the RPKI 79 As currently defined in section 7.2 of [RFC6487], validation of PKIX 80 certificates that conform to the RPKI profile relies on the use of a 81 path validation process where each certificate in the validation path 82 is required to meet the certificate validation criteria. This is a 83 recursively defined validation process where, in the context of an 84 ordered sequence of certificates, as defined by each pair of 85 certificates in this sequence having a common Issuer and Subject Name 86 respectively, a certificate is defined as valid if it satisfies basic 87 validation criteria relating to the syntactic correctness, currency 88 of validity dates and similar properties of the certificate itself, 89 as described in [RFC5280], and also that it satisfies certain 90 additional criteria with respect to the previous certificate in the 91 sequence (the Issuer part of the pair), and that this previous 92 certificate is itself a valid certificate using the same criteria. 93 This process is applied to all certificates in the sequence apart 94 from the initial sequence element, which is required to be a Trust 95 Anchor. 97 For RPKI certificates, the additional criteria relating to the 98 previous certificate in this sequence is that the certificate's 99 number resource set, as defined in [RFC3779], is "encompassed" by the 100 number resource set contained in the previous certificate. 102 Because [RFC6487] validation demands that all resources in a 103 certificate be valid under the parent (and recursively, to the root), 104 a digitally signed attestation, such as a Route Origin Authorization 105 (ROA) object [RFC6482], which refers only to a subset of RFC3779- 106 specified resources from that certificate validation chain can be 107 concluded to be invalid, but not by virtue of the relationship 108 between the RFC3779 extensions of the certificates on the putative 109 certificate validation path and the resources in the ROA, but by 110 other resources described in these certificates where the 111 "encompassing" relationship of the resources does not hold. Any such 112 invalidity along the certificate validation chain can cause this 113 outcome, not just at the immediate parent of the end entity 114 certificate that attests to the key used to sign the ROA. 116 For example, in the certificate sequence: 118 Certificate 1: 119 Issuer A, Subject B, Resources 192.0.2.0/24, AS64496-AS64500 121 Certificate 2: 122 Issuer B, Subject C, Resources 192.0.2.0/24/24, AS64496-AS64511 124 Certificate 3: 125 Issuer C, Subject D, Resources 192.0.2.0/24 127 Certificate 3 is considered to be an invalid certificate, because the 128 resources in Certificate 2 are not encompassed by the resources in 129 Certificate 1, by virtue of certificate 2 describing the resources of 130 the range AS64501 - AS64511 in this RFC3779 resource extension. 131 Obviously, these Autonomous Systems numbers are not related to the 132 IPv4 resources contained in Certificate 3. 134 Any non-encompassed resource set can cause this form or validation 135 failure, whether it is an ASN, IPv4 or IPv6 resource, if it is not 136 encompassed by the resource set in the parent (Issuer) certificate. 138 The underlying observation here is that this definition of 139 certificate validation treats a collection of resources as 140 inseparable, so that a single certificate containing a bundle of 141 number resources is semantically distinct from an equivalent set of 142 certificates where each certificate contains a single number 143 resource. This semantic distinction between the whole and the sum of 144 its parts is an artifice introduced by the particular choice of a 145 certificate validation procedure used by the RPKI, as distinct from 146 meeting any particular operational requirement, and the result is the 147 introduction of operational fragility into the handling of RPKI 148 certificates, particularly in the case where number resources are 149 moved between the corresponding registries, as described here. 151 3. Operational Considerations 153 There are two areas of operational concern with the current RPKI 154 validation definition. 156 The first is that of the robustness of the operational management 157 procedures in the issuance of certificates. If a subordinate 158 Certification Authority (CA) issues a certificate that contains an 159 Internet Number Resource (INR) collection that is not either exactly 160 equal to, or a strict subset of, its parent CA, then this issued 161 certificate, and all subordinate certificates of this issued 162 certificate are invalid. These certificates are not only defined as 163 invalid when being considered to validate an INR that is not in the 164 parent CA certificate, but are defined as invalid for all INRs in the 165 certificate. 167 This constraint creates a degree of operational fragility in the 168 issuance of certificates, as all CA's are now required to exercise 169 extreme care in the issuance and reissuance of certificates to ensure 170 that at no time do they overclaim on the resources described in the 171 parent CA, as the consequences of an operational lapse or oversight 172 implies that all the subordinate certificates from the point of INR 173 mismatch are invalid. It would be preferred if the consequences of 174 such an operational lapse were limited in scope to the specific INRs 175 that formed the mismatch, rather than including the entire set of 176 INRs within the scope of damage from this point of mismatch downward 177 across the entire sub-tree of descendant certificates in the RPKI 178 certificate hierarchy. 180 The second operational consideration described here relates to the 181 situation where a registry withdraws a resource from the current 182 holder, and the resource to transferred to another registry, to be 183 registered to a new holder in that registry. The reason why this is 184 a consideration in operational deployments of the RPKI lies in the 185 movement of the "home" registry of number resources during cases of 186 mergers, acquisitions, business re-alignments, and resource transfers 187 and the desire to ensure that during this movement all other 188 resources can continue to be validated. 190 If the original registry's certification actions are simply to issue 191 a new certificate for the current holder with a reduced resource set, 192 and to revoke the original certificate, then there is a distinct 193 possibility of encountering the situation illustrated by the example 194 in the previous section. This is a result of an operational process 195 for certificate issuance by the parent CA being de-coupled from the 196 certificate operations of child CA. 198 This de-coupled operation of CAs introduces a risk of unintended 199 third party damage: since a CA certificate can refer to holdings 200 which relate to two or more unrelated subordinate certificates, if 201 this CA certificate becomes invalid due to the reduction in the 202 resources allocated to this CA relating to one subordinate resource 203 set, all other subordinate certificates are invalid until the CA 204 certificate is reissued with a reduced resource set. 206 In the example provided in the previous section, all subordinate 207 certificates issued by CA B are invalid, including all certificates 208 issued by CA C, until CA A issues a new certificate for CA B with a 209 reduced resource set. 211 At the lower levels of the RPKI hierarchy the resource sets affected 212 by such movements of resources may not encompass significantly large 213 pools of resources. However, as one ascends through this 214 certification hierarchy towards the apex, the larger the resource set 215 that is going to be affected by a period of invalidity by virtue of 216 such uncoordinated certificate management actions. In the case of a 217 Regional Internet Registry (RIR) or National Internet Registry (NIR), 218 the potential risk arising from uncoordinated certification actions 219 relating to a transfer of resources is that the entire set of 220 subordinate certificates that refer to resources administered by the 221 RIR or the NIR cannot be validated during this period. 223 Avoiding such situations requires that CA's adhere to a very specific 224 ordering of certificate issuance. In this framework, the common 225 registry CA that describes (directly or indirectly) the resources 226 being shifted from one registry to the other, and also contains in 227 subordinate certificates (direct or indirect) the certificates for 228 both registries who are parties to the resource transfer has to 229 coordinate a specific sequence of actions. 231 This common registry CA has to first issue a new certificate towards 232 the "receiving" registry that adds to the RFC3779 extension resource 233 set the specific resource being transferred into this receiving 234 registry. The common registry CA then has to wait until all 235 registries in the subordinate certificate chain to the receiving 236 registry have also performed a similar issuance of new certificates, 237 and in each case a registry must await the issuance of the immediate 238 superior certificate with the augmented resource set before it, in 239 turn, can issue its own augmented certificate to its subordinate CA. 240 This is a "top down" issuance sequence." 242 It is possible for the common registry to issue a certificate to the 243 "sending" registry with the reduced resource set at any time, but it 244 should not revoke the previously issued certificate, nor overwrite 245 this previously issued certificate in its repository publication 246 point without specific coordination. Only when the common registry 247 is assured that the top down certificate issuance process to the 248 receiving registry CA chain has been completed can the common 249 registry commence the revocation of the original certificate for the 250 sending registry, However, it should not so until it is assured that 251 the immediate subordinate registry CA in the path to the sending 252 registry has issued a certificate with a reduced resource set, and so 253 on. This implies that on the sending side the certificate issuance 254 and revocation is a "bottom up" process. 256 If this process is not carefully followed, then the risk is that some 257 or all or the subordinate certificates of this common registry CA 258 will be unable to be validated until the entire process of 259 certificate issuance and revocation has been completed. While this 260 sequenced process is intended to preserve validity of certificates in 261 the RPKI, it is a complex, fragile and operationally cumbersome 262 process. 264 The underlying consideration here is that the operational 265 coordination of these certificate issuance and revocation actions to 266 effect a smooth resource transfer across registries is mandated by 267 the nature of the particular choice of certificate validation process 268 described in [RFC6487]. 270 4. Alternative Approaches 272 If the current definition of the RPKI certificate validation 273 procedure is considered to introduce unacceptable levels of fragility 274 and risk into the operational environment, what alternatives exist? 276 One approach is to remove the semantic requirement to consider the 277 collection of resources in the extension field of the RPKI 278 certificate as an indivisible bundle. This would allow for a 279 certificate to be considered as valid for some subset of the 280 resources listed in this extension, without necessarily being 281 considered as valid for all such described resources. The 282 implications of this approach is that any mismatch between parent and 283 subordinate over resources where the subordinate certificate lists 284 resources that are not contained in the parent certificate would 285 affect validity questions relating to only those particular 286 resources, rather than invaliding the subordinate certificate for all 287 resources, and all of its subordinate products. This would appear to 288 offer a relatively precise alignment to the defined problem space, 289 and limits the scope of consequent third party damage in the event of 290 a INR mismatch within the RPKI certification hierarchy. 292 Another approach may involve the alteration of the RPKI provisioning 293 protocol [RFC6492] to include a specific signal from child to parent 294 ("bottom up") relating to readiness for certificate revocation. At 295 this stage it is entirely unclear how this signalling mechanism would 296 operate, nor is it clear that it would alter the elements of 297 operational fragility nor mitigate to any meaningful extent the risks 298 of failure to ensure strict INR consistency at all times. This is a 299 topic for further study. 301 5. An Amended RPKI Certification Validation Process 303 The following is a amended specification of certificate validation as 304 described in [RFC6487] that describes an amended RPKI certificate 305 validation process that was informally outlined in the previous 306 section. 308 Validation of signed resource data using a signing key that is 309 certified in a resource certificate, coupled with a specific set of 310 number resources, consists of verifying that the digital signature of 311 the signed resource data is valid, using the public key that is 312 certified by the resource certificate, and also validating the 313 resource certificate in the context of the RPKI, using the path 314 validation process. 316 This path validation process verifies, among other things, that a 317 prospective certification path (a sequence of n certificates) 318 satisfies the following conditions: 320 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' 321 is the Issuer of certificate ('x' + 1); 323 2. certificate '1' is issued by a trust anchor; 325 3. certificate 'n' is the certificate to be validated; and 327 4. for all 'x' in {1, ..., n}, certificate 'x' is valid for the 328 specific set of resources. 330 RPKI validation for a specific set of resources entails verifying 331 that all of the following conditions hold, in addition to the 332 Certification Path Validation criteria specified in Section 6 of 333 [RFC5280]: 335 1. The certificate can be verified using the Issuer's public key 336 and the signature algorithm 338 2. The current time lies within the certificate's Validity From 339 and To values. 341 3. The certificate contains all fields that MUST be present, as 342 specified by [RFC6487], and contains values for selected 343 fields that are defined as allowable values by this 344 specification. 346 4. No field, or field value, that the [RFC6487] specification 347 defines as MUST NOT be present is used in the certificate. 349 5. The Issuer has not revoked the certificate. A revoked 350 certificate is identified by the certificate's serial number 351 being listed on the Issuer's current CRL, as identified by the 352 CRLDP of the certificate, the CRL is itself valid, and the 353 public key used to verify the signature on the CRL is the same 354 public key used to verify the certificate itself. 356 6. The resource extension data contained in this certificate 357 "encompasses" the entirety of the resources in the specific 358 resource set ("encompass" in this context is defined in 359 Section 7.1 of [RFC6487]). 361 7. The Certification Path originates with a certificate issued by 362 a trust anchor, and there exists a signing chain across the 363 Certification Path where the Subject of Certificate 'x' in the 364 Certification Path matches the Issuer in Certificate 'x + 1' 365 in the Certification Path, and the public key in Certificate 366 'x' can verify the signature value in Certificate 'x+1'. 368 A certificate validation algorithm MAY perform these tests in any 369 chosen order. 371 6. Security Considerations 373 The Security Considerations of [RFC6487] and [RFC6492] do not address 374 the topic described here. Obviously, within the current RPKI 375 validation procedure, any inconsistency in certificates located 376 towards the apex of the RPKI hierarchy would invalidate the entirety 377 of the sub-tree located below the point of this inconsistency. If 378 the RPKI was used to control inter-domain routing in the context of a 379 secure routing protocol, then the implications of this large scale 380 invalidation of certificates would have a corresponding massive 381 impact on the stability of routing. This appears to be a serious 382 situation. 384 7. IANA Considerations 386 No updates to the registries are suggested by this document. 388 8. Acknowledgements 390 TBA. 392 9. References 394 9.1. Normative References 396 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 397 Addresses and AS Identifiers", RFC 3779, DOI 10.17487/ 398 RFC3779, June 2004, 399 . 401 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 402 Housley, R., and W. Polk, "Internet X.509 Public Key 403 Infrastructure Certificate and Certificate Revocation List 404 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 405 . 407 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 408 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 409 RFC6487, February 2012, 410 . 412 9.2. Informative References 414 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 415 Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/ 416 RFC6482, February 2012, 417 . 419 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 420 Protocol for Provisioning Resource Certificates", 421 RFC 6492, DOI 10.17487/RFC6492, February 2012, 422 . 424 Authors' Addresses 426 Geoff Huston 427 Asia Pacific Network Information Centre 428 6 Cordelia St 429 South Brisbane, QLD 4101 430 Australia 432 Phone: +61 7 3858 3100 433 Email: gih@apnic.net 435 George Michaelson 436 Asia Pacific Network Information Centre 437 6 Cordelia St 438 South Brisbane, QLD 4101 439 Australia 441 Phone: +61 7 3858 3100 442 Email: ggm@apnic.net 444 Carlos M. Martinez 445 Latin American and Caribbean IP Address Regional Registry 446 Rambla Mexico 6125 447 Montevideo 11400 448 Uruguay 450 Phone: +598 2604 2222 451 Email: carlos@lacnic.net 453 Tim Bruijnzeels 454 RIPE Network Coordination Centre 455 Singel 258 456 Amsterdam 1016 AB 457 The Netherlands 459 Email: tim@ripe.net 460 Andrew Lee Newton 461 American Registry for Internet Numbers 462 3635 Concorde Parkway 463 Chantilly, VA 20151 464 USA 466 Email: andy@arin.net 468 Alain Aina 469 African Network Information Centre (AFRINIC) 470 11th Floor, Raffles Tower 471 Cybercity, Ebene 472 Mauritius 474 Phone: +230 403 51 00 475 Email: aalain@afrinic.net