SIDR S. Kent
Internet-Draft BBN
Intended status: Informational D. Ma
Expires: October 17, 2016 ZDNS
April 15, 2016

Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-adverse-actions-00

Abstract

This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is performed from the perspective of an affected INR holder. The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 17, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

In the context of this document, any change to the Resource Public Key Infrastructure (RPKI) [RFC6480] that results in a diminution of the set of Internet Numeric Resources (INRs) associated with an INR holder contrary to the holder's wishes is termed "adverse". Additionally, when a ROA or router certificate is created that "competes" with an existing ROA or router certificate (respectively), the creation of the new ROA or router certificate is considered adverse. (A newer ROA competes with an older ROA if the newer ROA points to a different ASN and contains the same or a more specific prefix. A newer router certificate competes with an older router certificate if the newer one contains the same ASN and a different public key.)

The SIDR WG is exploring proposals to address mistakes by RPKI Certification Authorities (CAs) and to accommodate INR transfers. Mistakes are not the only way that adverse changes to RPKI data can arise. A CA or repository operator might be subject to an attack [RFC7132]. For a CA, if an attack allows an adversary to use the private keys of that CA to sign RPKI objects, then the effect is analogous to the CA making mistakes. There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to generate "bogus" signed objects or remove legitimate repository data. In many cases, such actions may be hard to distinguish from non-malicious mistakes, other than with respect to the time required to remedy the adverse action. Thus this document examines the implications of adverse actions with respect to INRs irrespective of the cause of the actions. Standards for transfer of INRs are being explored in [I-D.ymbk-sidr-transfer]. That work also motivates exploration of the impact of both legitimate transfers and botched transfer attempts on the RPKI.

This document analyzes the various types of actions by a CA (or independent repository manager) that can adversely affect the INRs associated with that CA, as well as the INRs of subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is done from the perspective of an affected INR holder.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Analysis of RPKI Repository Objects

This section enumerates the RPKI repository system objects and examines how changes to them affect Route Origination Authorizations (ROAs) and router certificate validation. Identifiers are assigned to errors for reference by later sections of this document. Note that not all adverse actions may be addressed by this taxonomy.

The RPKI repository [RFC6481] contains a number of (digitally signed) objects that are fetched and processed by RPs. Until the deployment of BGPsec [I-D.ietf-sidr-bgpsec-overview], the principal goal of the RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds address space to an Autonomous System Number (ASN). A ROA can be used to verify BGP announcements with respect to route origin [RFC6483]. The most important objects in the RPKI for origin validation are ROAs; all of the other RPKI objects exist to enable the validation of ROAs in a fashion consistent with the INR allocation system. Thus errors that result in changes to a ROA, or to RPKI objects needed to validate a ROA, can cause RPs to reach different (from what was intended) conclusions about the validity of the bindings expressed in a ROA.

When BGPsec is deployed, router certificates [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository publication points. These are End-Entity (EE) certificates used to verify signatures applied to BGP update data, to enable path validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are as important to path validation as ROAs are to origin validation.

The objects contained in the RPKI repository are of two types: conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The latter make use of a common encapsulation format [RFC6488] based on the Cryptographic Message Syntax (CMS) [RFC5652]. A syntax error in this common format will cause an RP to reject the object, e.g., a ROA or Manifest, as invalid.

Adverse actions take several forms:

The first three of these actions (deletion, suppression, and corruption) can be effected by any entity that manages the publication point of the affected INR holder. Also, an entity with the ability to act as a man-in-the-middle between an RP and a repository can effect these actions with respect to the RP in question.

The latter three actions (modification, revocation, and injection) nominally require access to the private key of the INR holder.

All six of these actions also can be effected by a parent CA. A parent CA could reissue the INR holder's CA certificate, but with a different public key, matching a private key to which the parent CA has access. The CA could generate new signed objects using the private key associated with the reissued certificate, and publish these objects at a location of its choosing.

Most of these actions may be performed independently or in combination with one another. For example, a ROA may be revoked and deleted or revoked and replaced with a modified ROA. Where appropriate, the analysis of adverse actions will distinguish between individual actions, or combinations thereof, that yield different outcomes for RPs. Recall that the focus of the analysis is the impact on ROAs and router certificates, with respect to RP processing.

The following sections examine how the actions enumerated above affect objects in the RPKI repository system. Each action is addressed in order (Deletion, Suppression, Corruption, Modification, Revocation, and Injection) for each object, making it easy to see how each action has been considered with regard to each object. (For the GhostBusters record we condensed the discussion of the actions because the impact is the same in each case.)

2.1. ROA

In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistently with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors:

2.2. Manifest

Each repository publication point contains a manifest [RFC6486]. The RPKI incorporates manifests to enable RPs to detect suppression and/or substitution of (more recent) publication point objects, as the result of a mistake or attack. A manifest enumerates (by filename) all of the other signed objects at the publication point. The manifest also contains a hash of each enumerated file, to enable an RP to determine if the named file content matches what the INR holder identified in the manifest.

A manifest is an RPKI signed object, so it is validated as per [RFC6488]. If a manifest is modified in a way that causes any of these checks to fail, the manifest will be considered invalid. Suppression of a manifest itself (indicated by a stale manifest) also can cause an RP to not detect suppression of other signed objects at the publication point. (Note that if a Manifest's EE certificate expires at the time that the Manifest is scheduled to be replaced, a delay in publication will cause the Manifest to become invalid, not merely stale. This very serious outcome should be avoided, e.g., by making the Manifest EE certificate's notAfter value the same as that of the CA certificate under which it was issued). If a signed object at a publication point can be validated (using the rules applicable for that object type), then an RP MAY accept that object, even if there is no matching entry for it on the manifest. However, it appears that most RP software ignores publication point data that fails to match Manifest entries (at the time this document was written).

Corruption, suppression, modification, or deletion of a manifest might not affect RP processing of other publication point objects, as specified in [RFC6486]. However, as noted above, many RP implementations ignore objects that are present at a publication point but not listed in a valid Manifest. Thus the following actions against a manifest can impact RP processing:

2.3. Ghostbusters Record

The Ghostbusters record [RFC6493] is a signed object that MAY be included at a publication point, at the discretion of the INR holder or publication point operator. The record is validated according to [RFC6488]. Additionally, the syntax of the record is verified based on the vCard profile from Section 5 of [RFC6493]. Errors in this record do not affect RP processing. However, if an RP encounters a problem with objects at a publication point, the RP may use information from the record to contact the publication point operator.

Adverse actions against a Ghostbusters record can cause the following error:

2.4. Certificate Revocation List

Each publication point contains a CRL that enumerates revoked (not yet expired) certificates issued by the CA associated with the publication point [RFC6481].

Adverse actions against a CRL can cause the following errors:

2.5. CA Certificates

Every INR holder is represented by one or more CA certificates. An INR holder has multiple CA certificates if it holds resources acquired from different sources. Also, every INR holder has more than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916].

If a publication point is not a leaf in the RPKI hierarchy, then the publication point will contain one or more CA certificates, each representing a subordinate CA. Each subordinate CA certificate contains a pointer (SIA) to the publication point where the signed objects associated with that CA can be found [RFC6487].

A CA certificate is a complex data structure and thus errors in that structure may have different implications for RPs depending on the specific data that is in error.

Adverse actions against a CA certificate can cause the following errors:

2.6. Router Certificates

Router certificates are used by RPs to verify signatures on BGPsec_Path attributes carried in Update messages.

Each AS is free to determine the granularity at which router certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each participating AS is represented by one or more router certificates. During key or algorithm rollover, multiple router certificates will be present in a publication point, even if the AS is normally represented by just one such certificate.

Adverse actions against router certificates can cause the following errors:

3. Analysis of Actions Relative to Scenarios

This section examines the types of problems that can arise in four scenarios described below. We consider mistakes, (successful) attacks against a CA or a publication point, and situations in which a CA or publication point manager is compelled to take action by a law enforcement authority.

We explore the following four scenarios:

Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action. The most serious cases arise when the INR holder appears as a high-tier CA in the RPKI hierarchy; in such situations subordinate INR holders may be affected as a result of an action. A mistake by or an attack against a "leaf" has more limited impact because all of the affected INRs belong to the INR holder itself.

In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.)

In Scenario B, actions by the (outsourced) repository operator also can adversely affect the resources of the INR holder, and those of any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the outsourced repository operator.

In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects---ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A.

The INR holder is most vulnerable in Scenario D. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C.

3.1. Scenario A

In this scenario, the INR holder acts as its own CA and it manages its own publication point. Actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.) Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section. (We assume that objects generated by the CA are automatically published). An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section.

3.2. Scenario B

In this scenario, the INR holder acts as its own CA and but it delegates management of it own publication point to a third party. Mistakes by the INR holder can cause any of the modification, revocation, or injection actions described in Section 2. Actions by the repository operator can adversely affect the resources of the INR holder, and those of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the third party repository operator. A successful attack against the CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published). Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2.

3.3. Scenario C

In this scenario, the INR holder outsources management of its CA to its parent, but manages its own repository publication point. All signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect, unless the INR holder checks the signed objects before publishing them. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2, unless the INR holder checks the signed objects before publishing them. An attack against the INR holder (in its role as repository operator) can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the INR holder is managing its publication point), unless the INR holder checks the signed objects before publishing them. (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised.)

3.4. Scenario D

In this scenario an INR holder outsources management of both its CA and its publication point to its parent. The INR holder is most vulnerable in this scenario. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can also effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the parent CA is managing the INR holder's publication point).

4. Security Considerations

This informational document describes a threat model for the RPKI, focusing on mistakes by or attacks against CAs and independent repository managers. It is intended to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions.

The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors, in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the Routing Policy Specification Language (RPSL) [RFC2622]. IRR technology exhibits its own set of security problems, which are discussed in [RFC7682].

5. IANA Considerations

This document has no actions for IANA.

6. Acknowledgements

The authors thank Richard Hansen and David Mandelberg for their review, feedback and editorial assistance.

7. References

7.1. Normative References

[I-D.ietf-sidr-bgpsec-overview] Lepinski, M., "An Overview of BGPsec", Internet-Draft draft-ietf-sidr-bgpsec-overview-07, June 2015.
[I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M. and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", Internet-Draft draft-ietf-sidr-bgpsec-pki-profiles-16, March 2016.
[I-D.ietf-sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Internet-Draft draft-ietf-sidr-bgpsec-protocol-15, March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3779] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012.
[RFC6481] Huston, G., Loomans, R. and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012.
[RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, DOI 10.17487/RFC6485, February 2012.
[RFC6486] Austein, R., Huston, G., Kent, S. and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012.
[RFC6487] Huston, G., Michaelson, G. and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012.
[RFC6488] Lepinski, M., Chi, A. and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012.
[RFC6489] Huston, G., Michaelson, G. and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012.
[RFC6916] Gagliano, R., Kent, S. and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014.

7.2. Informative References

[I-D.ymbk-sidr-transfer] Austein, R., Bush, R., Huston, G. and G. Michaelson, "Resource Transfer in the Resource Public Key Infrastructure", Internet-Draft draft-ymbk-sidr-transfer-01, July 2015.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999.
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M. and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, DOI 10.17487/RFC2650, August 1999.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999.
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L. and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015.

Authors' Addresses

Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 USA EMail: kent@bbn.com
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China EMail: madi@zdns.cn