The RFC Archive
 The RFC Archive   RFC 6649   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 6649



Last modified on Tuesday, July 3rd, 2012

Permanent link to RFC 6649
Search GitHub Wiki for RFC 6649
Show other RFCs mentioning RFC 6649







Internet Engineering Task Force (IETF)              L. Hornquist Astrand
Request for Comments: 6649                                   Apple, Inc.
BCP: 179                                                           T. Yu
Obsoletes: 1510                                  MIT Kerberos Consortium
Updates: 1964, 4120, 4121, 4757                                July 2012
Category: Best Current Practice 
ISSN: 2070-1721


  Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms
                              in Kerberos

 Abstract

   The Kerberos 5 network authentication protocol, originally specified
   in RFC 1510, can use the Data Encryption Standard (DES) for
   encryption.  Almost 30 years after first publishing DES, the National
   Institute of Standards and Technology (NIST) finally withdrew the
   standard in 2005, reflecting a long-established consensus that DES is
   insufficiently secure.  By 2008, commercial hardware costing less
   than USD 15,000 could break DES keys in less than a day on average.
   DES is long past its sell-by date.  Accordingly, this document
   updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the
   use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in
   Kerberos.  Because RFC 1510 (obsoleted by RFC 4120) supports only
   DES, this document recommends the reclassification of RFC 1510 as
   Historic.

 Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/RFC 6649.










Hornquist Astrand & Yu    Best Current Practice              PAGE 1 top


RFC 6649 Deprecate DES in Kerberos July 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Hornquist Astrand & Yu Best Current Practice PAGE 2 top

RFC 6649 Deprecate DES in Kerberos July 2012 1. Introduction The original specification of the Kerberos 5 network authentication protocol [RFC 1510] supports only the Data Encryption Standard (DES) for encryption. For many years, the cryptographic community has regarded DES as providing inadequate security, mostly because of its small key size. Accordingly, this document recommends the reclassification of [RFC 1510] (obsoleted by [RFC 4120]) as Historic and updates current Kerberos-related specifications [RFC 1964], [RFC 4120], and [RFC 4121] to deprecate the use of DES and other weak cryptographic algorithms in Kerberos, including some unkeyed checksums and hashes, along with the weak 56-bit "export strength" RC4 variant encryption type of [RFC 4757]. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 3. Affected Specifications The original IETF specification of Kerberos 5 [RFC 1510] only supports DES for encryption. [RFC 4120] obsoletes [RFC 1510] and updates the Kerberos specification to include additional cryptographic algorithms, but still permits the use of DES. [RFC 3961] describes the Kerberos cryptographic system and includes support for DES encryption types, but it does not specify requirement levels for them. The specification of the Kerberos Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC 1964] and its updated version [RFC 4121] define checksum and encryption mechanisms based on DES. With the existence of newer encryption types for Kerberos GSS-API defined in [RFC 4121], Microsoft's RC4-HMAC-based GSS-API mechanism, and MIT's DES3 (which is not published as an RFC), there is no need to support the old DES-based integrity (SGN) and confidentiality (SEAL) types. [RFC 4757] describes the RC4-HMAC encryption types used by Microsoft Windows and allows for a 56-bit "export strength" variant. (The character constant "fortybits" used in the definition is a historical reference and does not refer to the actual key size of the encryption type.) Hornquist Astrand & Yu Best Current Practice PAGE 3 top

RFC 6649 Deprecate DES in Kerberos July 2012 4. DES Insecurity The insecurity of DES has been evident for many years. Even around the time of its first publication, cryptographers raised the possibility that 56 bits was too small a key size for DES. The National Institute of Standards and Technology (NIST) officially withdrew DES in 2005 [DES-Withdrawal], and also announced a transition period that ended on May 19, 2007 [DES-Transition-Plan]. The IETF has also published its position in [RFC 4772], in which the recommendation summary is very clear: "don't use DES". In 2006, researchers demonstrated the ability to find a DES key via brute-force search in an average of less than 9 days using less than EUR 10,000 worth of hardware [Break-DES]. By 2008, a company was offering hardware capable of breaking a DES key in less than a day on average [DES-1day] that cost less than USD 15,000 [DES-Crack]. Brute-force key searches of DES will only get faster and cheaper. (The aforementioned company markets its device for one-click recovery of lost DES keys.) It is clear that it is well past time to retire the use of DES in Kerberos. 5. Recommendations This document hereby removes the following RECOMMENDED types from [RFC 4120]: Encryption: DES-CBC-MD5(3) Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC 3961]). Kerberos implementations and deployments SHOULD NOT implement or deploy the following single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC-MD5(3) (updates [RFC 4120]). Kerberos implementations and deployments SHOULD NOT implement or deploy the following "export strength" RC4 variant encryption type: RC4-HMAC-EXP(24) (updates [RFC 4757]). This document does not add any sort of requirement for conforming implementations to implement RC4-HMAC(23). Kerberos implementations and deployments SHOULD NOT implement or deploy the following checksum types: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8) (updates [RFC 4120]). It is possible to safely use the RSA-MD5(7) checksum type, but only with additional protection, such as the protection that an encrypted Authenticator provides. Implementations MAY use RSA-MD5 inside an Hornquist Astrand & Yu Best Current Practice PAGE 4 top

RFC 6649 Deprecate DES in Kerberos July 2012 encrypted Authenticator for backward compatibility with systems that do not support newer checksum types (updates [RFC 4120]). One example is that some legacy systems only support RC4-HMAC(23) [RFC 4757] for encryption when DES is not available; these systems use RSA-MD5 checksums inside Authenticators encrypted with RC4-HMAC. Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES MAC(0200) (updates [RFC 1964]). Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SEAL ALG: DES(0000) (updates [RFC 1964]). The effect of the two last sentences is that this document deprecates Section 1.2 of [RFC 1964]. This document hereby recommends the reclassification of [RFC 1510] as Historic. 6. Security Considerations Removing support for single DES improves security because DES is considered to be insecure. RC4-HMAC-EXP has a similarly inadequate key size, so removing support for it also improves security. Kerberos defines some encryption types that are either underspecified or that only have number assignments but no specifications. Implementations should make sure that they only implement and enable secure encryption types. The security considerations of [RFC 4757] continue to apply to RC4-HMAC, including the known weaknesses of RC4 and MD4, and this document does not change the Informational status of [RFC 4757] for now. The main reason to not actively discourage the use of RC4-HMAC is that it is the only encryption type that interoperates with older versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. These older versions of Microsoft Windows will likely be in use until at least 2015. 7. Acknowledgements Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif Johansson, Simon Josefsson, and Martin Rex have read the document and provided suggestions for improvements. Sam Hartman proposed moving [RFC 1510] to Historic. Michiko Short provided information about the dates of end of support for Windows releases. Hornquist Astrand & Yu Best Current Practice PAGE 5 top

RFC 6649 Deprecate DES in Kerberos July 2012 8. References 8.1. Normative References [RFC 1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC 4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC 4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [RFC 4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows", RFC 4757, December 2006. 8.2. Informative References [Break-DES] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., and M. Schimmler, "How to break DES for EUR 8,980", SHARCS'06 - Special-purpose Hardware for Attacking Cryptographic Systems, April 2006, <http:// www.copacobana.org/paper/copacobana_SHARCS2006.pdf>. [DES-1day] SciEngines GmbH, "Break DES in less than a single day", <http://www.sciengines.com/company/news-a-events/ 74-des-in-1-day.html>. [DES-Crack] Scott, T., "DES Brute Force Cracking Efforts 1977 to 2010", 2010, <http://www.tjscott.net/security.extras/ des.crack.efforts.pdf>. [DES-Transition-Plan] National Institute of Standards and Technology, "DES Transition Plan", May 2005, <http://csrc.nist.gov/groups/ STM/common_documents/DESTranPlan.pdf>. Hornquist Astrand & Yu Best Current Practice PAGE 6 top

RFC 6649 Deprecate DES in Kerberos July 2012 [DES-Withdrawal] National Institute of Standards and Technology, "Announcing Approval of the Withdrawal of Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES); FIPS 74, Guidelines for Implementing and Using the NBS Data Encryption Standard; and FIPS 81, DES Modes of Operation", Federal Register Vol. 70, No. 96, Document 05-9945, 70 FR 28907-28908, May 2005, <http://www.gpo.gov/fdsys/pkg/ FR-2005-05-19/pdf/05-9945.pdf>. [RFC 1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC 4772] Kelly, S., "Security Implications of Using the Data Encryption Standard (DES)", RFC 4772, December 2006. Authors' Addresses Love Hornquist Astrand Apple, Inc. Cupertino, California USA EMail: lha@apple.com Tom Yu MIT Kerberos Consortium 77 Massachusetts Ave. Cambridge, Massachusetts USA EMail: tlyu@mit.edu Hornquist Astrand & Yu Best Current Practice PAGE 7 top

RFC TOTAL SIZE: 13498 bytes PUBLICATION DATE: Tuesday, July 3rd, 2012 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 6649: The IETF Trust, Tuesday, July 3rd, 2012
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement