| Network Working Group | L. Vegoda |
| Internet-Draft | T. Manderson |
| Intended status: Informational | ICANN |
| Expires: March 5, 2015 | September 2014 |
RPKI Key Management Issues
draft-vegoda-manderson-sidr-key-management-00
Strong key management is central to the security of any hierarchy of cryptographic certificates. Well-defined architectural objectives will be important guides to the detailed design work needed to support the deployment of a Global Trust Anchor for the RPKI. This document identifies some of the questions that need to be addressed in the architectural guidelines for key management.
This Internet-Draft is submitted to IETF 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 March 5, 2015.
Copyright (c) 2014 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.
Strong key management is central to the security of any hierarchy of cryptographic certificates [NISTKEYMANAGEMENT]. The deployment of a Global Trust Anchor for the RPKI requires a set of well-defined architectural objectives to guide the detailed design work. This document identifies some of the questions that need to be addressed in the architectural guidelines for key management.
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for X.509 PKIX Resource Certificates" [RFC6487], and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
The Global Trust Anchor (GTA) is the root of the Internet’s RPKI hierarchy and is responsible for issuing subordinate certificates for resources within 0/0 (IPv4), 0::/0 (IPv6), and Autonomous System Numbers 0-4294967295.
[RFC6485] requires that RPKI signatures use a SHA-256 hashing algorithm and 2048-bit RSA keys. Some jurisdictions have legal impediments to implementing this requirement [RFC5830] [RFC5832], resulting in a need to use other cryptographic algorithms. To support RPKI CAs in all jurisdictions, there is therefore a need to allow the use of algorithms other than RSA and SHA-256, and so validators will need to support these algorithms if they are going to successfully validate objects signed with a certificate using a signature algorithm other than RSA with a SHA-256 hash.
Advice is sought on how jurisdictional requirements can be addressed in the set of supported algorithms.
Published cryptographic algorithms are constantly tested [NISTALGORITHMTESTING]. There is a potential that the RSA algorithm will be found vulnerable to one or more attacks during the lifetime of an RPKI GTA that uses the algorithm. In order to mitigate this risk it is necessary to require support for additional public-key cryptographic algorithms in the RPKI so that the operator can roll the GTA to one using a different algorithm.
Advice is sought on how a production GTA can roll the algorithms it uses in the event of an effective attack on the RSA algorithm becoming available during the production lifetime of the GTA.
The US National Institute of Standards and Technology recommends [NISTKEYMANAGEMENT] that 2048-bit RSA keys, as required in [RFC6485], should not be used after 2030. It is common for an X.509 trust anchor to have a 15 year or longer lifetime [COMODO] [DIGICERT] [ENTRUST] [SYMANTEC]. If an RPKI GTA uses a standard lifetime it needs to use a key that is longer than 2048 bits. Alternatively, the key needs to be rolled prior to 2030 and the protocol must be updated to support keys that are judged to be safe to use after that date. If the key rollover and protocol update is selected, the lead time needs to be sufficient to make sure that the entire deployed base is upgraded to support the new algorithm of key length.
Advice is sought on whether the GTA should use a shorter lifetime than is typical in X.509 TAs or use a keylength that is considered safe beyond 2030.
Key rollover events must be communicated to subordinate CAs so that they know to reissue certificates and entities holding certificates, so that they know to re-sign objects. Key rollover events must also be communicated to validators so that they know to validate against a new certificate.
No mechanism has yet been defined for communicating key rollovers. This could either be performed with in-protocol signaling or via an out-of-band mechanism using domain specific businesses processes. Whichever option is selected needs to be sufficiently robust to allow for all involved parties to reissue certificates, or re-sign objects, or just configure a new key, expeditiously.
Advice is sought on whether in-protocol signaling should be developed or an out-of-band set of domain specific business processes should be used.
No mechanism has yet been defined to allow validators to tell a certificate issuer or object signer that a certificate it issued or object it signed has failed validation. In an inter-domain routing context this means that validation failure might only be communicated via a routing failure when local policy is configured to drop a route if validation fails.
This lack of validation status signaling could have catastrophic consequences if a problem occurs in a certificate or object near the top of the hierarchy. Such a failure in validation could impact a significant percentage of the Internet’s routing capability without providing adequate tools for diagnosis and remediation.
Advice is sought on whether it is important for validators to be able to signal validation failures to certificate issuers and signers.
This document does not define any IANA actions. This section may be removed by the RFC Editor prior to publication.
The RPKI needs to support better security in inter-domain routing. The security improvements should be partnered with improvements to the overall robustness and resilience of the inter-domain routing system. Until the issues described in this document are addressed the fragility of the system means that it is not safe to deploy in production environments and must remain merely of academic interest.
Geoff Huston, George Michaelson, Andrew de la Haye, and Tim Bruijnzeels, Richard Barnes, and Alia Atlas helped clarify some of the questions in this document. Thanks to Kim Davies, Tomofumi Okubo, and Elise Gerich for early reviews of this document.