Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
Retire weak encryption in Kerberos before it becomes a liability.
Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos", BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012, <https://www.rfc-editor.org/info/rfc6649>.
@misc{rfc6649,
series = {Request for Comments},
number = 6649,
howpublished = {RFC 6649},
publisher = {RFC Editor},
doi = {10.17487/RFC6649},
url = {https://www.rfc-editor.org/info/rfc6649},
author = {L. Hornquist Astrand and T. Yu},
title = {{Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos}},
pagetotal = 7,
year = 2012,
month = jul,
} RFC text
Contents
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/rfc6649.
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.
1. Introduction
The original specification of the Kerberos 5 network authentication
protocol [RFC1510] 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 [RFC1510] (obsoleted by [RFC4120]) as Historic
and updates current Kerberos-related specifications [RFC1964],
[RFC4120], and [RFC4121] 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 [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 specification of Kerberos 5 [RFC1510] only supports
DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the
Kerberos specification to include additional cryptographic
algorithms, but still permits the use of DES. [RFC3961] 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 [RFC1964] and
its updated version [RFC4121] define checksum and encryption
mechanisms based on DES. With the existence of newer encryption
types for Kerberos GSS-API defined in [RFC4121], 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.
[RFC4757] 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.)
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 [RFC4772], 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
[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 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 [RFC4120]). One example
is that some legacy systems only support RC4-HMAC(23) [RFC4757] 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 [RFC1964]).
Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SEAL ALG: DES(0000) (updates
[RFC1964]).
The effect of the two last sentences is that this document deprecates
Section 1.2 of [RFC1964].
This document hereby recommends the reclassification of [RFC1510] 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 [RFC4757] continue to apply to
RC4-HMAC, including the known weaknesses of RC4 and MD4, and this
document does not change the Informational status of [RFC4757] 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
[RFC1510] to Historic. Michiko Short provided information about the
dates of end of support 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
[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>.
[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>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC4772] 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
AI ELI5
On this page
§1Why DES Is No Longer Safe
The original Kerberos 5 specification (RFC 1510) supported only the Data Encryption Standard (DES), a 56-bit cipher published in 1977. Even then, cryptographers questioned whether 56 bits was too small. The National Institute of Standards and Technology (NIST) formally withdrew DES in 2005, acknowledging decades of consensus that it was no longer secure.
By 2006, researchers had demonstrated breaking DES in less than 9 days with hardware costing under EUR 10,000. By 2008, companies offered hardware for less than USD 15,000 that could crack a DES key in less than a day on average. DES brute-force attacks only get faster and cheaper as hardware improves.
This document recommends treating RFC 1510 as Historic and updates four Kerberos-related specifications to deprecate DES and other weak cryptographic algorithms, including RC4-HMAC-EXP (another export-strength, 56-bit cipher) and various unencrypted or weak checksums.
DES is an old encryption method with a tiny key. Researchers have shown how to break it with ordinary hardware in less than a day. It is time to stop using it.
§2Which Kerberos Specifications Are Affected
RFC 1510 (September 1993) specified Kerberos 5 with DES as the only encryption algorithm. RFC 4120 (2005) obsoleted RFC 1510 and added modern encryption types to Kerberos but still permitted DES. RFC 3961 describes the Kerberos cryptographic framework and includes DES support but does not specify requirement levels for any algorithm.
RFC 1964 (1996) and RFC 4121 (2005) specify the Kerberos Generic Security Services Application Programming Interface (GSS-API) mechanism, which defines DES-based integrity and confidentiality mechanisms. Modern alternatives (RC4-HMAC, DES3, and others) exist, making DES-based GSS-API mechanisms unnecessary.
RFC 4757 (2006) describes Microsoft's RC4-HMAC encryption types and includes a 56-bit export-strength variant called RC4-HMAC-EXP.
This document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to clarify that weak algorithms SHOULD NOT be used.
Different versions of Kerberos used DES in different ways. This RFC tells all of them to stop using DES and other weak methods.
§3Which Algorithms Are Deprecated
The document removes the RECOMMENDED status from DES-CBC-MD5 (encryption type 3) in RFC 4120. Kerberos implementations and deployments SHOULD NOT implement or deploy these single DES encryption types: DES-CBC-CRC (type 1), DES-CBC-MD4 (type 2), and DES-CBC-MD5 (type 3).
RC4-HMAC-EXP (encryption type 24), the export-strength 56-bit variant, is also deprecated. The document does not mandate RC4-HMAC (type 23), the 128-bit variant.
Several checksum types are deprecated: CRC32, RSA-MD4, RSA-MD4-DES, DES-MAC, DES-MAC-K, RSA-MD4-DES-K, and DES-MD5 (RSA-MD5-DES). These are unencrypted or tied to DES.
RSA-MD5 (type 7) is considered unsafe on its own but MAY be used inside an encrypted Authenticator for backward compatibility with legacy systems that do not support newer checksum types, particularly older Microsoft Windows systems that only support RC4-HMAC.
The GSS-API mechanisms deprecated include DES MAC MD5 (SGN ALG 0000), MD2.5 (0100), DES MAC (0200), and the DES SEAL ALG (0000) from RFC 1964.
These are the old locks to throw away: various ways to use DES in Kerberos, and a few other weak methods. There is one exception for old systems that need temporary help.
§4Security Improvements
Removing single DES encryption directly improves security because DES is cryptographically broken. RC4-HMAC-EXP, with its 56-bit effective key size, has the same inadequate security profile and its removal is equally important.
Kerberos defines some encryption types that are either poorly specified or exist only by name without a published specification. Implementations should ensure they only use secure, well-specified encryption types.
RC4-HMAC (the 128-bit variant) is retained despite known weaknesses in RC4 and MD4 for one reason: it is the only encryption type that maintains interoperability with older Microsoft Windows releases once DES and RC4-HMAC-EXP are removed. These older Windows versions were expected to remain in use at least until 2015. The document does not change the Informational status of RFC 4757 for now.
Removing these weak locks makes Kerberos much safer. One exception is kept temporarily to work with old Windows computers that cannot use anything better.
§5Implementation and Deployment Path
The recommendations use the RFC 2119 keywords SHOULD NOT and MAY, not MUST, to allow for a transition period. Implementations are encouraged (not mandated) to drop weak algorithms. Organizations with legacy systems still using DES or RC4-HMAC-EXP should plan their migration to modern algorithms.
The deprecation of RFC 1510 as Historic acknowledges that the original 1993 specification is obsolete and should not be referenced for new work. RFC 4120 supersedes it and is the authoritative specification, even though it still allows weak algorithms until they are fully removed from implementations.
The RFC does not say implementers MUST remove these locks immediately, but strongly encourages them to do so. Organizations need to plan how to move systems off the weak algorithms.