Network Working Group L. Vegoda Internet-Draft T. Manderson Intended status: Informational ICANN Expires: April 2, 2015 September 29, 2014 RPKI Key Management Issues draft-vegoda-manderson-sidr-key-management-00 Abstract 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. Status of This Memo 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 April 2, 2015. Copyright Notice 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. Vegoda & Manderson Expires April 2, 2015 [Page 1] Internet-Draft RPKI Key Management September 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Algorithm support . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Algorithm based on jurisdiction . . . . . . . . . . . . . 3 4.2. Algorithm vulnerability . . . . . . . . . . . . . . . . . 3 5. Key Length . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Key rollover support . . . . . . . . . . . . . . . . . . . . 4 6.1. Protocol support for key rollover events not requiring a change in cryptographic algorithm . . . . . . . . . . . . 4 7. Communication from validators to objects signers regarding validation status . . . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. 2. Terminology 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]. 3. Definitions 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. Vegoda & Manderson Expires April 2, 2015 [Page 2] Internet-Draft RPKI Key Management September 2014 4. Algorithm support 4.1. Algorithm based on jurisdiction [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. 4.2. Algorithm vulnerability 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. 5. Key Length 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. Vegoda & Manderson Expires April 2, 2015 [Page 3] Internet-Draft RPKI Key Management September 2014 6. Key rollover support 6.1. Protocol support for key rollover events not requiring a change in cryptographic algorithm 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. 7. Communication from validators to objects signers regarding validation status 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. 8. IANA Considerations This document does not define any IANA actions. This section may be removed by the RFC Editor prior to publication. Vegoda & Manderson Expires April 2, 2015 [Page 4] Internet-Draft RPKI Key Management September 2014 9. Security Considerations 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. 10. References [COMODO] Comodo CA, Ltd., "Comodo Certification Practices Statement, Section 2.1.1, v.4.0", July 2012, . [DIGICERT] DigiCert Inc., "DigiCert Certification Practices Statement, Section 6.3.2, v.4.0.6", May 2014, . [ENTRUST] Entrust Limited, "Entrust Certificate Services Certification Practice Statement, Appendix A, v.2.11", March 2014, . [NISTALGORITHMTESTING] National Institute of Standards and Technology, "Cryptographic Algorithm Validation Program", September 2014, . [NISTKEYMANAGEMENT] Barker, E., "NIST Special Publication 800-57, Recommendation for Key Management - Part 1: General (Revision 3)", July 2014, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Vegoda & Manderson Expires April 2, 2015 [Page 5] Internet-Draft RPKI Key Management September 2014 [RFC5830] Dolmatov, V., "GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms", RFC 5830, March 2010. [RFC5832] Dolmatov, V., "GOST R 34.10-2001: Digital Signature Algorithm", RFC 5832, March 2010. [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012. [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012. [SYMANTEC] Symantec Corporation, "Symantec Trust Network (STN) Certification Practice Statement v.3.8.1.6, Section 6.3.2", July 2014, . Appendix A. Acknowledgements 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. Authors' Addresses Leo Vegoda Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA Phone: +1 310 301 5800 Email: leo.vegoda@icann.org URI: http://www.icann.org/ Vegoda & Manderson Expires April 2, 2015 [Page 6] Internet-Draft RPKI Key Management September 2014 Terry Manderson Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA Phone: +1 310 301 5800 Email: terry.manderson@icann.org URI: http://www.icann.org/ Vegoda & Manderson Expires April 2, 2015 [Page 7]