Internet-Draft                                                R. Housley
Intended Status: Best Current Practice                    Vigil Security
Expires: 8 July 2014                                      8 January 2014


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

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              January 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 may use of cryptographic algorithms to provide
   confidentiality, integrity, or non-repudiation.  For the mechanisms
   to work properly,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 performance improves, the work factor to
   break a particular cryptographic algorithm will reduce.  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.  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.
   Either approach is acceptable; however, designers are encouraged to
   pick one of these approaches and use it consistently throughout the
   protocol.




Housley                                                         [Page 2]


Guidelines for Cryptographic Algorithm Agility              January 2014


   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 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 allows many different key sizes.  When more than one
   key size is available, the algorithm specification MUST identify the
   specific sizes that are to be supported.

   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
   implementation and deployment of the alternative algorithm is
   imperfect, so one cannot be completely assured of interoperability
   with alternative algorithm.

   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 happen 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 refuse to use the weak



Housley                                                         [Page 3]


Guidelines for Cryptographic Algorithm Agility              January 2014


   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 Considerations

   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 necessary to handle the transition to from unprotected to
   protected use of the the application layer protocol.

3.2.  Migration Mechanisms

   When a protocol specifies a single mandatory-to-implement algorithm



Housley                                                         [Page 4]


Guidelines for Cryptographic Algorithm Agility              January 2014


   for integrity and authentication, eventually that algorithm will be
   found to be weak.  Perhaps there will be a flaw found in the
   algorithm that greatly shortens its expected life.  Regardless, 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.

   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.

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.

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

5.  References

   This section contains normative and informative references.




Housley                                                         [Page 5]


Guidelines for Cryptographic Algorithm Agility              January 2014


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

5.2.  Informative References

   [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 and Eliot Lear for their review and
   insightful comments.

Authors' Addresses

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




















Housley                                                         [Page 6]