idnits 2.17.1 draft-ietf-sidr-adverse-actions-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2016) is 2906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-07 == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-16 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-15 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR S. Kent 3 Internet-Draft BBN 4 Intended status: Informational D. Ma 5 Expires: October 15, 2016 ZDNS 6 April 13, 2016 8 Adverse Actions by a Certification Authority (CA) or Repository Manager 9 in the Resource Public Key Infrastructure (RPKI) 10 draft-ietf-sidr-adverse-actions-00 12 Abstract 14 This document analyzes actions by or against a CA or independent 15 repository manager in the RPKI that can adversely affect the Internet 16 Number Resources (INRs) associated with that CA or its subordinate 17 CAs. The analysis is based on examination of the data items in the 18 RPKI repository, as controlled by a CA (or independent repository 19 manager) and fetched by Relying Parties (RPs). The analysis is 20 performed from the perspective of an affected INR holder. The 21 analysis does not purport to be comprehensive; it does represent an 22 orderly way to analyze a number of ways that errors by or attacks 23 against a CA or repository manager can affect the RPKI and routing 24 decisions based on RPKI data. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 15, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 63 2.1. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.3. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 10 66 2.4. Certificate Revocation List . . . . . . . . . . . . . . . 11 67 2.5. CA Certificates . . . . . . . . . . . . . . . . . . . . . 14 68 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 69 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 70 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 71 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 72 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21 73 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 79 7.2. Informative References . . . . . . . . . . . . . . . . . 24 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 In the context of this document, any change to the Resource Public 85 Key Infrastructure (RPKI) [RFC6480] that results in a diminution of 86 the set of Internet Numeric Resources (INRs) associated with an INR 87 holder contrary to the holder's wishes is termed "adverse". 88 Additionally, when a ROA or router certificate is created that 89 "competes" with an existing ROA or router certificate (respectively), 90 the creation of the new ROA or router certificate is considered 91 adverse. (A newer ROA competes with an older ROA if the newer ROA 92 points to a different ASN and contains the same or a more specific 93 prefix. A newer router certificate competes with an older router 94 certificate if the newer one contains the same ASN and a different 95 public key.) 96 The SIDR WG is exploring proposals to address mistakes by RPKI 97 Certification Authorities (CAs) and to accommodate INR transfers. 98 Mistakes are not the only way that adverse changes to RPKI data can 99 arise. A CA or repository operator might be subject to an attack 100 [RFC7132]. For a CA, if an attack allows an adversary to use the 101 private keys of that CA to sign RPKI objects, then the effect is 102 analogous to the CA making mistakes. There is also the possibility 103 that a CA or repository operator may be subject to legal measures 104 that compel them to generate "bogus" signed objects or remove 105 legitimate repository data. In many cases, such actions may be hard 106 to distinguish from non-malicious mistakes, other than with respect 107 to the time required to remedy the adverse action. Thus this 108 document examines the implications of adverse actions with respect to 109 INRs irrespective of the cause of the actions. Standards for 110 transfer of INRs are being explored in [I-D.ymbk-sidr-transfer]. 111 That work also motivates exploration of the impact of both legitimate 112 transfers and botched transfer attempts on the RPKI. 114 This document analyzes the various types of actions by a CA (or 115 independent repository manager) that can adversely affect the INRs 116 associated with that CA, as well as the INRs of subordinate CAs. The 117 analysis is based on examination of the data items in the RPKI 118 repository, as controlled by a CA (or independent repository manager) 119 and fetched by Relying Parties (RPs). The analysis is done from the 120 perspective of an affected INR holder. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Analysis of RPKI Repository Objects 130 This section enumerates the RPKI repository system objects and 131 examines how changes to them affect Route Origination Authorizations 132 (ROAs) and router certificate validation. Identifiers are assigned 133 to errors for reference by later sections of this document. Note 134 that not all adverse actions may be addressed by this taxonomy. 136 The RPKI repository [RFC6481] contains a number of (digitally signed) 137 objects that are fetched and processed by RPs. Until the deployment 138 of BGPsec [I-D.ietf-sidr-bgpsec-overview], the principal goal of the 139 RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds 140 address space to an Autonomous System Number (ASN). A ROA can be 141 used to verify BGP announcements with respect to route origin 142 [RFC6483]. The most important objects in the RPKI for origin 143 validation are ROAs; all of the other RPKI objects exist to enable 144 the validation of ROAs in a fashion consistent with the INR 145 allocation system. Thus errors that result in changes to a ROA, or 146 to RPKI objects needed to validate a ROA, can cause RPs to reach 147 different (from what was intended) conclusions about the validity of 148 the bindings expressed in a ROA. 150 When BGPsec is deployed, router certificates 151 [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository 152 publication points. These are End-Entity (EE) certificates used to 153 verify signatures applied to BGP update data, to enable path 154 validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are 155 as important to path validation as ROAs are to origin validation. 157 The objects contained in the RPKI repository are of two types: 158 conventional PKI objects (certificates and Certificate Revocation 159 Lists (CRLs)) and RPKI-specific signed objects. The latter make use 160 of a common encapsulation format [RFC6488] based on the Cryptographic 161 Message Syntax (CMS) [RFC5652]. A syntax error in this common format 162 will cause an RP to reject the object, e.g., a ROA or Manifest, as 163 invalid. 165 Adverse actions take several forms: 167 * Deletion (D) is defined as removing an object from a 168 publication point, without the permission of the INR holder. 170 * Suppression (S) is defined as not deleting an object, or not 171 publishing an object, as intended by an INR holder. This 172 action also includes retaining a prior version of an object in 173 a publication point when a newer version is available for 174 publication. 176 * Corruption (C) is defined as modification of a signed object in 177 a fashion not requiring access to the private key used to sign 178 the object. Thus a corrupted object will not carry a valid 179 signature. Implicitly, the corrupted object replaces the 180 legitimate version. 182 * Modification (M) is defined as publishing a syntactically 183 valid, verifiable version of an object that differs from the 184 (existing) version authorized by the INR holder. Implicitly, 185 the legitimate version of the affected object is deleted and 186 replaced by the modified object. 188 * Revocation (R) is defined as revoking a certificate (EE or CA) 189 by placing its serial number on the appropriate CRL, without 190 authorization of the INR holder. 192 * Injection (I) is defined as introducing an instance of a signed 193 object into a publication point (without authorization of the 194 INR holder). It assumes that the signature on the object will 195 be viewed as valid by RPs. 197 The first three of these actions (deletion, suppression, and 198 corruption) can be effected by any entity that manages the 199 publication point of the affected INR holder. Also, an entity with 200 the ability to act as a man-in-the-middle between an RP and a 201 repository can effect these actions with respect to the RP in 202 question. 204 The latter three actions (modification, revocation, and injection) 205 nominally require access to the private key of the INR holder. 207 All six of these actions also can be effected by a parent CA. A 208 parent CA could reissue the INR holder's CA certificate, but with a 209 different public key, matching a private key to which the parent CA 210 has access. The CA could generate new signed objects using the 211 private key associated with the reissued certificate, and publish 212 these objects at a location of its choosing. 214 Most of these actions may be performed independently or in 215 combination with one another. For example, a ROA may be revoked and 216 deleted or revoked and replaced with a modified ROA. Where 217 appropriate, the analysis of adverse actions will distinguish between 218 individual actions, or combinations thereof, that yield different 219 outcomes for RPs. Recall that the focus of the analysis is the 220 impact on ROAs and router certificates, with respect to RP 221 processing. 223 The following sections examine how the actions enumerated above 224 affect objects in the RPKI repository system. Each action is 225 addressed in order (Deletion, Suppression, Corruption, Modification, 226 Revocation, and Injection) for each object, making it easy to see how 227 each action has been considered with regard to each object. (For the 228 GhostBusters record we condensed the discussion of the actions 229 because the impact is the same in each case.) 231 2.1. ROA 233 In addition to the generic RPKI object syntax checks, ROA validation 234 requires that the signature on the ROA can be validated using the 235 public key from the EE certificate embedded in the ROA [RFC6482]. It 236 also requires that the EE certificate be validated consistently with 237 the procedures described in [RFC6482] and [RFC6487]. Adverse actions 238 against a ROA can cause the following errors: 240 A-1.1 Deletion 242 A-1.1.1 A ROA may be deleted from the indicated 243 publication point. The result is to void the 244 binding between the prefix(es) and the AS number 245 in the ROA. An RP that previously viewed this 246 binding as authentic will now not have any 247 evidence about its validity. For origin 248 validation, this means that a legitimate route 249 will be treated as NotFound (if there are no other 250 ROAs for the same prefix) or Invalid (if there is 251 another ROA for the same prefix, but with a 252 different AS number). 254 A-1.2 Suppression 256 A-1.2.1 Publication of a newer ROA may be suppressed. If 257 the INR holder intended to change the binding 258 between the prefix(es) and the AS number in the 259 ROA, this change will not be effected. As a 260 result, RPs may continue to believe an old prefix/ 261 ASN binding that is no longer what the INR holder 262 intended. 264 A-1.2.2 If an INR holder intends to issue and publish two 265 (or more) new ROAs for the same address space, one 266 (or more) of the new ROAs may be suppressed while 267 the other is published. In this case, RPs will 268 de-preference the suppressed prefix/ASN binding. 269 Suppression of the new ROA might cause traffic to 270 flow to an ASN other than the one(s) intended by 271 the INR holder. 273 A-1.2.3 If an INR holder intends to delete all ROAs for 274 the same address space, some of them may be 275 retained while the others are deleted. Preventing 276 the deletion of some ROAs can cause traffic to 277 continue to be delivered to the ASNs that were 278 advertised by these ROAs. Deletion of all ROAs is 279 consistent with a transfer of address space to a 280 different INR holder, in a phased fashion. Thus 281 this sort of attack could interfere with the 282 successful transfer of the affected address space 283 (until such time as the prefixes are removed from 284 the previous INR holder's CA certificate). 286 A-1.3 Corruption 288 A-1.3.1 A ROA may be corrupted. A corrupted ROA will be 289 ignored by an RP, so the effect is essentially the 290 same as for A-1.1 and 1.5. A possible difference 291 is that an RP may be alerted to the fact that the 292 ROA was corrupted, which might attract attention 293 to the attack. 295 A-1.4 Modification 297 A-1.4.1 A ROA may be modified so that the Autonomous 298 System Number (ASN) or one or more of the address 299 blocks in a ROA is different from the values the 300 INR holder intended for this ROA. (This action 301 assumes that the modified ROA's ASN and address 302 ranges are authorized for use by the INR holder.) 303 This attack will cause RPs to de-preference the 304 legitimate prefix/ASN binding intended by the INR 305 holder. 307 A-1.5 Revocation 309 A-1.5.1 A ROA may be revoked (by placing its EE 310 certificate on the CRL for the publication point). 311 This has the same effect as A-1.1. 313 A-1.6 Injection 315 A-1.6.1 A ROA expressing different bindings than those 316 published by the INR holder may be injected into a 317 publication point. This action could authorize an 318 additional ASN to advertise the specified prefix, 319 allowing that ASN to originate routes for the 320 prefix, thus enabling route origin spoofing. In 321 this case, the injected ROA is considered to be in 322 competition with any existing authorized ROAs for 323 the specified prefix. 325 A-1.6.2 An injected ROA might express a different prefix 326 for an ASN already authorized to originate a 327 route, e.g., a longer prefix, which could enable 328 that ASN to override other advertisements using 329 shorter prefixes. If there are other ROAs that 330 authorize different ASNs to advertise routes to 331 the injected ROA's prefix, then the injected ROA 332 is in competition with these ROAs. 334 2.2. Manifest 336 Each repository publication point contains a manifest [RFC6486]. The 337 RPKI incorporates manifests to enable RPs to detect suppression and/ 338 or substitution of (more recent) publication point objects, as the 339 result of a mistake or attack. A manifest enumerates (by filename) 340 all of the other signed objects at the publication point. The 341 manifest also contains a hash of each enumerated file, to enable an 342 RP to determine if the named file content matches what the INR holder 343 identified in the manifest. 345 A manifest is an RPKI signed object, so it is validated as per 346 [RFC6488]. If a manifest is modified in a way that causes any of 347 these checks to fail, the manifest will be considered invalid. 348 Suppression of a manifest itself (indicated by a stale manifest) also 349 can cause an RP to not detect suppression of other signed objects at 350 the publication point. (Note that if a Manifest's EE certificate 351 expires at the time that the Manifest is scheduled to be replaced, a 352 delay in publication will cause the Manifest to become invalid, not 353 merely stale. This very serious outcome should be avoided, e.g., by 354 making the Manifest EE certificate's notAfter value the same as that 355 of the CA certificate under which it was issued). If a signed object 356 at a publication point can be validated (using the rules applicable 357 for that object type), then an RP MAY accept that object, even if 358 there is no matching entry for it on the manifest. However, it 359 appears that most RP software ignores publication point data that 360 fails to match Manifest entries (at the time this document was 361 written). 363 Corruption, suppression, modification, or deletion of a manifest 364 might not affect RP processing of other publication point objects, as 365 specified in [RFC6486]. However, as noted above, many RP 366 implementations ignore objects that are present at a publication 367 point but not listed in a valid Manifest. Thus the following actions 368 against a manifest can impact RP processing: 370 A-2.1 Deletion 372 A-2.1.1 A Manifest may be deleted from the indicated 373 publication point. In this circumstance an RP may 374 elect to use the previous Manifest (if available), 375 and may ignore any new/changed objects at the 376 publication point. The implications of this 377 action are equivalent to suppression of 378 publication of the objects that are not recognized 379 by RPs because the new objects are not present in 380 the old Manifest. For example, a new ROA could be 381 ignored (A-1.2). A newly issued CA certificate 382 might be ignored (A-5.1). A subordinate CA 383 certificate that was revoked might still be viewed 384 as valid by RPs (A-4.1). A new or changed router 385 certificate might be ignored (A-6.2) as would a 386 revised Ghostbusters record (A-3.1). 388 A-2.2 Suppression 390 A-2.2.1 Publication of a newer Manifest may be suppressed. 391 Suppression of a newer Manifest probably will 392 cause an RP to rely on a cached Manifest (if 393 available). The older Manifest would not 394 enumerate newly added objects, and thus those 395 objects might be ignored by an RP, equivalent to 396 deletion of those objects (A-1.1, A-3.1, A-4.1, 397 A-5.1, A-6.1). 399 A-2.3 Corruption 401 A-2.3.1 A Manifest may be corrupted. A corrupted Manifest 402 will be rejected by RPs. This may cause RPs to 403 rely on a previous manifest, with the same impact 404 as A-2.2. If an RP does not revert to using a 405 cached Manifest, the impact of this action is very 406 severe, i.e., all publication point objects 407 probably will be viewed as invalid, including 408 subordinate tree objects. This is equivalent to 409 revoking or deleting an entire subtree (see 410 A-4.4.2). 412 A-2.4 Modification 414 A-2.4.1 A Manifest may be modified to remove one or more 415 objects. Because the modified Manifest is viewed 416 as valid by RPs, any objects that were removed may 417 be ignored by RPs. This is equivalent to deleting 418 these objects from the repository. The impact of 419 this action will vary, depending on which objects 420 are (effectively) removed. However, the impact is 421 equivalent to deletion of the object in question, 422 (A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). 424 A-2.4.2 A Manifest may be modified to add one or more 425 objects. If an added object has a valid signature 426 (and is non-expired), it will be accepted by RPs 427 and processed accordingly. If the added object 428 was previously deleted by the INR holder, this 429 action is equivalent to suppressing deletion of 430 that object. If the object is newly created, or 431 modified, it is equivalent to a modification or 432 injection action for the type of object in 433 question, and thus is discussed in the relevant 434 section for those actions for the object type. 436 A-2.4.3 A Manifest may be modified to list an incorrect 437 hash for one or more objects. An object with an 438 incorrect hash may be ignored by an RP. Thus the 439 effect may be equivalent to corrupting the object 440 in question, although the error reported by RP 441 software would differ from that reported for a 442 corrupted object. (The Manifest specifications do 443 not require an RP to ignore an object that has a 444 valid signature and that is not revoked or 445 expired, but for which the hash doesn't match the 446 object. However, an RP may elect to do so.) 448 A-2.5 Revocation 450 A-2.5.1 A Manifest may be revoked (by including its EE 451 certificate on the CRL for the publication point). 452 A revoked Manifest will be ignored by an RP, which 453 probably would revert to an older (cached) 454 Manifest. The implications for RPs are equivalent 455 to A-2.1, with regard to new/changed objects. 457 A-2.6 Injection 459 A-2.6.1 A Manifest representing different objects may be 460 injected into a publication point. The effects 461 are the same as for a modified Manifest (see 462 above). The impact will depend on the type of the 463 affected object(s), and thus is discussed in the 464 relevant section(s) for each object type. 466 2.3. Ghostbusters Record 468 The Ghostbusters record [RFC6493] is a signed object that MAY be 469 included at a publication point, at the discretion of the INR holder 470 or publication point operator. The record is validated according to 471 [RFC6488]. Additionally, the syntax of the record is verified based 472 on the vCard profile from Section 5 of [RFC6493]. Errors in this 473 record do not affect RP processing. However, if an RP encounters a 474 problem with objects at a publication point, the RP may use 475 information from the record to contact the publication point 476 operator. 478 Adverse actions against a Ghostbusters record can cause the following 479 error: 481 A-3.1 Deletion, suppression, corruption, or revocation of a 482 Ghostbusters record could prevent an RP from contacting the 483 appropriate entity when a problem is detected by the RP. 484 Modification or injection of a Ghostbusters record could 485 cause an RP to contact the wrong entity, thus delaying 486 remediation of a detected anomaly. All of these actions 487 are viewed as equivalent from an RP processing perspective; 488 they do not alter RP validation of ROAs or router 489 certificates. However, these actions can interfere with 490 remediation of a problem when detected by an RP. 492 2.4. Certificate Revocation List 494 Each publication point contains a CRL that enumerates revoked (not 495 yet expired) certificates issued by the CA associated with the 496 publication point [RFC6481]. 498 Adverse actions against a CRL can cause the following errors: 500 A-4.1 Deletion 502 A-4.1.1 If a CRL is deleted, RPs will continue to use an 503 older, previously fetched Certificate Revocation 504 List. As a result, they will not be informed of 505 any changes in revocation status of subordinate CA 506 or router certificates or the EE certificates of 507 signed objects, e.g., ROAs. This action is 508 equivalent to corruption of a CRL, since a 509 corrupted CRL will not be accepted by an RP. 511 A-4.1.2 Deletion of a CRL could cause an RP to continue to 512 accept a ROA that no longer expresses the intent 513 of an INR holder. As a result, an announcement 514 for the affected prefixes would be viewed as 515 Valid, instead of NotFound or Invalid. In this 516 case, the effect is analogous to A-1.2. 518 A-4.1.3 If a router certificate were revoked, and the CRL 519 were deleted, RPs would not be aware of the 520 revocation. They might continue to accept the 521 old, revoked, router certificate. If the 522 certificate had been revoked due to a compromise 523 of the router's private key, RPs would be 524 vulnerable to accepting routes signed by an 525 unauthorized entity. 527 A-4.1.4 If a subordinate CA certificate were revoked on 528 the deleted CRL, the revocation would not take 529 effect. This could interfere with a transfer of 530 address space from the subordinate CA, adversely 531 affecting routing to the new holder of the space. 533 A-4.2 Suppression 535 A-4.2.1 If publication of the most recent CRL is 536 suppressed, an RP will not be informed of the most 537 recent revocation status of subordinate CA or 538 router certificates or the EE certificates of 539 signed objects. If an EE certificate has been 540 revoked and the associated signed object is still 541 present in the publication point, an RP might 542 mistakenly treat that object as valid. (This 543 would happen if the object is still in the 544 manifest or the RP is configured to process valid 545 objects that are not on the manifest.) This type 546 of action is of special concern if the affected 547 object is a ROA, a router certificate, or a 548 subordinate CA certificate. The effects here are 549 equivalent to CRL deletion (A-4.1), but 550 suppression of a new CRL may not even be reported 551 as an error, i.e., if the suppressed CRL were 552 issued before the NextUpdate time (of the previous 553 CRL). 555 A-4.3 Corruption 557 A-4.3.1 If a CRL is corrupted, an RP will reject it. If a 558 prior CRL has not yet exceeded its NextUpdate 559 time, an RP will continue to use the prior CRL. 560 Even if the prior CRL has passed the NextUpdate 561 time, an RP may choose to continue to rely on the 562 prior CRL. The effects are essentially equivalent 563 to suppression or deletion of a CRL (A-4.1, A-4.2) 565 A-4.4 Modification 567 A-4.4.1 If a CRL is modified to erroneously list a signed 568 object's EE certificate as revoked, the 569 corresponding object will be treated as invalid by 570 RPs, even if it is present in a publication point. 571 If this object is a ROA, the (legitimate) binding 572 expressed by the ROA will be ignored by an RP (see 573 A-1.5). If a CRL is modified to erroneously list 574 a router certificate as revoked, a path signature 575 associated with that certificate will be treated 576 as Not Valid by RPs (see A-6.5). 578 A-4.4.2 If a CRL is modified to erroneously list a CA 579 certificate as revoked, that CA and all 580 subordinate signed objects will be treated as 581 invalid by RPs. Depending on the location of the 582 affected CA in the hierarchy, these effects could 583 be very substantial, causing routes that should be 584 Valid to be treated as NotFound. 586 A-4.4.3 If a CRL is modified to omit a revoked EE, router, 587 or CA certificate, RPs likely will continue to 588 accept the revoked, signed object as valid. This 589 contravenes the intent of the INR holder. If an 590 RP continues to accept a revoked ROA, it may make 591 routing decisions on now-invalid data. This could 592 cause valid routes to be de-preferenced and 593 invalid routes to continue to be accepted. 595 A-4.5 Revocation 597 A-4.5.1 A CRL cannot be revoked, per se, but it will fail 598 validation if the CA certificate under which it 599 was issued is revoked. See A-5.5 for a discussion 600 of that action. 602 A-4.6 Injection 604 A-4.6.1 Insertion of a bogus CRL can have the same effects 605 as listed above for a modified CRL, depending on 606 how the inserted CRL differs from the correct CRL. 608 2.5. CA Certificates 610 Every INR holder is represented by one or more CA certificates. An 611 INR holder has multiple CA certificates if it holds resources 612 acquired from different sources. Also, every INR holder has more 613 than one CA certificate during key rollover [RFC6489] and algorithm 614 rollover [RFC6916]. 616 If a publication point is not a leaf in the RPKI hierarchy, then the 617 publication point will contain one or more CA certificates, each 618 representing a subordinate CA. Each subordinate CA certificate 619 contains a pointer (SIA) to the publication point where the signed 620 objects associated with that CA can be found [RFC6487]. 622 A CA certificate is a complex data structure and thus errors in that 623 structure may have different implications for RPs depending on the 624 specific data that is in error. 626 Adverse actions against a CA certificate can cause the following 627 errors: 629 A-5.1 Deletion 631 A-5.1.1 Deletion of a CA certificate would cause an RP to 632 not be able to locate signed objects generated by 633 that CA, except those that have been cached by the 634 RP. Thus an RP would be unaware of changed or new 635 (issued after the cached data) INR bindings 636 asserted in subordinate ROAs, and the RP would be 637 unable to validate new or changed router 638 certificates. If the missed objects were intended 639 to replace ROAs or router certificates prior to 640 expiration, then when those objects expire, RPs 641 may cease to view them as valid. As a result, 642 valid routes may be viewed as NotFound or Invalid. 644 A-5.2 Suppression 646 A-5.2.1 If publication of a CA certificate is suppressed, 647 the impact depends on what changes appeared in the 648 suppressed certificate. If the SIA value changed, 649 the effect would be the same as in A-5.1 or 5.4.3. 650 If the 3779 extensions in the suppressed 651 certificate changed, the impact would be the same 652 as in 5.4.1. If the AIA extension changed in the 653 suppressed certificate, the impact would be the 654 same as in 5.4.4. 656 A-5.3 Corruption 658 A-5.3.1 Corruption of a CA certificate will cause it to be 659 rejected by RPs. In turn, this may cause 660 subordinate signed objects to become invalid. An 661 RP that has cached the subtree under the affected 662 CA certificate may continue to view it as valid, 663 until objects expire. But changed or new objects 664 might not be retrieved, depending on details of 665 the design of the RP software. Thus this action 666 may be equivalent to suppressing changes to the 667 affected subtree. 669 A-5.4 Modification 671 A-5.4.1 If a CA certificate is modified, but still 672 conforms to the RPKI certificate profile 673 [RFC6485], it will be accepted by RPs. If an 674 [RFC3779] extension in this certificate is changed 675 to exclude INRs that were previously present, then 676 subordinate signed objects will become invalid if 677 they rely on the excised INRs. If these objects 678 are CA certificates, their subordinate signed 679 objects will be treated as invalid. If the 680 objects are ROAs, the binding expressed by the 681 affected ROAs will be ignored by RPs. If the 682 objects are router certificates, BGPsec_Path 683 attributes [I-D.ietf-sidr-bgpsec-protocol] 684 verifiable under these certificates will be 685 considered invalid. 687 A-5.4.2 If an [RFC3779] extension in this certificate is 688 changed to include INRs that were previously 689 absent in this certificate, and are still absent 690 in the issuer's certificate, then this certificate 691 will fail validation and be treated as invalid. 692 The impact of this is the same as in A-5.5. 694 A-5.4.3 If the SIA extension of a CA certificate is 695 modified to refer to another publication point, 696 this will cause an RP to look at another location 697 for subordinate objects. This could cause RPs to 698 not acquire the objects that the INR holder 699 intended to be retrieved - manifests, ROAs, router 700 certificates, Ghostbuster records, or any 701 subordinate CA certificates associated with that 702 CA. If the objects at this new location contain 703 invalid signatures or appear to be corrupted, they 704 may be rejected. In this case, cached versions of 705 the objects may be viewed as valid by an RP, until 706 they expire. If the objects at the new location 707 have valid signatures and pass path validation 708 checks, they will replace the cached objects, 709 effectively replacing the INR holder's objects. 711 A-5.4.4 If the AIA extension in a CA certificate is 712 modified, it would point to a different CA 713 certificate, not the parent CA certificate. This 714 extension is used only for path discovery, not 715 path validation. Path discovery in the RPKI is 716 usually performed on a top-down basis, starting 717 with TAs and recursively descending the RPKI 718 hierarchy. Thus there may be no impact on the 719 ability of clients to acquire and validate 720 certificates if the AIA is modified. 722 A-5.4.5 If the Subject Public Key Info (and Subject Key 723 Identifier extension) in a CA certificate is 724 modified to contain a public key corresponding to 725 a private key held by the parent, the parent could 726 sign objects as children of the affected CA 727 certificate. With this capability, the parent 728 could replace the INR holder, issuing new signed 729 objects that would be accepted by RPs (as long as 730 they do not violate the path validation criteria). 731 This would enable the parent to effect 732 modification, revocation, and injection actions 733 against all of the objects under the affected CA 734 certificate, including subordinate CA 735 certificates. 737 A-5.5 Revocation 739 A-5.5.1 If a CA certificate is revoked an RP will treat as 740 invalid all subordinate signed objects, both 741 immediate and transitively. The effects are 742 essentially the same as described in A-4.4.2. 744 A-5.6 Injection 746 A-5.6.1 If a CA certificate is injected the impact will 747 depend on the data contained in the injected 748 certificate. Changes will generally be equivalent 749 to modification actions as described in A-5.4. 751 2.6. Router Certificates 753 Router certificates are used by RPs to verify signatures on 754 BGPsec_Path attributes carried in Update messages. 756 Each AS is free to determine the granularity at which router 757 certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each 758 participating AS is represented by one or more router certificates. 759 During key or algorithm rollover, multiple router certificates will 760 be present in a publication point, even if the AS is normally 761 represented by just one such certificate. 763 Adverse actions against router certificates can cause the following 764 errors: 766 A-6.1 Deletion 768 A-6.1.1 Deletion of a router certificate would cause an RP 769 to not be able to verify signatures applied to 770 BGPsec_Path attributes on behalf of the AS in 771 question. In turn, this would cause the route to 772 be treated with lower preference than competing 773 routes that have valid BGPsec_Path attribute 774 signatures. (However, if another router 775 certificate for the affected AS is valid and 776 contains the same AS number and public key, and is 777 in use by that AS, there would be no effect on 778 routing. This scenario will arise if a router 779 certificate is renewed, i.e., issued with a new 780 validity interval.) 782 A-6.2 Suppression 784 A-6.2.1 Suppression of a router certificate could have the 785 same impact as deletion of a certificate of this 786 type, i.e., if no router certificate was 787 available, BGPsec attributes that should be 788 verified using the certificate would fail 789 validation. If an older certificate existed, and 790 had not expired, it would be used by RPs. If the 791 older certificate contained a different ASN, the 792 impact would be the same as in A-6.4. 794 A-6.3 Corruption 796 A-6.3.1 Corruption of a router certificate will result in 797 the certificate being rejected by RPs. Absent a 798 valid router certificate, BGPsec_Path attributes 799 associated with that certificate will be 800 unverifiable. In turn, this would cause the route 801 to be treated with lower preference than competing 802 routes that have valid BGPsec_Path attribute 803 signatures. 805 A-6.4 Modification 807 A-6.4.1 If a router certificate is modified to represent a 808 different ASN, but it still passes syntax checks, 809 then this action could cause signatures on 810 BGPsec_Path attributes to be associated with the 811 wrong AS. This could cause signed routes to be 812 inconsistent with the intent of the INR holder, 813 e.g., traffic might be routed via a different AS 814 than intended. 816 A-6.5 Revocation 818 A-6.5.1 If a router certificate were revoked, BGPsec_Path 819 attributes verifiable using that certificate would 820 not longer be considered valid. The impact would 821 be the same as for a deleted certificate, as 822 described in A-6.1 824 A-6.6 Injection 826 A-6.6.1 Insertion of a router certificate could authorize 827 additional routers to sign BGPsec traffic for the 828 targeted ASN, and thus undermine fundamental 829 BGPsec security guarantees. If there are 830 existing, authorized router certificates for the 831 same ASN, then the injected router certificate is 832 in competition with these existing certificates. 834 3. Analysis of Actions Relative to Scenarios 836 This section examines the types of problems that can arise in four 837 scenarios described below. We consider mistakes, (successful) 838 attacks against a CA or a publication point, and situations in which 839 a CA or publication point manager is compelled to take action by a 840 law enforcement authority. 842 We explore the following four scenarios: 844 A. An INR holder operates its own CA and manages its own 845 repository publication point. 847 B. An INR holder operates its own CA, but outsources management 848 of its repository publication point to its parent or another 849 entity. 851 C. An INR holder outsources management of its CA to its parent, 852 but manages its own repository publication point. 854 D. An INR holder outsources management of its CA and its 855 publication point to its parent. 857 Note that these scenarios focus on the affected INR holder as the 858 party directly affected by an adverse action. The most serious cases 859 arise when the INR holder appears as a high-tier CA in the RPKI 860 hierarchy; in such situations subordinate INR holders may be affected 861 as a result of an action. A mistake by or an attack against a "leaf" 862 has more limited impact because all of the affected INRs belong to 863 the INR holder itself. 865 In Scenario A, actions by the INR holder can adversely affect all of 866 its resources and, transitively, resources of any subordinate CAs. 867 (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs 868 and the damage is limited to its own INRs.) 870 In Scenario B, actions by the (outsourced) repository operator also 871 can adversely affect the resources of the INR holder, and those of 872 any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it 873 has no subordinate CAs and the damage is limited, as in Scenario A.) 874 The range of adverse effects here includes those in Scenario A, and 875 adds a new potential source of adverse actions, i.e., the outsourced 876 repository operator. 878 In Scenario C, all signed objects associated with the INR holder are 879 generated by the parent CA but are self-hosted. (We expect this 880 scenario to be rare, because an INR holder that elects to outsource 881 CA operation seems unlikely to manage its own repository publication 882 point.) Because that CA has the private key used to sign them, it 883 can generate alternative signed objects---ones not authorized by the 884 INR holder. However, erroneous objects created by the parent CA will 885 not be published by the INR holder IF the holder checks them first. 886 Because the parent CA is acting on behalf of the INR holder, mistakes 887 by or attacks against that entity are equivalent to ones effected by 888 the INR holder in Scenario A. 890 The INR holder is most vulnerable in Scenario D. Actions by the 891 parent CA, acting on behalf of the INR holder, can adversely affect 892 all signed objects associated with that INR holder, including any 893 subordinate CA certificates. These actions will presumably translate 894 directly into publication point changes, because the parent CA is 895 managing the publication point for the INR holder. The range of 896 adverse effects here includes those in Scenarios A, B, and C. 898 3.1. Scenario A 900 In this scenario, the INR holder acts as its own CA and it manages 901 its own publication point. Actions by the INR holder can adversely 902 affect all of its resources and, transitively, resources of any 903 subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no 904 subordinate CAs and the damage is limited to its own INRs.) Mistakes 905 by the INR holder can cause any of the actions noted in Section 2. A 906 successful attack against this CA can effect all of the modification, 907 revocation, or injection actions noted in that section. (We assume 908 that objects generated by the CA are automatically published). An 909 attack against the publication point can effect all of the deletion, 910 suppression, or corruption actions noted in that section. 912 3.2. Scenario B 914 In this scenario, the INR holder acts as its own CA and but it 915 delegates management of it own publication point to a third party. 916 Mistakes by the INR holder can cause any of the modification, 917 revocation, or injection actions described in Section 2. Actions by 918 the repository operator can adversely affect the resources of the INR 919 holder, and those of any subordinate CAs. (If the CA is a "leaf" in 920 the RPKI, then it has no subordinate CAs and the damage is limited, 921 as in Scenario A.) The range of adverse effects here includes those 922 in Scenario A, and adds a new potential source of adverse actions, 923 i.e., the third party repository operator. A successful attack 924 against the CA can effect all of the modification, revocation, or 925 injection actions noted in that section (assuming that objects 926 generated by the CA are automatically published). Here, actions by 927 the publication point manager (or attacks against that entity) can 928 effect all of the deletion, suppression, or corruption actions noted 929 in Section 2. 931 3.3. Scenario C 933 In this scenario, the INR holder outsources management of its CA to 934 its parent, but manages its own repository publication point. All 935 signed objects associated with the INR holder are generated by the 936 parent CA but are self-hosted. (We expect this scenario to be rare, 937 because an INR holder that elects to outsource CA operation seems 938 unlikely to manage its own repository publication point.) Because 939 that CA has the private key used to sign them, it can generate 940 alternative signed objects -- ones not authorized by the INR holder. 941 However, erroneous objects created by the parent CA will not be 942 published by the INR holder IF the holder checks them first. Because 943 the parent CA is acting on behalf of the INR holder, mistakes by or 944 attacks against that entity are equivalent to ones effected by the 945 INR holder in Scenario A. Mistakes by the INR holder, acted upon by 946 the parent CA, can cause any of the actions noted in Section 2. 947 Actions unilaterally undertaken by the parent CA also can have the 948 same effect, unless the INR holder checks the signed objects before 949 publishing them. A successful attack against the parent CA can 950 effect all of the modification, revocation, or injection actions 951 noted in Section 2, unless the INR holder checks the signed objects 952 before publishing them. An attack against the INR holder (in its 953 role as repository operator) can effect all of the deletion, 954 suppression, or corruption actions noted in Section 2 (because the 955 INR holder is managing its publication point), unless the INR holder 956 checks the signed objects before publishing them. (An attack against 957 the INR holder implies that the path it uses to direct the parent CA 958 to issue and publish objects has been compromised.) 960 3.4. Scenario D 962 In this scenario an INR holder outsources management of both its CA 963 and its publication point to its parent. The INR holder is most 964 vulnerable in this scenario. Actions by the parent CA, acting on 965 behalf of the INR holder, can adversely affect all signed objects 966 associated with that INR holder, including any subordinate CA 967 certificates. These actions will presumably translate directly into 968 publication point changes, because the parent CA is managing the 969 publication point for the INR holder. The range of adverse effects 970 here includes those in Scenarios A, B, and C. Mistakes by the INR 971 holder, acted upon by the parent CA, can cause any of the actions 972 noted in Section 2. Actions unilaterally undertaken by the parent CA 973 also can have the same effect. A successful attack against the 974 parent CA can effect all of the modification, revocation, or 975 injection actions noted in Section 2. An attack against the parent 976 CA can also effect all of the deletion, suppression, or corruption 977 actions noted in Section 2 (because the parent CA is managing the INR 978 holder's publication point). 980 4. Security Considerations 982 This informational document describes a threat model for the RPKI, 983 focusing on mistakes by or attacks against CAs and independent 984 repository managers. It is intended to provide a basis for the 985 design of future RPKI security mechanisms that seek to address the 986 concerns associated with such actions. 988 The analysis in this document identifies a number of circumstances in 989 which attacks or errors can have significant impacts on routing. One 990 ought not interpret this as a condemnation of the RPKI. It is only 991 an attempt to document the implications of a wide range of attacks 992 and errors, in the context of the RPKI. The primary alternative 993 mechanism for disseminating routing information is Internet Routing 994 Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the 995 Routing Policy Specification Language (RPSL) [RFC2622]. IRR 996 technology exhibits its own set of security problems, which are 997 discussed in [RFC7682]. 999 5. IANA Considerations 1001 This document has no actions for IANA. 1003 6. Acknowledgements 1005 The authors thank Richard Hansen and David Mandelberg for their 1006 review, feedback and editorial assistance. 1008 7. References 1010 7.1. Normative References 1012 [I-D.ietf-sidr-bgpsec-overview] 1013 Lepinski, M., "An Overview of BGPsec", draft-ietf-sidr- 1014 bgpsec-overview-07 (work in progress), June 2015. 1016 [I-D.ietf-sidr-bgpsec-pki-profiles] 1017 Reynolds, M. and S. Kent, "A Profile for BGPsec Router 1018 Certificates, Certificate Revocation Lists, and 1019 Certification Requests", draft-ietf-sidr-bgpsec-pki- 1020 profiles-16 (work in progress), March 2016. 1022 [I-D.ietf-sidr-bgpsec-protocol] 1023 Lepinski, M. and K. Sriram, "BGPsec Protocol 1024 Specification", draft-ietf-sidr-bgpsec-protocol-15 (work 1025 in progress), March 2016. 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, 1029 DOI 10.17487/RFC2119, March 1997, 1030 . 1032 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1033 Addresses and AS Identifiers", RFC 3779, 1034 DOI 10.17487/RFC3779, June 2004, 1035 . 1037 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1038 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1039 . 1041 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1042 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1043 February 2012, . 1045 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1046 Resource Certificate Repository Structure", RFC 6481, 1047 DOI 10.17487/RFC6481, February 2012, 1048 . 1050 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1051 Origin Authorizations (ROAs)", RFC 6482, 1052 DOI 10.17487/RFC6482, February 2012, 1053 . 1055 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1056 Origination Using the Resource Certificate Public Key 1057 Infrastructure (PKI) and Route Origin Authorizations 1058 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1059 . 1061 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 1062 Use in the Resource Public Key Infrastructure (RPKI)", 1063 RFC 6485, DOI 10.17487/RFC6485, February 2012, 1064 . 1066 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1067 "Manifests for the Resource Public Key Infrastructure 1068 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1069 . 1071 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1072 X.509 PKIX Resource Certificates", RFC 6487, 1073 DOI 10.17487/RFC6487, February 2012, 1074 . 1076 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1077 Template for the Resource Public Key Infrastructure 1078 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1079 . 1081 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 1082 Authority (CA) Key Rollover in the Resource Public Key 1083 Infrastructure (RPKI)", BCP 174, RFC 6489, 1084 DOI 10.17487/RFC6489, February 2012, 1085 . 1087 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 1088 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 1089 February 2012, . 1091 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1092 Procedure for the Resource Public Key Infrastructure 1093 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1094 2013, . 1096 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1097 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1098 . 1100 7.2. Informative References 1102 [I-D.ymbk-sidr-transfer] 1103 Austein, R., Bush, R., Huston, G., and G. Michaelson, 1104 "Resource Transfer in the Resource Public Key 1105 Infrastructure", draft-ymbk-sidr-transfer-01 (work in 1106 progress), July 2015. 1108 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1109 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 1110 "Routing Policy Specification Language (RPSL)", RFC 2622, 1111 DOI 10.17487/RFC2622, June 1999, 1112 . 1114 [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. 1115 Alaettinoglu, "Using RPSL in Practice", RFC 2650, 1116 DOI 10.17487/RFC2650, August 1999, 1117 . 1119 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 1120 Murphy, "Routing Policy System Security", RFC 2725, 1121 DOI 10.17487/RFC2725, December 1999, 1122 . 1124 [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and 1125 D. Mitchell, "Considerations for Internet Routing 1126 Registries (IRRs) and Routing Policy Configuration", 1127 RFC 7682, DOI 10.17487/RFC7682, December 2015, 1128 . 1130 Authors' Addresses 1132 Stephen Kent 1133 BBN Technologies 1134 10 Moulton St 1135 Cambridge, MA 02138-1119 1136 USA 1138 EMail: kent@bbn.com 1140 Di Ma 1141 ZDNS 1142 4 South 4th St. 1143 Zhongguancun 1144 Haidian, Beijing 100190 1145 China 1147 EMail: madi@zdns.cn