Guidelines for Cryptographic Algorithm Agility
draft-iab-crypto-alg-agility-02

Internet-Draft                                                R. Housley
Intended Status: Best Current Practice                    Vigil Security
Expires: 2 July 2015                                    29 December 2014

              Guidelines for Cryptographic Algorithm Agility
                   <draft-iab-crypto-alg-agility-02.txt>

Abstract

   Many IETF protocols use cryptographic algorithms to provide
   confidentiality, integrity, or non-repudiation.  Communicating peers
   must support the same set of cryptographic algorithms for these
   mechanisms to work properly.  This memo provides guidelines to ensure
   that protocols have the ability to migrate from one algorithm suite
   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             December 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 set
   of cryptographic algorithms.  In most cases, a combination of
   compatible cryptographic algorithms will be used to provide the
   desired security services.  The set of cryptographic algorithms being
   used at a particular time is often referred to as a cryptographic
   algorithm suite.

   Cryptographic algorithms age; they 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 cryptographic algorithm suite, which
   ensures that protocols can migrate from one algorithm suite to
   another over time.  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

Housley                                                         [Page 2]
Guidelines for Cryptographic Algorithm Agility             December 2014

   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
   it easier for the protocol designer to ensure that the algorithm
   selections are complete and compatible for future assignments.

   Regardless of the approach used, protocols MUST NOT negotiate
   symmetric ciphers and cipher modes separately.

   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
   cryptographic algorithm suite.  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 needs to 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 standards
   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 and 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 asymmetric keys can be found
   in BCP 86 [RFC3766].

Housley                                                         [Page 3]
Guidelines for Cryptographic Algorithm Agility             December 2014

   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
   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.  Sadly, 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 using the weak algorithm
   altogether, rejecting offers to use the weak algorithm well before
   the alternative algorithm is widely deployed.

   In any case, there comes a point in time 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 128-bit AES key and the content-
   encryption key is wrapped with a 256-bit AES key, then at most 128
   bits of protection is provided.  In this situation, the algorithm and
   key size selections should ensure that the key encryption is at least
   as strong as the content encryption.  In general, wrapping one key
   with another key of a different size yields the security strength of
   the shorter key.

Housley                                                         [Page 4]
Guidelines for Cryptographic Algorithm Agility             December 2014

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.

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
   traffic to protected traffic in the application layer protocol.

3.2.  Migration Mechanisms

   Cryptographic algorithm selection or negotiation SHOULD be integrity
   protected.  If selection is not integrity-protected, then the
   protocol will be subject to a downgrade attack.  Without integrity
   protection of algorithm selection, transition to a new cryptographic
   algorithm suite will not be smooth.

   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.  In this situation, a flaw in the
   mandatory-to-implement algorithm may allow an attacker to influence
   the choices of the other algorithms.

   Performance is always a factor is selecting cryptographic algorithms.
   In many algorithms, shorter keys offer higher performance, but less
   security.  Performance and security need to be balanced.  Yet, 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 suite to
   another over time, not just the integrity algorithm, but all
   cryptographic algorithms.

Housley                                                         [Page 5]
Guidelines for Cryptographic Algorithm Agility             December 2014

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.

   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
   alternatives 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.

Housley                                                         [Page 6]
Guidelines for Cryptographic Algorithm Agility             December 2014

   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.

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.

Housley                                                         [Page 7]
Guidelines for Cryptographic Algorithm Agility             December 2014

Acknowledgements

   Thanks to Bernard Aboba, David Black, Jon Callas, Tony Finch, Ian
   Grigg, Wes Hardaker, Joe Hildebrand, Christian Huitema, Paul Lambert,
   Ben Laurie, Eliot Lear, Kristof Teichel, and Nico Williams 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.

Author's Address

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: housley@vigilsec.com

Housley                                                         [Page 8]