RFC 6649

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

📅 published July 2012, from ietf

RFC 6649 📜✨ Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos

Okay bestie, this one is a Best Current Practice (BCP 179) from the IETF, dated July 2012 🎀. The authors are L. Hornquist Astrand (Apple, Inc.) and T. Yu (MIT Kerberos Consortium). It obsoletes RFC 1510 and updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757. The ISSN is 2070-1721 💅.

Abstract ✨

Kerberos 5 is a network authentication protocol, first specified in RFC 1510, and it can use the Data Encryption Standard (DES) for encryption 🔐. Almost 30 years after DES was first published, NIST finally withdrew the standard in 2005, which matched a long-running consensus that DES isn't secure enough 💀. By 2008, commercial hardware under USD 15,000 could break DES keys in under a day on average. DES is so far past its sell-by date 😭. So this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate DES, RC4-HMAC-EXP, and other weak algorithms in Kerberos 🫶. Since RFC 1510 (obsoleted by RFC 4120) only supports DES, this document recommends reclassifying 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) and reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 📚.

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6649 💜.

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. Please read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶.

1. Introduction 🦋

The original Kerberos 5 spec, [RFC1510], only supports the Data Encryption Standard (DES) for encryption 🔐. For years, the crypto community has seen DES as not secure enough, mostly because the key is so small 💀. So this document recommends reclassifying [RFC1510] (which [RFC4120] obsoleted) as Historic. It also updates the current Kerberos specs [RFC1964], [RFC4120], and [RFC4121] to deprecate DES and other weak algorithms in Kerberos. That includes some unkeyed checksums and hashes, plus the weak 56-bit "export strength" RC4 variant encryption type from [RFC4757] 🙈.

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 [RFC2119] 🎀.

3. Affected Specifications 📜

The original IETF Kerberos 5 spec, [RFC1510], only supports DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the Kerberos spec to add more crypto algorithms, but it still allows DES 🌸. [RFC3961] describes the Kerberos cryptographic system and includes DES encryption types, but it doesn't set requirement levels for them 🧐.

The Kerberos GSS-API mechanism spec [RFC1964] and its updated version [RFC4121] define checksum and encryption mechanisms based on DES. Now that newer Kerberos GSS-API encryption types exist in [RFC4121], plus Microsoft's RC4-HMAC-based GSS-API mechanism and MIT's DES3 (which isn't published as an RFC), there's no reason to keep supporting the old DES-based integrity (SGN) and confidentiality (SEAL) types 🔥.

[RFC4757] describes the RC4-HMAC encryption types used by Microsoft Windows, and it allows a 56-bit "export strength" variant. (The character constant "fortybits" in the definition is just a historical reference and doesn't mean the real key size of the encryption type 🙃.)

4. DES Insecurity 💀

DES has been obviously insecure for years. Right when it was first published, cryptographers were already saying 56 bits might be too small a key size for DES 😭. NIST officially withdrew DES in 2005 [DES-Withdrawal], and it also announced a transition period that ended on May 19, 2007 [DES-Transition-Plan]. The IETF put its position in writing too, in [RFC4772], and the recommendation summary is super clear: "don't use DES" 🚫.

In 2006, researchers showed they could find a DES key by 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 selling hardware that could break a DES key in under a day on average [DES-1day], and it cost less than USD 15,000 [DES-Crack]. Brute-force DES key searches will only keep getting faster and cheaper 📉. (That company markets its device for one-click recovery of lost DES keys, iykyk 🙈.) It is clearly way past time to retire DES in Kerberos 👑.

5. Recommendations 💖

This document hereby removes the following RECOMMENDED types from [RFC4120] 🌟:

   Encryption: DES-CBC-MD5(3)

   Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]).

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 [RFC4120]) 🚫.

Kerberos implementations and deployments SHOULD NOT implement or deploy the following "export strength" RC4 variant encryption type: RC4-HMAC-EXP(24) (updates [RFC4757]). 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 [RFC4120]) 🙅‍♀️.

It is possible to safely use the RSA-MD5(7) checksum type, but only with extra protection, like the protection an encrypted Authenticator provides 🔐. Implementations MAY use RSA-MD5 inside an encrypted Authenticator for backward compatibility with systems that don't support newer checksum types (updates [RFC4120]) 🫶. For example, some legacy systems only support RC4-HMAC(23) [RFC4757] for encryption when DES isn't available. Those 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 [RFC1964]) 🌸.

Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SEAL ALG: DES(0000) (updates [RFC1964]) 🌸.

The effect of the last two sentences is that this document deprecates Section 1.2 of [RFC1964] 🦋.

This document hereby recommends reclassifying [RFC1510] as Historic 📚.

6. Security Considerations 🔥

Removing support for single DES improves security, because DES is considered insecure 🔐. RC4-HMAC-EXP has a similarly inadequate key size, so removing it also improves security 💪.

Kerberos defines some encryption types that are either underspecified or only have number assignments with no specifications. Implementations should make sure they only implement and enable secure encryption types ⚠️.

The security considerations of [RFC4757] still apply to RC4-HMAC, including the known weaknesses of RC4 and MD4. This document doesn't change the Informational status of [RFC4757] for now. The main reason not to actively discourage RC4-HMAC is that it's the only encryption type that works with older versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. Those older versions will likely still be in use until at least 2015 😬.

7. Acknowledgements 🫶

Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif Johansson, Simon Josefsson, and Martin Rex read the document and gave suggestions for improvements 💖. Sam Hartman proposed moving [RFC1510] to Historic 👑. Michiko Short shared info about the end-of-support dates for Windows releases 🙌.

8. References 📚

8.1. Normative References

   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
               RFC 1964, June 1996.

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

   [RFC3961]   Raeburn, K., "Encryption and Checksum Specifications for
               Kerberos 5", RFC 3961, February 2005.

   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
               Kerberos Network Authentication Service (V5)", RFC 4120,
               July 2005.

   [RFC4121]   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.

   [RFC4757]   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 📚

Okay bestie, these are the extra-credit reads 🤓 Not required, but they give the whole DES saga receipts 💅

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
📦 where this page comes from