Skip to main content

Guidelines for Cryptographic Key Management
draft-bellovin-mandate-keymgmt-03

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4107.
Authors Steven Bellovin , Russ Housley
Last updated 2015-10-14 (Latest revision 2005-01-11)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Best Current Practice
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4107 (Best Current Practice)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Sam Hartman
Send notices to smb@cs.columbia.edu
draft-bellovin-mandate-keymgmt-03
Network Working Group                                 Steven M. Bellovin
Internet Draft                                       Columbia University
January 2005                                             Russell Housley
Expires in six months                                     Vigil Security

              Guidelines for Cryptographic Key Management

                 draft-bellovin-mandate-keymgmt-03.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The question often arises of whether or not a given security system
   requires some form of automated key management, or whether manual
   keying is sufficient.  This memo proposes guidelines for making such
   decisions.  The presumption is that when symmetric cryptographic
   mechanisms are used in a protocol, then automated key management is
   generally but not always needed.  If manual keying is proposed, the
   burden of proving that automated key management is not required falls
   to the proposer.

Bellovin & Housley                                              [Page 1]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

1. Introduction

   The question often arises of whether or not a given security system
   requires some form of automated key management, or whether manual
   keying is sufficient.

   There is not one answer to that question; circumstances differ.  In
   general, automated key management SHOULD be used.  Occasionally,
   relying on manual key management is reasonable; we propose some
   guidelines for making that judgment.

   On the other hand, relying on manual key management has significant
   disadvantages, and we outline the security concerns that justify the
   preference for automated key management.  Yet, there are situations
   where manual key management is acceptable.

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 RFC 2119 [B].

2. Guidelines

   These guidelines are for use by IETF working groups and protocol
   authors who are determining whether to mandate automated key
   management and whether manual key management is acceptable.  Informed
   judgment is needed.

   The term "key management" is the establishment of cryptographic
   keying material for use with a cryptographic algorithm to provide
   protocol security services, especially integrity, authentication, and
   confidentiality. Automated key management derives one or more short-
   term session keys.  The key derivation function may make use of long-
   term keys to incorporate authentication into the process.  The manner
   in which this long-term key is distributed to the peers and the type
   of key used (pre-shared symmetric secret value, RSA public key, DSA
   public key, and others) is beyond the scope of this document.
   However, it is part of the overall key management solution.  Manual
   key management is used to distribute such values.  Manual key
   management can also be used to distribute long-term session keys.

   Automated key management and manual key management provide very
   different features.  In particular, the protocol associated with an
   automated key management technique will confirm liveness of the peer,
   protect against replay, authenticate the source of the short-term

Bellovin & Housley                                              [Page 2]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

   session key, associate protocol state information with the short-term
   session key, and ensure that a fresh short-term session key is
   generated.  Further, an automated key management protocol can improve
   interoperability by including negotiation mechanisms for
   cryptographic algorithms.  These valuable features are impossible or
   extremely cumbersome with manual key management.

   Implementations of some symmetric cryptographic algorithms are
   required to prevent the overuse of each key.  An implementation of
   such algorithms can make use of automated key management when the
   usage limits are nearly exhausted to establish replacement keys
   before the limits are reached, thereby maintaining secure
   communications.

   Examples of automated key management systems include IPsec IKE and
   Kerberos.  S/MIME and TLS also include automated key management
   functions.

   Key management schemes should not be designed by amateurs; it is
   almost certainly inappropriate for working groups to design their
   own.  To put it in concrete terms, the very first key management
   protocol in the open literature was published in 1978 [NS].  A flaw
   and a fix were published in 1981 [DS], and the fix was cracked in
   1994 [AN].  In 1995 [L], a new flaw was found in the original 1978
   version, in an area not affected by the 1981/1994 issue.  All of
   these flaws were blindingly obvious once described -- yet no one
   spotted them earlier.  Note that the original protocol (translated to
   employ certificates, which had not been invented at that time) was
   only three messages.

   Key management software is not always large or bloated; even IKEv1
   [HC] can be done in less than 200 Kbytes of object code, and TLS [DA]
   in half that space.  (Note that this TLS estimate includes other
   functionality as well.)

   A session key is used to protect a payload.  The nature of the
   payload depends on the layer where the symmetric cryptography is
   applied.

   In general, automated key management SHOULD be used to establish
   session keys.  This is a very strong "SHOULD", meaning the
   justification is needed in the security considerations section of a
   proposal that makes use of manual key management.

Bellovin & Housley                                              [Page 3]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

2.1. Automated Key Management

   Automated key management MUST be used if any of these conditions
   hold:

        A party will have to manage n^2 static keys, where n may become
        large.

        Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
        [WHF]) is used.

        An initialization vector (IV) might be reused, especially an
        implicit IV.  (Note that random or pseudo-random explicit IVs
        are not a problem unless the probability of repetition is high.)

        Large amounts of data might need to be encrypted in a short
        time, causing frequent change of the short-term session key.

        Long-term session keys are used by more than two parties.
        (Multicast is a necessary exception, but multicast key
        management standards are emerging so that this can be avoided in
        the future.  Sharing long-term session keys should generally be
        discouraged.)

        The likely operational environment is one where personnel (or
        device) turnover is frequent, causing frequent change of the
        short-term session key.

2.2. Manual Key Management

   Manual key management is a reasonable approach in any of these
   situations:

        The environment has very limited available bandwidth or very
        high round-trip times.  Public key systems tend to require long
        messages and lots of computation; symmetric key alternatives,
        such as Kerberos, often require several round trips and
        interaction with third parties.

        The information being protected has low value.

        The total volume of traffic over the entire lifetime of the
        long-term session key will be very low.

        The scale of each deployment is very limited.

   Note that assertions about such things should often be viewed with

Bellovin & Housley                                              [Page 4]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

   the skepticism.  The burden of demonstrating that manual key
   management is appropriate falls to the proponents -- and it is a
   fairly high hurdle.

   Systems that employ manual key management need provisions for key
   changes.  There MUST be some way to indicate which key is in use, to
   avoid problems during transition.  Designs SHOULD sketch plausible
   mechanisms for deploying new keys and replacing old ones, which might
   have been compromised.  If done well, such mechanisms can later be
   used by an add-on key management scheme.

   Lack of clarity about the parties involved in authentication is not a
   valid reason for avoiding key management.  Rather, it tends to
   indicate a deeper problem with the underlying security model.

2.3. Key Size and Random Values

   Guidance on cryptographic key size for public keys used for
   exchanging symmetric keys can be found in BCP 86 [OH].

   When manual key management is used, long-term shared secret values
   SHOULD be at least 128 bits.

   Guidance on random number generation can be found in RFC 1750 [ECS].

   When manual key management is used, long-term shared secrets MUST be
   unpredictable "random" values, ensuring that an adversary will have
   no greater expectation than 50% of finding the value after searching
   half the key search space.

3. Security Considerations

   This document provides guidance to working groups and protocol
   designers, and the security if the Internet is improved when
   automated key management is employed.

   The inclusion of automated key management does not mean that an
   interface for manual key management is prohibited.  In fact, manual
   key management is very helpful for debugging, so implementations
   ought to provide a manual key management interface for such purposes,
   even if they are not specified by the protocol.

Bellovin & Housley                                              [Page 5]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

4. IPR Considerations

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

5. References

   This section contains normative and informative references.

5.1. Normative Reference

   [B]         S. Bradner.  "Key words for use in RFCs to Indicate
               Requirement Levels."  RFC 2119, March 1997.

   [ECS]       D. Eastlake, 3rd, S. Crocker, and J. Schiller.
               "Randomness Recommendations for Security."  RFC 1750,
               December 1994.

   [OH]        H. Orman and P. Hoffman.  "Determining Strengths For
               Public Keys Used For Exchanging Symmetric Keys."  RFC
               3766, April 2004.

Bellovin & Housley                                              [Page 6]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

5.2. Informative References

   [AN]        M. Abadi and R. Needham, "Prudent Engineering Practice
               for Cryptographic Protocols", Proc. IEEE Computer Society
               Symposium on Research in Security and Privacy, May 1994.

   [DA]        T. Dierks and C. Allen.  "The TLS Protocol, Version 1.0."
               RFC 2246, January 1999.

   [DS]        D. Denning and G. Sacco.  "Timestamps in key distributed
               protocols", Communication of the ACM, 24(8):533--535,
               1981.

   [HC]        D. Harkins and D. Carrel.  "The Internet Key Exchange
               (IKE)."  RFC 2409, November 1998.

   [L]         G. Lowe.  "An attack on the Needham-Schroeder public key
               authentication protocol", Information Processing Letters,
               56(3):131--136, November 1995.

   [NIST]      National Institute of Standards and Technology.
               "Recommendation for Block Cipher Modes of Operation --
               Methods and Techniques," NIST Special Publication SP
               800-38A, December 2001.

   [NS]        R. Needham and M. Schroeder. "Using encryption for
               authentication in large networks of computers",
               Communications of the ACM, 21(12), December 1978.

   [TK]        Thayer, R. and K. Kaukonen.  "A Stream Cipher Encryption
               Algorithm," Work in Progress.

   [WHF]       D. Whiting, R. Housley, and N. Ferguson.  "Counter with
               CBC-MAC (CCM)."  RFC 3610, September 2003.

Bellovin & Housley                                              [Page 7]
Internet Draft    draft-bellovin-mandate-keymgmt-03.txt     January 2005

6. Authors' Addresses

   Steven M. Bellovin
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, M.C. 0401
   New York, NY 10027-7003
   Phone: +1 212-939-7149
   Email: bellovin@acm.org

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   Phone: +1 703-435-1775
   Email: housley@vigilsec.com

7. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Bellovin & Housley                                              [Page 8]