idnits 2.17.1 draft-ietf-sidr-rpki-validation-reconsidered-03.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 17 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 180: '...he Relying Party MUST keep a set of ve...' RFC 2119 keyword, line 193: '...parent certificate a warning SHOULD be...' RFC 2119 keyword, line 197: '... the certificate MUST be considered in...' 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 2950 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: September 22, 2016 C. Martinez 6 LACNIC 7 T. Bruijnzeels 8 RIPE NCC 9 A. Newton 10 ARIN 11 A. Aina 12 AFRINIC 13 March 21, 2016 15 RPKI Validation Reconsidered 16 draft-ietf-sidr-rpki-validation-reconsidered-03 18 Abstract 20 This document proposes and alternative to the certificate validation 21 procedure specified in RFC6487 that reduces aspects of operational 22 fragility in the 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 September 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Certificate Validation in the RPKI . . . . . . . . . . . . . 2 60 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 61 4. An Amended RPKI Certification Validation Process . . . . . . 4 62 4.1. Changes to existing standards . . . . . . . . . . . . . . 4 63 4.2. An example . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document proposes and alternative to the certificate validation 73 procedure specified in RFC6487 that reduces aspects of operational 74 fragility in the management of certificates in the RPKI. 76 2. Certificate Validation in the RPKI 78 As currently defined in section 7.2 of [RFC6487], validation of PKIX 79 certificates that conform to the RPKI profile relies on the use of a 80 path validation process where each certificate in the validation path 81 is required to meet the certificate validation criteria. 83 These criteria require in particular that the resources on each 84 certificate in the validation path are "encompassed" by the resources 85 on the issuing certificate. The first certificate in the path is 86 required to be a trust anchor, and its resources are considered valid 87 by definition. 89 For example, in the following sequence: 91 Certificate 1 (trust anchor): 92 Issuer TA, Subject TA, Resources 192.0.2.0/24, AS64496-AS64500 94 Certificate 2: 95 Issuer TA, Subject CA1, Resources 192.0.2.0/24, AS64496-AS64500 97 Certificate 3: 98 Issuer CA1, Subject CA2, Resources 192.0.2.0/24, AS64496-AS64500 100 ROA 1: 101 Embedded Certificate 4 (EE certificate): 102 Issuer CA2, Subject R1, Resources 192.0.2.0/24 104 Prefix 192.0.2.0/24, Max Length 24, ASN 64496 106 All certificates in this scenario are considered valid in that the 107 resources on each certificate are encompassed by the issuing 108 certificate. The roa "ROA1" is also considered valid here in this 109 regard - the prefix is encompassed by the embedded EE certificate. 111 3. Operational Considerations 113 Resource allocations can change in the RPKI. And this can lead to 114 situations where an "over-claiming" certificate is introduced. 116 Consider the following sequence: 118 Certificate 1 (trust anchor): 119 Issuer TA, Subject TA, Resources 192.168.2.0/24, AS64496-AS64500 121 Certificate 2: 122 Issuer TA, Subject CA1, Resources 192.168.2.0/24 124 Certificate 3: 125 Issuer CA1, Subject CA2, Resources 192.168.2.0/24, AS64496-AS64500 127 ROA 1: 128 Embedded Certificate 4 (EE certificate): 129 Issuer CA2, Subject R1, Resources 192.168.2.0/24 131 Prefix 192.168.2.0/24, Max Length 24, ASN 64496 133 Here Certificate 2 from the previous example was re-issued by TA to 134 CA1 and certain AS resources were removed. However, CA1 failed to 135 re-issue a new Certificate 3 to CA2. As a result Certificate 3 is 136 now over-claiming and considered invalid, and by recursion ROA1 137 issued by CA2 is also invalid. 139 It should be noted that CA2 is not claiming any resources on ROA1 140 that it cannot receive on a new Certificate 3. If CA1 would only re- 141 issue a Certificate 3 without the AS resources to CA2, then ROA1 142 would be considered valid without the need for any further action by 143 CA2. 145 [RFC6492] describes the protocol for provisioning resource 146 certificates. In this protocol new resource certificates are always 147 issued by request of a child. If that protocol were strictly 148 followed then CA1 would have known that its resource set was about to 149 shrink, and it would have known that it issued some of those 150 resources to its child CA2. 152 The protocol currently lacks normative wording on how CAs should deal 153 with this situation, but one can imagine amending the protocol with 154 normative instructions that would require CA1 to refuse to request a 155 certificate with a shrunk resource set until all of its children 156 would have requested new shrunk certificates where applicable. And 157 that would forbid any parent CA to pro-actively re-issue a 158 certificate with shrunk resource set before receiving a certificate 159 re-issuance request from its child CA. 161 In practice such a model is unworkable for the CA higher in the path, 162 because it has no control over if and when it can shrink a 163 certificate for its children. Therefore higher level CAs will pro- 164 actively re-issue shrunk resource certificates when resources are no 165 longer validly held by a child. 167 The question here is whether the impact of such a re-issuance should 168 be limited to just the resources that seem to be under dispute 169 between TA and CA1, or all resources issued to CA2. 171 4. An Amended RPKI Certification Validation Process 173 4.1. Changes to existing standards 175 The following is a amended specification of certificate validation as 176 described in section 7.2 item number 6 of certificate validation in 177 [RFC6487] that describes the validation of resources in the RPKI 178 path: 180 The Relying Party MUST keep a set of verified resources for the 181 certificate independent of the RFC3779 extension itself, that is 182 built up using the following approach: 184 For any of the resource extensions that use the "inherit" 185 element as described in sections 2.2.3.5 and 3.2.3.3 of 186 [RFC3779], the corresponding resources of this type should be 187 taken from the parent certificate, where this issuer is the 188 subject. 190 For any other resources the intersection of the quoted 191 resources on this certificate and the parent certificate is 192 kept. If any resources were found on this certificate that 193 were not present on the parent certificate a warning SHOULD be 194 issued to help operators rectify this situation. 196 If the the set of verified resources obtained this way is empty, 197 then the certificate MUST be considered invalid. 199 Note that if this approach would be used in the example we cite in 200 section 3 of this document, Certificate 3 would have a verified 201 resource set that contains only "192.0.2.0/24", and a warning would 202 be issued with regards to resources "AS64496-AS64500". ROA1 would be 203 considered valid because the quoted prefix was also part of the 204 verified resource set of the embedded Certificate 4. 206 4.2. An example 208 Consider the following example under the amended approach: 210 Certificate 1 (trust anchor): 211 Issuer TA, Subject TA, Resources 192.168.2.0/24, AS64496-AS64500 213 Verified resources: 192.168.2.0/24, AS64496-AS64500 214 Warnings: none 216 Certificate 2: 217 Issuer TA, Subject CA1, Resources 192.168.2.0/24 219 Verified resources: 192.168.2.0/24 220 Warnings: none 222 Certificate 3: 223 Issuer CA1, Subject CA2, Resources 192.168.2.0/24, AS64496-AS64500 225 Verified resources: 192.168.2.0/24 226 Warnings: overclaim for AS64496-AS64500 228 ROA 1: 229 Embedded Certificate 4 (EE certificate): 230 Issuer CA2, Subject R1, Resources 192.168.2.0/24 232 Verified resources: 192.168.2.0/24 233 Warnings: none 235 Prefix 192.168.2.0/24, Max Length 24, ASN 64496 237 ROA1 is considered valid because the prefix matches the verified 238 resources on the embedded EE certificate. 240 ROA 2: 241 Embedded Certificate 5 (EE certificate): 242 Issuer CA2, Subject R2, Resources 192.168.3.0/24 244 Verified resources: none 245 Warnings: overclaim for 192.168.3.0/24 247 Prefix 192.168.3.0/24, Max Length 24, ASN 64496 249 ROA2 is considered invalid because the prefix does not 250 match the verified resources on the embedded EE certificate. 251 The amended approach cannot lead to ROAs showing up as valid 252 for resources that are not verified on the full path from the 253 Trust Anchor down to the ROA. 255 5. Security Considerations 257 The problem described in section 3 of this document has not occurred 258 to date. So one could consider this a low probability problem today. 259 However the potential impact on routing security would be high if the 260 inconsistency occurred near the apex of the RPKI hierarchy and would 261 invalidate the entirety of the sub-tree located below the point of 262 this inconsistency. 264 The proposed process does not change the probability of this problem, 265 but it limits the impact to just the resources that are under 266 dispute. As far as the authors can see there are no real new 267 problems introduced by this approach. 269 It should be noted that although this is a problem with a low 270 probability today this is largely due to the fact that most current 271 RPKI systems use their own Trust Anchor and do not support any large 272 number of delegated CAs. If this changes and the issuance and 273 publication of a certificate, by the parent, and its use, by a child, 274 are handled by different organisations more commonly, then the 275 probability of this problem will increase. 277 6. IANA Considerations 279 No updates to the registries are suggested by this document. 281 7. Acknowledgements 283 TBA. 285 8. Normative References 287 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 288 Addresses and AS Identifiers", RFC 3779, 289 DOI 10.17487/RFC3779, June 2004, 290 . 292 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 293 X.509 PKIX Resource Certificates", RFC 6487, 294 DOI 10.17487/RFC6487, February 2012, 295 . 297 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 298 Protocol for Provisioning Resource Certificates", 299 RFC 6492, DOI 10.17487/RFC6492, February 2012, 300 . 302 Authors' Addresses 304 Geoff Huston 305 Asia Pacific Network Information Centre 306 6 Cordelia St 307 South Brisbane, QLD 4101 308 Australia 310 Phone: +61 7 3858 3100 311 Email: gih@apnic.net 313 George Michaelson 314 Asia Pacific Network Information Centre 315 6 Cordelia St 316 South Brisbane, QLD 4101 317 Australia 319 Phone: +61 7 3858 3100 320 Email: ggm@apnic.net 322 Carlos M. Martinez 323 Latin American and Caribbean IP Address Regional Registry 324 Rambla Mexico 6125 325 Montevideo 11400 326 Uruguay 328 Phone: +598 2604 2222 329 Email: carlos@lacnic.net 331 Tim Bruijnzeels 332 RIPE Network Coordination Centre 333 Singel 258 334 Amsterdam 1016 AB 335 The Netherlands 337 Email: tim@ripe.net 339 Andrew Lee Newton 340 American Registry for Internet Numbers 341 3635 Concorde Parkway 342 Chantilly, VA 20151 343 USA 345 Email: andy@arin.net 346 Alain Aina 347 African Network Information Centre (AFRINIC) 348 11th Floor, Raffles Tower 349 Cybercity, Ebene 350 Mauritius 352 Phone: +230 403 51 00 353 Email: aalain@afrinic.net