idnits 2.17.1 draft-kent-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 (May 20, 2015) is 3264 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-06 == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-10 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-11 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) == Outdated reference: A later version (-10) exists of draft-ietf-sidr-rpki-validation-reconsidered-01 == Outdated reference: A later version (-04) exists of draft-kent-sidr-suspenders-03 Summary: 2 errors (**), 0 flaws (~~), 6 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: November 21, 2015 ZDNS 6 May 20, 2015 8 Adverse Actions by a Certification Authority (CA) or Repository Manager 9 in the Resource Public Key Infrastructure (RPKI) 10 draft-kent-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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 21, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 4 59 2.1. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 8 62 2.4. Certificate Revocation List . . . . . . . . . . . . . . . 8 63 2.5. CA Certificates . . . . . . . . . . . . . . . . . . . . . 9 64 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 11 65 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 12 66 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4. Detection and Remediation . . . . . . . . . . . . . . . . . . 14 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 Both Suspenders [I-D.kent-sidr-suspenders] and RPKI Validation 82 Reconsidered [I-D.ietf-sidr-rpki-validation-reconsidered] address 83 mistaes by Resource Public Key Infrastructure (RPKI) [RFC6480] 84 Certification Authorities (CAs) (with respect to subordinate CAs). 85 However, mistakes are not the only way that adverse changes to RPKI 86 data can arise. A CA or repository operator might be subject to an 87 attack [RFC7132]. For a CA, if an attack allows an adversary to use 88 the private keys of that CA to sign RPKI objects, then the effect is 89 analogous to the CA making mistakes. There is also the possibility 90 that a CA or repository operator may be subject to legal measures 91 that compel actions that result in generating "bogus" signed objects 92 or removing legitimate repository data. In many cases, such actions 93 may be hard to distinguish from non-malicious mistakes, other than 94 with respect to the time required to remedy the adverse action. Thus 95 this document examines the implications of adverse actions with 96 respect to Internet Number Resources (INRs) irrespective of the cause 97 of the actions. The document proposes mitigation strategies that 98 take into account the nature of adverse actions, e.g., distinguishing 99 malicious vs. erroneous actions. 101 This document analyzes the various types of actions by a CA (or 102 independent repository manager) that can adversely affect the 103 Internet Number Resources (INRs) associated with that CA, as well as 104 the INRs of subordinate CAs. The analysis is based on examination of 105 the data items in the RPKI repository, as controlled by a CA (or 106 independent repository manager) and fetched by Relying Parties (RPs). 107 The analysis is done from the perspective of an affected INR holder. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Analysis of RPKI Repository Objects 117 This section enumerates the RPKI repository system objects and 118 examines how changes to them affect Route Origination Authorizations 119 (ROAs) and router certificate validation. Identifiers are assigned 120 to errors for reference by later sections of this document. 122 The RPKI repository [RFC6481] contains a number of (digitally signed) 123 objects that are fetched and processed by RPs. The principal goal of 124 the RPKI, until the deployment of BGPsec 125 [I-D.ietf-sidr-bgpsec-overview], is to enable an RP to validate ROAs 126 [RFC6482]. A ROA binds address space to an Autonomous System Number 127 (ASN). A ROA can be used to verify BGP announcements (with respect 128 to route origin) [RFC6483]. The most important objects in the RPKI 129 (for origin validation) are ROAs; all of the other RPKI objects exist 130 to enable the validation of ROAs in a fashion consistent with the INR 131 allocation system. Thus errors that result in changes to a ROA, or 132 to RPKI objects needed to validate a ROA, can cause RPs to reach 133 different conclusions about the validity of the bindings expressed in 134 a ROA. 136 When BGPsec is deployed, router certificates 137 [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository 138 publication points. These are End-Entity (EE) certificates used to 139 verify signatures applied to BGP update data, to enable path 140 validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are 141 as important to path validation as ROAs are to origin validation. 143 The objects contained in the RPKI repository are of two types: 144 conventional PKI objects (certificates and Certificate Revocation 145 Lists (CRLs)) and RPKI-specific signed objects. The latter make use 146 of a common encapsulation format [RFC6488] based on the Cryptographic 147 Message Syntax (CMS) [RFC5652]. A syntax error in this common format 148 will cause an RP to reject the object as invalid. In turn, this may 149 cause a ROA at a publication point to be considered invalid. 151 Adverse actions take several forms: 153 * Deletion (D) is defined as removing an object from a 154 publication point, without the permission of the INR holder. 156 * Suppression (S) is defined as not deleting an object, or not 157 publishing an object, as intended by an INR holder. This 158 action also includes retaining a prior version of an object in 159 a publication point when a newer version is available for 160 publication. 162 * Corruption (C) is defined as modification of a signed object in 163 a fashion not requiring access to the private key used to sign 164 the object. Thus a corrupted object will not carry a valid 165 signature. Implicitly, the corrupted object replaces the 166 legitimate version. 168 * Modification (M) is defined as publishing a version of an 169 object that differs from the version authorized by the INR 170 holder (but which is still syntactically valid). Implicitly, 171 the legitimate version of the affected object is deleted and 172 replaced by the modified object. The signature on the modified 173 object will be valid in the RPKI. 175 * Revocation (R) is defined as revoking a certificate (EE or CA) 176 by placing its serial number on the appropriate CRL, without 177 authorization of the INR holder. 179 * Injection (I) is defined as introducing an instance of a signed 180 object into a publication point. It assumes that the signature 181 on the object will be viewed as valid by RPs. 183 The first three of these actions (deletion, suppression, and 184 corruption) can be effected by any entity that manages the 185 publication point of the affected INR holder. (An entity with the 186 ability to act as a man-in-the-middle between an RP and a repository 187 also can effect these actions with respect to the RP in question.) 189 The latter three actions (modification, revocation, and injection) 190 nominally require access to the private key of the INR holder. 192 All six of these actions also can be effected by a parent CA. A 193 parent CA could reissue the INR holder's CA certificate, generate new 194 signed objects using the private key associated with the reissued 195 certificate, and publish these objects at a location of its choosing. 197 Most of these actions may be performed independently or in 198 combination with one another. For example, a ROA may be revoked and 199 deleted or revoked and replaced with a modified ROA. Where 200 appropriate, the analysis of adverse actions will distinguish which 201 of these individual actions, or combinations thereof, yield different 202 outcomes for RPs. Recall that the focus of the analysis is the 203 impact on ROAs and router certificates, with respect to RP 204 processing. 206 2.1. ROA 208 In addition to the generic RPKI object syntax checks, ROA validation 209 requires that the signature on the ROA can be validated using the 210 public key from the EE certificate embedded in the ROA [RFC6482]. It 211 also requires that the EE certificate be validated consistent with 212 the procedures described in [RFC6482] and [RFC6487]. Adverse actions 213 against a ROA can cause the following errors: 215 A-1.1 A ROA may be deleted from the indicated publication point. 217 A-1.2 A ROA may be revoked on the CRL for the publication point. 219 A-1.3 Publication of a newer ROA may be suppressed. 221 A-1.4 A ROA may be corrupted. 223 A-1.5 A valid ROA may be replaced with a corrupted ROA, which 224 will be rejected by RPs. 226 A-1.6 A ROA may be modified so that the Autonomous System Number 227 (ASN) or one or more of the address blocks in a ROA is 228 different than the values authorized by the INR holder. 229 (This action assumes that the modified ROA's ASN and 230 address ranges are authorized for use by the INR holder.) 232 A-1.7 If an INR holder intends to issue and publish two (or more) 233 new ROAs for the same address space, one (or more) of the 234 new ROAs may be suppressed while the other is published. 236 A-1.8 If an INR holder intends to delete all ROAs for the same 237 address space, some of them may be held while the others 238 are deleted. 240 2.2. Manifest 242 Each repository publication point contains a manifest [RFC6486]. The 243 RPKI incorporates manifests to enable RPs to detect suppression and/ 244 or substitution of (more recent) publication point objects, as the 245 result of a mistake or attack. A manifest enumerates (by filename) 246 all of the other signed objects at the publication point. The 247 manifest also contains a hash of each enumerated file, to enable an 248 RP to determine if the named file content matches what the INR holder 249 identified in the manifest. 251 A manifest is an RPKI signed object, so it is validated as per 252 [RFC6488]. If a manifest is modified in a way that causes any of 253 these checks to fail, the manifest will be considered invalid. 254 Suppression of a manifest itself (indicated by a stale manifest) also 255 can cause an RP to not detect suppression of other signed objects at 256 the publication point. However, RPs are not required to reject 257 publication point entries in the face of an invalid manifest. If a 258 signed object at a publication point can be validated (using the 259 rules applicable for that object type), then an RP MAY accept that 260 object, even if there is no matching entry for it on the manifest. 262 Corruption, suppression, modification, or deletion of a manifest 263 might not affect RP processing of other publication point objects, as 264 specified in [RFC6486]. However, many RP implementations ignore 265 objects that are present at a publication point but not listed in a 266 valid Manifest. Thus the following actions against can impact RP 267 processing: 269 A-2.1 A Manifest may be deleted from the indicated publication 270 point. 272 A-2.2 A Manifest may be revoked on the CRL for the publication 273 point. 275 A-2.3 Publication of a newer Manifest may be suppressed. 277 A-2.4 A Manifest may be corrupted. 279 A-2.5 A valid Manifest may be replaced with a corrupted Manifest, 280 which will be rejected by RPs. 282 A-2.6 A Manifest may be modified to remove one or more objects. 284 A-2.7 A Manifest may be modified to add one or more objects. 286 A-2.8 A Manifest may be modified to list an incorrect hash for 287 one or more objects. 289 2.3. Ghostbusters Record 291 The Ghostbusters record [RFC6493] is a signed object that MAY be 292 included at a publication point, at the discretion of the INR holder 293 or publication point operator. The record is validated according to 294 [RFC6488]. Additionally, the syntax of the record is verified based 295 on the vCard profile contained in [RFC6493]. Errors in this record 296 do not affect RP processing. However, if an RP encounters a problem 297 with objects at a publication point, the RP may use information from 298 the record to contact the publication point operator. 300 Adverse actions against a Ghostbusters record can cause the following 301 error: 303 A-3.1 Suppression, deletion, or corruption of a Ghostbusters 304 record could prevent an RP from contacting the appropriate 305 entity when a problem is detected by the RP. Modification 306 of a Ghostbusters record could cause an RP to contact the 307 wrong entity, thus delaying remediation of an detected 308 anomaly. All of these actions are viewed as equivalent 309 from an RP processing perspective; they do not alter RP 310 validation of ROAs or router certificates. However, these 311 actions can interfere with remediation of the action when 312 detected by an RP. 314 2.4. Certificate Revocation List 316 Each publication point contains a CRL that enumerates revoked (and 317 not yet expired) certificates issued by the CA associated with the 318 publication point [RFC6481]. 320 Adverse actions against a CRL can cause the following errors: 322 A-4.1 If a CRL is deleted, RPs will continue to use an older, 323 previously fetched Certificate Revocation List. As a 324 result, they will not be informed of any changes in 325 revocation status of subordinate CA or router certificates 326 or affected subordinate signed objects, e.g., ROAs or CA 327 certificates. This action is essentially equivalent to 328 corruption of a CRL, since a corrupted CRL will not be 329 accepted by an RP. 331 A-4.2 If publication of the most recent CRL is suppressed, an RP 332 will not be informed of the most recent revocation status 333 of subordinate CA or router certificates or affected 334 subordinate signed objects. If an EE certificate has been 335 revoked and the associated signed object is still present 336 in the publication point, an RP might mistakenly treat that 337 object as valid. (This would happen if the object is still 338 in the manifest or the RP is configured to process valid 339 objects that are not on the manifest.) This type of action 340 is of special concern if the affected object is a ROA, a 341 router certificate, or a subordinate CA certificate (since 342 suppression of revocation of any of these objects can have 343 a substantial impact on the RPKI). 345 A-4.3 If a CRL is modified to erroneously list a signed object's 346 EE certificate as revoked, the corresponding object will be 347 treated as invalid by RPs, even if it is present in a 348 publication point. If this object is a ROA, the 349 (legitimate) binding expressed by the ROA will be ignored 350 by an RP. If a CRL is modified to erroneously list a 351 router certificate as revoked, a path signature associated 352 with that certificate will likely be treated as invalid by 353 RPs. 355 A-4.4 If a CRL is modified to erroneously list a CA certificate 356 as revoked, that CA and all subordinate signed objects will 357 be treated as invalid by RPs. Because RPs acquire RPKI 358 data based on AIA and SIA extensions in CA certificates, 359 revocation of a CA certificate may cause RPs to not 360 retrieve all subordinate signed objects. Thus erroneous 361 revocation of a CA certificate may have significant 362 implications for RPs. 364 A-4.5 If a CRL is modified to omit a revoked EE, router, or CA 365 certificate, RPs may continue to accept the revoked, signed 366 object as valid. This contravenes the intent of the INR 367 holder. 369 2.5. CA Certificates 371 Every INR holder is represented by one or more CA certificates. An 372 INR holder has multiple CA certificates if it holds resources 373 acquired from different sources. Also, every INR holder has more 374 than one CA certificate during key rollover [RFC6489] and algorithm 375 rollover [RFC6916]. 377 If a publication point is not a leaf in the RPKI hierarchy, then the 378 publication point will contain one or more CA certificates, each 379 representing a subordinate CA. Each subordinate CA certificate 380 contains a pointer (SIA) to the publication point where the signed 381 objects associated with that CA can be found [RFC6487]. 383 A CA certificate is a complex data structure and thus errors in that 384 structure may have different implications for RPs depending on the 385 specific data that is in error. 387 Adverse actions against a CA certificate can cause the following 388 errors: 390 A-5.1 Revocation or deletion of a CA certificate would cause an 391 RP to not be able to locate signed objects generated by 392 that CA. Suppression of a CA certificate with a changed 393 SIA value would have an equivalent effect. Thus an RP 394 would be unaware of the INR bindings asserted in 395 subordinate ROAs, and the RP would be unable to validate 396 router certificates. 398 A-5.2 Corruption of a CA certificate will cause it to be rejected 399 by RPs. In turn, this will cause any subordinate signed 400 objects to become invalid. 402 A-5.3 If a CA certificate is modified, but still conforms to the 403 RPKI certificate profile [RFC6485], it will be accepted by 404 RPs. If an [RFC3779] extension in this certificate is 405 changed to exclude INRs that were previously present, then 406 subordinate signed objects will become invalid if they rely 407 on the excised INRs. If these objects are CA certificates, 408 their subordinate signed objects will be treated as 409 invalid. If the objects are ROAs, the binding expressed by 410 the affected ROAs will be ignored by RPs. If the objects 411 are router certificates, BGPsec_Path attributes 412 [I-D.ietf-sidr-bgpsec-protocol] verifiable under these 413 certificates will likely be considered invalid. 415 A-5.4 If the SIA extension of a CA certificate is modified to 416 refer to another publication point, this will cause an RP 417 to look at another location for subordinate objects. This 418 could cause RPs to not acquire the objects that the INR 419 holder intended to be retrieved. In turn, RPs would not be 420 able to acquire (much less validate) ROAs, router 421 certificates, or any subordinate CA certificates associated 422 with that CA. 424 A-5.5 If the AIA extension in a CA certificate is modified, it 425 would point to a different CA certificate, not the parent 426 CA certificate. This extension is used only for path 427 discovery, not path validation. Path discovery in the RPKI 428 is usually performed on a top-down basis, starting with TAs 429 and recursively descending the RPKI hierarchy. Thus there 430 may be no impact on the ability of clients to acquire and 431 validate certificates if the AIA is modified. 433 A-5.6 If the Subject Public Key Info (and Subject Key Identifier 434 extension) in a CA certificate is modified to contain a 435 public key corresponding to a private key held by the 436 parent, the parent could sign objects as children of the 437 affected CA certificate. 439 2.6. Router Certificates 441 Router certificates are used by RPs to verify signatures on 442 BGPsec_Path attributes carried in Update messages. 444 Each AS is free to determine the granularity at which router 445 certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each 446 participating AS is represented by one or more router certificates. 447 During key or algorithm rollover, multiple router certificates will 448 be present in a publication point, even if the AS is normally 449 represented by just one such certificate. 451 Adverse actions against router certificates can cause the following 452 errors: 454 A-6.1 Suppression, revocation, or deletion of a router 455 certificate would cause an RP to not be able to verify 456 signatures applied to BGPsec_Path attributes on behalf of 457 the AS in question. In turn, this would cause the route to 458 be treated with lower preference than competing routes that 459 have valid BGPsec_Path attribute signatures. (However, if 460 another router certificate for the affected ASN is valid 461 and contains the same AS number and public key, and is in 462 use by that AS, there would be no effect on routing. This 463 scenario will arise if a router certificate is renewed, 464 i.e., issued with a new validity interval.) Modification 465 of a router certificate that causes it to fail syntax 466 checks will result in the certificate being rejected by 467 RPs. Absent a valid router certificate, BGPsec_Path 468 attributes associated with that certificate will be 469 unverifiable. In turn, this would cause the route to be 470 treated with lower preference than competing routes that 471 have valid BGPsec_Path attribute signatures. 473 A-6.2 If a router certificate is modified to represent a 474 different ASN, but it still passes syntax checks, then this 475 action could cause signatures on BGPsec_Path attributes to 476 be associated with the wrong AS. This could cause signed 477 routes to be inconsistent with the intent of the INR 478 holder. 480 3. Analysis of Actions Relative to Scenarios 482 This section examines the types of problems that can arise in four 483 scenarios described below. We consider mistakes, (successful) 484 attacks against a CA or a publication point, and situations in which 485 a CA or publication point manager is compelled to take action by a 486 law enforcement authority. 488 We explore the following four scenarios: 490 A. An INR holder operates its own CA and manages its own 491 repository publication point. 493 B. An INR holder operates its own CA, but outsources management 494 of its repository publication point to its parent or another 495 entity. 497 C. An INR holder outsources management of its CA to its parent, 498 but manages its own repository publication point. 500 D. An INR holder outsources management of its CA and its 501 publication point to its parent. 503 Note that these scenarios focus on the affected INR holder as the 504 party directly affected by an adverse action. The most serious cases 505 arise when the INR holder appears as a high-tier CA in the RPKI 506 hierarchy; in such situations subordinate INR holders may be affected 507 as a result of an action. A mistake by or an attack against a "leaf" 508 has more limited impact because all of the affected INRs belong to 509 the INR holder itself. 511 In Scenario A, actions by the INR holder can adversely affect all of 512 its resources and, transitively, resources of any subordinate CAs. 513 (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs 514 and the damage is limited to its own INRs.) 516 In Scenario B, actions by the (outsourced) repository operator also 517 can adversely affect the resources of the INR holder, and those of 518 any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it 519 has no subordinate CAs and the damage is limited, as in Scenario A.) 520 The range of adverse effects here includes those in Scenario A, and 521 adds a new potential source of adverse actions, i.e., the outsourced 522 repository operator. 524 In Scenario C, all signed objects associated with the INR holder are 525 generated by the parent CA but are self-hosted. (We expect this 526 scenario to be rare, because an INR holder that elects to outsource 527 CA operation seems unlikely to manage its own repository publication 528 point.) Because that CA has the private key used to sign them, it 529 can generate alternative signed objects---ones not authorized by the 530 INR holder. However, erroneous objects created by the parent CA will 531 not be published by the INR holder IF the holder checks them first. 532 Because the parent CA is acting on behalf of the INR holder, mistakes 533 by or attacks against that entity are equivalent to ones effected by 534 the INR holder in Scenario A. 536 The INR holder is most vulnerable in Scenario D. Actions by the 537 parent CA, acting on behalf of the INR holder, can adversely affect 538 all signed objects associated with that INR holder, including any 539 subordinate CA certificates. These actions will presumably translate 540 directly into publication point changes, because the parent CA is 541 managing the publication point for the INR holder. The range of 542 adverse effects here includes those in Scenarios A, B, and C. 544 3.1. Scenario A 546 In this scenario, the INR holder acts as its own CA and it manages 547 its own publication point. Mistakes by the INR holder can cause any 548 of the actions noted in Section 2. A successful attack against this 549 CA can effect all of the modification, revocation, or injection 550 actions noted in that section. (We assume that objects generated by 551 the CA are automatically published). An attack against the 552 publication point can effect all of the deletion, suppression, or 553 corruption actions noted in that section. 555 3.2. Scenario B 557 In this scenario, the INR holder acts as its own CA and but it 558 outsources management of it own publication point. Mistakes by the 559 INR holder can cause any of the actions noted in Section 2. A 560 successful attack against its CA can effect all of the modification, 561 revocation, or injection actions noted in that section (assuming that 562 objects generated by the CA are automatically published). Here, 563 actions by the publication point manager (or attacks against that 564 entity) can effect all of the deletion, suppression, or corruption 565 actions noted in Section 2. 567 3.3. Scenario C 569 In this scenario, the INR holder outsources management of its CA to 570 its parent, but manages its own repository publication point. 571 Mistakes by the INR holder, acted upon by the parent CA, can cause 572 any of the actions noted in Section 2. Actions unilaterally 573 undertaken by the parent CA also can have the same effect, unless the 574 INR holder checks the signed objects before publishing them. A 575 successful attack against the parent CA can effect all of the 576 modification, revocation, or injection actions noted in Section 2. 577 An attack against the INR holder can effect all of the deletion, 578 suppression, or corruption actions noted in Section 2 (because the 579 INR holder is managing its publication point). (An attack against 580 the INR holder implies that the path it uses to direct the parent CA 581 to issue and publish objects has been compromised.) 583 3.4. Scenario D 585 In this scenario an INR holder outsources management of both its CA 586 and its publication point to its parent. Mistakes by the INR holder, 587 acted upon by the parent CA, can cause any of the actions noted in 588 Section 2. Actions unilaterally undertaken by the parent CA also can 589 have the same effect. A successful attack against the parent CA can 590 effect all of the modification, revocation, or injection actions 591 noted in Section 2. An attack against the parent CA can effect all 592 of the deletion, suppression, or corruption actions noted in 593 Section 2 (because the parent CA is managing the INR holder's 594 publication point). 596 4. Detection and Remediation 598 Each INR holder SHOULD check the signed objects available in its 599 publication point, to detect problems, on a regular basis. This 600 document RECOMMENDS that each INR holder perform such checks as a 601 side-effect of acquiring RPKI data for local processing, e.g., 3-4 602 times a day. Third parties also can perform checks in behalf of RPs, 603 to detect adverse actions. This is consistent with the outsourcing 604 options noted in the use cases in Section 1. In either situation, 605 detection of adverse actions requires that the cognizant party have 606 available a reference set of RPKI data for the INR holder. The 607 reference set includes all signed objects in the publication point(s) 608 of the INR holder plus the CA certificate for each publication point. 610 If an adverse action is the result of a mistake by, or an attack 611 against, a superior CA or a repository manager, the INR holder SHOULD 612 contact the relevant entity as soon as possible. It is expected that 613 a mistake by these entities normally will be corrected and new 614 objects published within 24-72 hours. An attack against a superior 615 CA or repository manager also should be remedied by the affected 616 parties, but the time to repair the damage may be longer, because of 617 the additional activities that may accompany responding to an attack. 619 In both of these situations, the harmful effects of adverse actions 620 can be mitigated if RPs delay acting on changes that might be 621 attributable to adverse actions. This observation motivates the 622 introduction of hysteresis into the RPKI validation process, at least 623 with respect to changes that are indicative of an adverse action. 624 The idea is that an RP would continue to accept as valid objects that 625 were previously valid (based on local cache history), and ignore 626 recent changes, for some interval. However, sometimes an INR holder 627 may wish to make a change that might be viewed as an adverse action, 628 without encountering such a delay. 630 To accommodate this situation, the RPKI can be extended to allow an 631 INR holder to provide independent confirmation of such changes. A 632 mechanism of this sort could prevent mistakes by a superior CA or 633 repository manager from having an immediate, adverse effect. If the 634 independent confirmation is not completely dependent on the RPKI 635 repository and CA system, it can be immune to mistakes by or attacks 636 against superior CAs and repository managers, and outsourced CA and 637 repository managers. 639 The effects of an attack on an INR holder itself may not be countered 640 by a mechanism of this sort; an adversary who can attack a CA and/or 641 repository management function of an INR holder may be able to attack 642 the independent confirmation mechanism at the same time. The use of 643 a separate mechanism does create the potential for additional 644 safeguards against such attacks. However, the extent to which this 645 potential is achieved will depend on how an INR holder implements and 646 manages this mechanism. 648 If a superior CA or repository manager is compelled to engage in an 649 adverse action against an INR holder, e.g., by a law enforcement 650 agency, use of an independent confirmation mechanism also may be able 651 to counter such an action. In this situation, the actions are not 652 likely to be reversed quickly, unlike a mistake or attack. This 653 situation might argue for a longer period of delay. An INR holder 654 and a subordinate INR holder may disagree about an action that 655 invalidates the holdings of the subordinate. The addition of 656 hysteresis and an independent confirmation mechanism to the RPKI 657 ought not deprive an INR holder of the legitimate ability to take 658 such actions. This argues for a time limit on the hysteresis and 659 confirmation mechanism, consistent with the business practices of 660 RPKI CAs. This time limit should be long enough to allow affected 661 entities to remedy mistakes and recover from attacks. It also should 662 be short enough to not impede the resolution of legitimate actions by 663 an INR holder relative to subordinate INR holders. 665 5. Security Considerations 667 This informational document describes a threat model for the RPKI, 668 focusing on mistakes by or attacks against CAs and independent 669 repository managers. It is intended to support the design of future 670 RPKI security mechanisms that seek to address the concerns associated 671 with such actions. 673 6. IANA Considerations 675 This document has no actions for IANA. 677 7. Acknowledgements 679 The authors would like to thank Richard Hansen and David Mandelberg 680 for their review feedback. The authors also thank Richard Hansen for 681 his editorial assistance. 683 8. References 685 8.1. Normative References 687 [I-D.ietf-sidr-bgpsec-overview] 688 Lepinski, M. and S. Turner, "An Overview of BGPsec", 689 draft-ietf-sidr-bgpsec-overview-06 (work in progress), 690 January 2015. 692 [I-D.ietf-sidr-bgpsec-pki-profiles] 693 Reynolds, M., Turner, S., and S. Kent, "A Profile for 694 BGPSEC Router Certificates, Certificate Revocation Lists, 695 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 696 profiles-10 (work in progress), January 2015. 698 [I-D.ietf-sidr-bgpsec-protocol] 699 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 700 sidr-bgpsec-protocol-11 (work in progress), January 2015. 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 706 Addresses and AS Identifiers", RFC 3779, June 2004. 708 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 709 RFC 5652, September 2009. 711 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 712 Secure Internet Routing", RFC 6480, February 2012. 714 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 715 Resource Certificate Repository Structure", RFC 6481, 716 February 2012. 718 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 719 Origin Authorizations (ROAs)", RFC 6482, February 2012. 721 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 722 Origination Using the Resource Certificate Public Key 723 Infrastructure (PKI) and Route Origin Authorizations 724 (ROAs)", RFC 6483, February 2012. 726 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 727 Use in the Resource Public Key Infrastructure (RPKI)", RFC 728 6485, February 2012. 730 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 731 "Manifests for the Resource Public Key Infrastructure 732 (RPKI)", RFC 6486, February 2012. 734 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 735 X.509 PKIX Resource Certificates", RFC 6487, February 736 2012. 738 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 739 Template for the Resource Public Key Infrastructure 740 (RPKI)", RFC 6488, February 2012. 742 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 743 Authority (CA) Key Rollover in the Resource Public Key 744 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 746 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 747 Ghostbusters Record", RFC 6493, February 2012. 749 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 750 Procedure for the Resource Public Key Infrastructure 751 (RPKI)", BCP 182, RFC 6916, April 2013. 753 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 754 RFC 7132, February 2014. 756 8.2. Informative References 758 [I-D.ietf-sidr-rpki-validation-reconsidered] 759 Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 760 Newton, A., and A. Aina, "RPKI Validation Reconsidered", 761 draft-ietf-sidr-rpki-validation-reconsidered-01 (work in 762 progress), January 2015. 764 [I-D.kent-sidr-suspenders] 765 Kent, S. and D. Mandelberg, "Suspenders: A Fail-safe 766 Mechanism for the RPKI", draft-kent-sidr-suspenders-03 767 (work in progress), April 2015. 769 Authors' Addresses 771 Stephen Kent 772 BBN Technologies 773 10 Moulton St 774 Cambridge, MA 02138-1119 775 USA 777 EMail: kent@bbn.com 779 Di Ma 780 ZDNS 781 4 South 4th St. 782 Zhongguancun 783 Haidian, Beijing 100190 784 China 786 EMail: madi@zdns.cn