draft-ietf-krb-wg-des-die-die-die-04.txt   rfc6649.txt 
Network Working Group L. Hornquist Astrand Internet Engineering Task Force (IETF) L. Hornquist Astrand
Internet-Draft Apple, Inc Request for Comments: 6649 Apple, Inc.
Updates: 1510, 1964, 4120, 4121, 4757 T. Yu BCP: 179 T. Yu
(if approved) MIT Kerberos Consortium Obsoletes: 1510 MIT Kerberos Consortium
Intended status: BCP February 27, 2012 Updates: 1964, 4120, 4121, 4757 July 2012
Expires: August 30, 2012 Category: Best Current Practice
ISSN: 2070-1721
Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms
Kerberos in Kerberos
draft-ietf-krb-wg-des-die-die-die-04
Abstract Abstract
The Kerberos 5 network authentication protocol, originally specified The Kerberos 5 network authentication protocol, originally specified
in RFC1510, can use the Data Encryption Standard (DES) for in RFC 1510, can use the Data Encryption Standard (DES) for
encryption. Almost 30 years after first publishing DES, the National encryption. Almost 30 years after first publishing DES, the National
Institute of Standards and Technology (NIST) finally withdrew the Institute of Standards and Technology (NIST) finally withdrew the
standard in 2005, reflecting a long-established consensus that DES is standard in 2005, reflecting a long-established consensus that DES is
insufficiently secure. By 2008, commercial hardware costing less insufficiently secure. By 2008, commercial hardware costing less
than USD 15,000 could break DES keys in less than a day on average. 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 DES is long past its sell-by date. Accordingly, this document
updates RFC1964, RFC4120, RFC4121, and RFC4757 to deprecate the use updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the
of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in
Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only
this document reclassifies RFC1510 as Historic. DES, this document recommends the reclassification of RFC 1510 as
Historic.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This memo documents an Internet Best Current Practice.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 30, 2012. 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Requirements Notation 1. Introduction
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].
2. Introduction
The original specification of the Kerberos 5 network authentication The original specification of the Kerberos 5 network authentication
protocol [RFC1510] supports only the Data Encryption Standard (DES) protocol [RFC1510] supports only the Data Encryption Standard (DES)
for encryption. For many years, the cryptographic community has for encryption. For many years, the cryptographic community has
regarded DES as providing inadequate security, mostly because of its regarded DES as providing inadequate security, mostly because of its
small key size. Accordingly, this document reclassifies [RFC1510] small key size. Accordingly, this document recommends the
(obsoleted by [RFC4120]) as Historic, and updates current Kerberos- reclassification of [RFC1510] (obsoleted by [RFC4120]) as Historic
related specifications [RFC1964], [RFC4120], and [RFC4121] to and updates current Kerberos-related specifications [RFC1964],
deprecate the use of DES and other weak cryptographic algorithms in [RFC4120], and [RFC4121] to deprecate the use of DES and other weak
Kerberos, including some unkeyed checksums and hashes, along with the cryptographic algorithms in Kerberos, including some unkeyed
weak 56-bit "export strength" RC4 variant enctype of [RFC4757]. checksums and hashes, along with the weak 56-bit "export strength"
RC4 variant encryption type of [RFC4757].
3. Affected specifications 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 The original IETF specification of Kerberos 5 [RFC1510] only supports
DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the
Kerberos specification to include additional cryptographic Kerberos specification to include additional cryptographic
algorithms, but still permits the use of DES. [RFC3961] describes algorithms, but still permits the use of DES. [RFC3961] describes
the Kerberos cryptographic system and includes support for DES the Kerberos cryptographic system and includes support for DES
encryption types, but it does not specify requirement levels for encryption types, but it does not specify requirement levels for
them. them.
The specification of the Kerberos Generic Security Services The specification of the Kerberos Generic Security Services
Application Programming Interface (GSS-API) mechanism [RFC1964] and Application Programming Interface (GSS-API) mechanism [RFC1964] and
its updated version [RFC4121] define checksum and encryption its updated version [RFC4121] define checksum and encryption
mechanisms based on DES. With the existence of newer encryption mechanisms based on DES. With the existence of newer encryption
types for Kerberos GSS-API defined in [RFC4121], Microsoft's RC4-HMAC types for Kerberos GSS-API defined in [RFC4121], Microsoft's
based GSS-API mechanism, and MIT's DES3 (which is not published as an RC4-HMAC-based GSS-API mechanism, and MIT's DES3 (which is not
RFC), there is no need to support the old DES based integrity (SGN) published as an RFC), there is no need to support the old DES-based
and confidentiality (SEAL) types. integrity (SGN) and confidentiality (SEAL) types.
[RFC4757] describes the RC4-HMAC encryption types used by Microsoft [RFC4757] describes the RC4-HMAC encryption types used by Microsoft
Windows, and allows for a 56-bit "export strength" variant. (The Windows and allows for a 56-bit "export strength" variant. (The
character constant "fortybits" used in the definition is a historical character constant "fortybits" used in the definition is a historical
reference and does not refer to the actual key size of the enctype.) reference and does not refer to the actual key size of the encryption
type.)
4. DES insecurity 4. DES Insecurity
The insecurity of DES has been evident for many years. Even around The insecurity of DES has been evident for many years. Even around
the time of its first publication, cryptographers raised the the time of its first publication, cryptographers raised the
possibility that 56 bits was too small a key size for DES. The possibility that 56 bits was too small a key size for DES. The
National Institute of Standards and Technology (NIST) officially National Institute of Standards and Technology (NIST) officially
withdrew DES in 2005 [DES-Withdrawal], and also announced a withdrew DES in 2005 [DES-Withdrawal], and also announced a
transition period that ended on May 19, 2007 [DES-Transition-Plan]. transition period that ended on May 19, 2007 [DES-Transition-Plan].
The IETF has also published its position in [RFC4772], in which the The IETF has also published its position in [RFC4772], in which the
recommendation summary is very clear: "don't use DES". recommendation summary is very clear: "don't use DES".
In 2006, researchers demonstrated the ability to brute force a DES In 2006, researchers demonstrated the ability to find a DES key via
key in an average of less than 9 days using less than EUR 10,000 brute-force search in an average of less than 9 days using less than
worth of hardware [Break-DES]. By 2008, a company was offering EUR 10,000 worth of hardware [Break-DES]. By 2008, a company was
hardware capable of breaking a DES key in less than a day on average offering hardware capable of breaking a DES key in less than a day on
[DES-1day] that cost less than USD 15,000 [DES-crack]. Brute force average [DES-1day] that cost less than USD 15,000 [DES-Crack].
key searches of DES will only get faster and cheaper. (The Brute-force key searches of DES will only get faster and cheaper.
aforementioned company markets its device for one-click recovery of (The aforementioned company markets its device for one-click recovery
lost DES keys.) It is clear that it is well past time to retire the of lost DES keys.) It is clear that it is well past time to retire
use of DES in Kerberos. the use of DES in Kerberos.
5. Recommendations 5. Recommendations
This document hereby removes the following RECOMMENDED types from This document hereby removes the following RECOMMENDED types from
[RFC4120]: [RFC4120]:
Encryption: DES-CBC-MD5(3) Encryption: DES-CBC-MD5(3)
Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]).
Kerberos implementations and deployments SHOULD NOT implement or Kerberos implementations and deployments SHOULD NOT implement or
deploy the following single DES encryption types: DES-CBC-CRC(1), deploy the following single DES encryption types: DES-CBC-CRC(1),
DES-CBC-MD4(2), DES-CBC-MD5(3) (updates [RFC4120]). DES-CBC-MD4(2), DES-CBC-MD5(3) (updates [RFC4120]).
Kerberos implementations and deployments SHOULD NOT implement or Kerberos implementations and deployments SHOULD NOT implement or
deploy the following "export strength" RC4 variant encryption type: deploy the following "export strength" RC4 variant encryption type:
RC4-HMAC-EXP(24) (updates [RFC4757]). This document does not add any RC4-HMAC-EXP(24) (updates [RFC4757]). This document does not add any
sort of requirement for conforming implementations to implement RC4- sort of requirement for conforming implementations to implement
HMAC(23). RC4-HMAC(23).
Kerberos implementations and deployments SHOULD NOT implement or Kerberos implementations and deployments SHOULD NOT implement or
deploy the following checksum types: CRC32(1), RSA-MD4(2), RSA-MD4- deploy the following checksum types: CRC32(1), RSA-MD4(2),
DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8) RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6),
(updates [RFC4120]). RSA-MD5-DES(8) (updates [RFC4120]).
It is possible to safely use the RSA-MD5(7) checksum type, but only It is possible to safely use the RSA-MD5(7) checksum type, but only
with additional protection, such as the protection that an encrypted with additional protection, such as the protection that an encrypted
Authenticator provides. Implementations MAY use RSA-MD5 inside an Authenticator provides. Implementations MAY use RSA-MD5 inside an
encrypted Authenticator for backward compatibility with systems that encrypted Authenticator for backward compatibility with systems that
do not support newer checksum types (updates [RFC4120]). One example do not support newer checksum types (updates [RFC4120]). One example
is that some legacy systems only support RC4-HMAC(23) [RFC4757] for is that some legacy systems only support RC4-HMAC(23) [RFC4757] for
encryption when DES is not available; these systems use RSA-MD5 encryption when DES is not available; these systems use RSA-MD5
checksums inside Authenticators encrypted with RC4-HMAC. checksums inside Authenticators encrypted with RC4-HMAC.
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SGN ALG: DES MAC MD5(0000), implement or deploy the following SGN ALG: DES MAC MD5(0000),
MD2.5(0100), DES MAC(0200) (updates [RFC1964]). MD2.5(0100), DES MAC(0200) (updates [RFC1964]).
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SEAL ALG: DES(0000) (updates implement or deploy the following SEAL ALG: DES(0000) (updates
[RFC1964]). [RFC1964]).
The effect of the two last sentences is that this document deprecates The effect of the two last sentences is that this document deprecates
section 1.2 in [RFC1964]. Section 1.2 of [RFC1964].
This document hereby reclassifies [RFC1510] as Historic.
6. Acknowledgements
Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif This document hereby recommends the reclassification of [RFC1510] as
Johansson, Simon Josefsson, and Martin Rex have read the document and Historic.
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.
7. Security Considerations 6. Security Considerations
Removing support for single DES improves security, because DES is Removing support for single DES improves security because DES is
considered to be insecure. RC4-HMAC-EXP has a similarly inadequate considered to be insecure. RC4-HMAC-EXP has a similarly inadequate
key size, so removing support for it also improves security. key size, so removing support for it also improves security.
Kerberos defines some encryption types that are either underspecified Kerberos defines some encryption types that are either underspecified
or that only have number assignments but no specifications. or that only have number assignments but no specifications.
Implementations should make sure that they only implement and enable Implementations should make sure that they only implement and enable
secure encryption types. secure encryption types.
The security considerations of [RFC4757] continue to apply to RC4- The security considerations of [RFC4757] continue to apply to
HMAC, including the known weaknesses of RC4 and MD4, and this RC4-HMAC, including the known weaknesses of RC4 and MD4, and this
document does not change the Informational status of [RFC4757] for document does not change the Informational status of [RFC4757] for
now. The main reason to not actively discourage the use of RC4-HMAC 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 is that it is the only encryption type that interoperates with older
versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed.
These older versions of Microsoft Windows will likely be in use until These older versions of Microsoft Windows will likely be in use until
at least 2015. at least 2015.
8. IANA Considerations 7. Acknowledgements
There are no IANA Considerations for this document. 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.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
Kerberos Encryption Types Used by Microsoft Windows", Kerberos Encryption Types Used by Microsoft Windows",
RFC 4757, December 2006. RFC 4757, December 2006.
9.2. Informative References 8.2. Informative References
[Break-DES] [Break-DES] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A.,
Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., and M. Schimmler, "How to break DES for EUR 8,980",
and M. Schimmler, "How to break DES for EUR 8,980 - SHARCS'06 - Special-purpose Hardware for Attacking
SHARCS'06 - Special-purpose Hardware for Attacking Cryptographic Systems, April 2006, <http://
Cryptographic Systems", April 2006, <http:// www.copacobana.org/paper/copacobana_SHARCS2006.pdf>.
www.copacobana.org/paper/copacobana_SHARCS2006.pdf>.
[DES-1day] [DES-1day] SciEngines GmbH, "Break DES in less than a single day",
SciEngines GmbH, "Break DES in less than a single day", <h <http://www.sciengines.com/company/news-a-events/
ttp://www.sciengines.com/company/news-a-events/ 74-des-in-1-day.html>.
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] [DES-Transition-Plan]
National Institute of Standards and Technology, "DES National Institute of Standards and Technology, "DES
Transition Plan", May 2005, <http://csrc.nist.gov/groups/ Transition Plan", May 2005, <http://csrc.nist.gov/groups/
STM/common_documents/DESTranPlan.pdf>. STM/common_documents/DESTranPlan.pdf>.
[DES-Withdrawal] [DES-Withdrawal]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Announcing Approval of the Withdrawal of Federal "Announcing Approval of the Withdrawal of Federal
Information Processing Standard (FIPS) 46-3, Data Information Processing Standard (FIPS) 46-3, Data
Encryption Standard (DES); FIPS 74, Guidelines for Encryption Standard (DES); FIPS 74, Guidelines for
Implementing and Using the NBS Data Encryption Standard; Implementing and Using the NBS Data Encryption Standard;
and FIPS 81, DES Modes of Operation - Federal Register and FIPS 81, DES Modes of Operation", Federal Register
Document 05-9945", 70 FR 28907-28908, May 2005, <http:// Vol. 70, No. 96, Document 05-9945, 70 FR 28907-28908,
www.gpo.gov/fdsys/pkg/FR-2005-05-19/pdf/05-9945.pdf>. May 2005, <http://www.gpo.gov/fdsys/pkg/
FR-2005-05-19/pdf/05-9945.pdf>.
[DES-crack]
Scott, T., "DES Brute Force Cracking Efforts 1977 to
2010", 2010, <http://www.tjscott.net/security.extras/
des.crack.efforts.pdf>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication Service (V5)", RFC 1510, September 1993.
[RFC4772] Kelly, S., "Security Implications of Using the Data [RFC4772] Kelly, S., "Security Implications of Using the Data
Encryption Standard (DES)", RFC 4772, December 2006. Encryption Standard (DES)", RFC 4772, December 2006.
Authors' Addresses Authors' Addresses
Love Hornquist Astrand Love Hornquist Astrand
Apple, Inc Apple, Inc.
Cupertino Cupertino, California
USA USA
Email: lha@apple.com EMail: lha@apple.com
Tom Yu Tom Yu
MIT Kerberos Consortium MIT Kerberos Consortium
77 Massachusetts Ave 77 Massachusetts Ave.
Cambridge, Massachusetts Cambridge, Massachusetts
USA USA
Email: tlyu@mit.edu EMail: tlyu@mit.edu
 End of changes. 46 change blocks. 
131 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/