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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual in sec area)
Last updated 2015-04-15 (latest revision 2014-12-29)
Replaces draft-housley-crypto-alg-agility
Stream IETF
Intended RFC status Best Current Practice
Formats plain text pdf html bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd No shepherd assigned
IESG IESG state AD is watching
Consensus Boilerplate Unknown
Telechat date
Responsible AD Stephen Farrell
Send notices to draft-iab-crypto-alg-agility@ietf.org, draft-iab-crypto-alg-agility.ad@ietf.org, housley@vigilsec.com, draft-iab-crypto-alg-agility.shepherd@ietf.org
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.
Show full document text