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