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

The original specification of the Kerberos 5 network authentication protocol 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 (obsoleted by ) as Historic and updates current Kerberos-related specifications , , and 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 .

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 .

The original IETF specification of Kerberos 5 only supports DES for encryption. obsoletes and updates the Kerberos specification to include additional cryptographic algorithms, but still permits the use of DES. 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 and its updated version define checksum and encryption mechanisms based on DES. With the existence of newer encryption types for Kerberos GSS-API defined in , Microsoft's RC4&nbhy;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. 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.)

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 , and also announced a transition period that ended on May 19, 2007 . The IETF has also published its position in , 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 . By 2008, a company was offering hardware capable of breaking a DES key in less than a day on average that cost less than USD 15,000 . 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.

This document hereby removes the following RECOMMENDED types from : Encryption: DES-CBC-MD5(3) Checksums: DES-MD5 (8, named RSA-MD5-DES in ). 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 ). Kerberos implementations and deployments SHOULD NOT implement or deploy the following "export strength" RC4 variant encryption type: RC4-HMAC-EXP(24) (updates ). This document does not add any sort of requirement for conforming implementations to implement RC4&nbhy;HMAC(23). Kerberos implementations and deployments SHOULD NOT implement or deploy the following checksum types: CRC32(1), RSA-MD4(2), RSA&nbhy;MD4&nbhy;DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA&nbhy;MD5&nbhy;DES(8) (updates ). 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 encrypted Authenticator for backward compatibility with systems that do not support newer checksum types (updates ). One example is that some legacy systems only support RC4-HMAC(23) 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 ). Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SEAL ALG: DES(0000) (updates ). The effect of the two last sentences is that this document deprecates Section 1.2 of . This document hereby recommends the reclassification of as Historic.

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 continue to apply to RC4&nbhy;HMAC, including the known weaknesses of RC4 and MD4, and this document does not change the Informational status of 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.

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 to Historic. Michiko Short provided information about the dates of end of support for Windows releases.