Internet-Draft R. Housley Intended Status: Best Current Practice Vigil Security Expires: 29 December 2014 27 June 2014 Guidelines for Cryptographic Algorithm Agility Abstract Many IETF protocols may use of cryptographic algorithms to provide confidentiality, integrity, or non-repudiation. Communicating peers must support the same cryptographic algorithm or algorithms for these mechanisms to work properly. This memo provides guidelines for ensuring that such a protocol has the ability to migrate from one algorithm to another over time. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Housley [Page 1] Guidelines for Cryptographic Algorithm Agility June 2014 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. 1. Introduction Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. For interoperability, communicating peers must support the same cryptographic algorithm or algorithms. Yet, cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing capabilities improve, the work factor to break a particular cryptographic algorithm will reduce. Algorithm agility is achieved when a protocol can easily support more that one set of cryptographic algorithms. For the protocol implementer, this means that implementations should be modular to easily accommodate the insertion of new algorithms. For the protocol designer, this means that one or more algorithm identifier must be carried, the set of mandatory-to-implement algorithms will change over time, and an IANA registry of algorithm identifiers will be needed. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2. Algorithm Agility Guidelines These guidelines are for use by IETF working groups and protocol authors for IETF protocols that make use of cryptographic algorithms. 2.1. Algorithm Identifiers IETF protocols that make use of cryptographic algorithms MUST carry one or more algorithm identifier. Some approaches carry one identifier for each algorithm that is used. Other approaches carry one identifier for a suite of algorithms. Both approaches are used in IETF protocols. Designers are encouraged to pick one of these approaches and use it consistently throughout the protocol or family of protocols. However, suite identifiers make Housley [Page 2] Guidelines for Cryptographic Algorithm Agility June 2014 it easier for the protocol designer to ensure that the algorithm selections are complete and compatible for future assignments. In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such separation is completely fine design choice. An IANA registry SHOULD be used for these algorithm identifiers. 2.2. Mandatory-to-Implement Algorithms For interoperability, communicating peers must support the same cryptographic algorithm or algorithms. For this reason, the protocol SHOULD specify one or more mandatory-to-implement algorithm. This is not done for protocols that are embedded in other protocols. For example, S/MIME [RFC5751] makes use of the cryptographic message Syntax (CMS) [RFC5652]. Other protocols also make use of CMS. S/MIME specifies the mandatory-to-implement algorithms, not CMS. The IETF must be able to change the mandatory-to-implement algorithms over time. It is highly desirable to make this change without updating the base protocol specification. Therefore the base protocol specification SHOULD reference a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other. This division also facilitates the advancement of the base protocol specification on the maturity ladder even if the algorithm document changes frequently. Some cryptographic algorithms are inherently tied to a specific key size, but others allow many different key sizes. Likewise, some algorithms support parameters of different sizes, such as integrity check values or nonces. The algorithm specification MUST identify the specific key sizes ans parameter sizes that are to be supported. When more than one key size is available, expect the mandatory-to- implement key size to increase over time. Guidance on cryptographic key size for public keys can be found in BCP 86 [RFC3766]. Symmetric keys used for protection of long-term values SHOULD be at least 128 bits. 2.3. Transition from Weak Algorithms Transition from an algorithm that is found to be weak can be tricky. It is straightforward to specify an alternative algorithm. When the alternative algorithm is widely deployed, then the weak algorithm should no longer be used. However, knowledge about the Housley [Page 3] Guidelines for Cryptographic Algorithm Agility June 2014 implementation and deployment of the alternative algorithm is imperfect, so one cannot be completely assured of interoperability with alternative algorithm. To facilitate transition, protocols MUST be able to advertise which algorithms are supported. This may naturally occur as part of an algorithm selection or negotiation mechanism. In the worst case, the algorithm may be found to be tragically flawed, permitting a casual attacker to download a simple script to break it. This has happened when a secure algorithm is used incorrectly or used with poor key management. In such situations, the protection offered by the algorithm is severely compromised, perhaps to the point that one wants to stop offering to use the weak algorithm and refuse offers to use the weak algorithm well before the alternative algorithm is widely deployed. In any case, there come a point where one refuses to use the weak algorithm. This can happen on a flag day, or each installation can select a date on their own. 2.4. Balance Security Strength When selecting a suite of cryptographic algorithms, the strength of each algorithm MUST be considered. In CMS [RFC5652], a previously distributed symmetric key-encryption key can be used to encrypt a content-encryption key, which is in turn used to encrypt the content. The key-encryption and content- encryption algorithms are often different. If, for example, a message content is encrypted with 168-bit Triple-DES key and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. Thus, a trivial search to determine the value of the 40-bit RC2 key will recover Triple-DES key, and then the recovered Triple-DES key can be used to decrypt the content. In this situation, the algorithm and key size selections should ensure that the key encryption is at least as strong as the content encryption. 3. Algorithm Agility in Protocol Design Some attempts at algorithm agility have not been completely successful. This section provides some of the insights based on protocol designs and deployments. Housley [Page 4] Guidelines for Cryptographic Algorithm Agility June 2014 3.1. Algorithm Identifiers If a protocol does not carry an algorithm identifier, then the protocol version number or some other major change is needed to transition from one algorithm to another. The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility. In addition, an IANA registry is needed to pair the identifier with an algorithm specification. Sometimes application layer protocols can make use of transport layer security protocols, such as TLS or DTLS. This insulates the application layer protocol from the cryptography altogether, but it may still be necessary to handle the transition from unprotected to protected use of the the application layer protocol. 3.2. Migration Mechanisms Cryptographic algorithm selection or negotiation MUST be integrity protected. When a protocol specifies a single mandatory-to-implement integrity algorithm, eventually that algorithm will be found to be weak. Perhaps there will be a flaw found in the integrity algorithm that greatly shortens its expected life. Extra care is needed when a mandatory-to-implement algorithm is used to provide integrity protection for the negotiation of other cryptographic algorithms used by the protocol. In this situation, a flaw in the mandatory-to-implement algorithm may allow an attacker to influence the choices of other algorithms. All algorithms age, and the advances in computing power available to the attacker will eventually make them obsolete. For this reason, protocols need mechanisms to migrate from one algorithm to another over time, not just the integrity algorithm, but all cryptographic algorithms used by the protocol. 3.3. Cryptographic Key Management Traditionally, protocol designers have avoided a more than one approach to key management because it makes the security analysis of the overall protocol more difficult. However, with the increasing deployment of frameworks such as EAP and GSSAPI, the key management is very flexible, often hiding many of the details from the application. As a result, more and more protocols support multiple key management approaches. In fact, the key management approach may be negotiable, which creates a design challenge to protect the negotiation of the key management approach before it is used to produce cryptographic keys for the cryptographic algorithm. Housley [Page 5] Guidelines for Cryptographic Algorithm Agility June 2014 Protocols can negotiate a key management approach, derive an initial cryptographic key, and then authenticate the negotiation. However, if the authentication fails, the only recourse is to start the negotiation over from the beginning. Some environments will restrict the key management approaches by policy. Such policies tend to improve interoperability within a particular environment, but they cause problems for individuals that need to work in multiple incompatible environments. 4. Security Considerations This document provides guidance to working groups and protocol designers. The security of the Internet is improved when broken or weak cryptographic algorithms can be easily replaced with strong ones. The ability to use a algorithm of one's own choosing is very desirable; however, this does not mean that any and all cryptographic algorithms ought to be available in every implementation. Mandatory- to-implement algorithms ought to be well studied, giving rise to significant confidence. In addition, inclusion of too many alternative may add complexity to algorithm selection or negotiation. Some protocols are used to protected stored data. For example, S/MIME [RFC5751] can protect a message kept in a mailbox. To recover the protected stored data, protocol implementations need to support older algorithms, even when they no longer use the older algorithms for the protection of new stored data. Support for too many algorithms can lead to implementation vulnerabilities. When many algorithms are supported, some of them will be rarely used. Any code that is rarely used can contain undetected bugs, and algorithm implementations are no different. Section 2.3 talks about algorithm transition without considering any other aspects of the protocol design. In practice, there are dependencies between the cryptographic algorithm and other aspects of the protocol. For example, the BEAST attack [BEAST] against TLS [RFC5246] caused many sites to turn off modern cryptographic algorithms in favor of older and clearly weaker algorithms. Housley [Page 6] Guidelines for Cryptographic Algorithm Agility June 2014 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. 6. Informative References [BEAST] http://en.wikipedia.org/wiki/ Transport_Layer_Security#BEAST_attack. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. Acknowledgements Thanks to Bernard Aboba, David Black, Tony Finch, Ian Grigg, Wes Hardaker, Joe Hildebrand, Paul Lambert, Ben Laurie, Eliot Lear, and Kristof Teichel for their review and insightful comments. While some of these people do not agree with some aspects of this document, the discussion that resulted for their comments has certainly resulted in a better document. Housley [Page 7] Guidelines for Cryptographic Algorithm Agility June 2014 Author's Address Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Housley [Page 8]