Difference between revisions of "RFC6649"

From RFC-Wiki
imported>Admin
(Created page with " Internet Engineering Task Force (IETF) L. Hornquist AstrandRequest for Comments: 6649 Apple, Inc.BCP: 179 ...")
 
 
Line 1: Line 1:
 +
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'''
 
 
 
 
 
 
Internet Engineering Task Force (IETF)              L. Hornquist AstrandRequest for Comments: 6649                                  Apple, Inc.BCP: 179                                                          T. YuObsoletes: 1510                                  MIT Kerberos ConsortiumUpdates: 1964, 4120, 4121, 4757                                July 2012Category: Best Current PracticeISSN: 2070-1721
 
 
 
  Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms                          in Kerberos
 
Abstract
 
  
 
The Kerberos 5 network authentication protocol, originally specified
 
The Kerberos 5 network authentication protocol, originally specified
Line 24: Line 26:
 
Historic.
 
Historic.
  
Status of This Memo
+
'''Status of This Memo'''
  
 
This memo documents an Internet Best Current Practice.
 
This memo documents an Internet Best Current Practice.
Line 38: Line 40:
 
http://www.rfc-editor.org/info/rfc6649.
 
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
Line 63: Line 54:
 
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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
== Introduction ==
 
== 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 recommends the
 
small key size.  Accordingly, this document recommends the
reclassification of [RFC1510] (obsoleted by [RFC4120]) as Historic
+
reclassification of [[RFC1510]] (obsoleted by [[RFC4120]]) as Historic
and updates current Kerberos-related specifications [RFC1964],
+
and updates current Kerberos-related specifications [[RFC1964]],
[RFC4120], and [RFC4121] to deprecate the use of DES and other weak
+
[[RFC4120]], and [[RFC4121]] to deprecate the use of DES and other weak
 
cryptographic algorithms in Kerberos, including some unkeyed
 
cryptographic algorithms in Kerberos, including some unkeyed
 
checksums and hashes, along with the weak 56-bit "export strength"
 
checksums and hashes, along with the weak 56-bit "export strength"
RC4 variant encryption type of [RFC4757].
+
RC4 variant encryption type of [[RFC4757]].
  
 
== Requirements Notation ==
 
== Requirements Notation ==
Line 120: Line 73:
 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
+
document are to be interpreted as described in [[RFC2119]].
  
 
== Affected Specifications ==
 
== 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
Line 133: Line 86:
  
 
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
+
types for Kerberos GSS-API defined in [[RFC4121]], Microsoft's
 
RC4-HMAC-based GSS-API mechanism, and MIT's DES3 (which is not
 
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
 
published as an RFC), there is no need to support the old DES-based
 
integrity (SGN) 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 encryption
 
reference and does not refer to the actual key size of the encryption
 
type.)
 
type.)
 
 
 
 
 
 
 
 
  
 
== DES Insecurity ==
 
== DES Insecurity ==
Line 163: Line 108:
 
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".
  
Line 179: Line 124:
  
 
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
 
sort of requirement for conforming implementations to implement
 
RC4-HMAC(23).
 
RC4-HMAC(23).
Line 198: Line 143:
 
deploy the following checksum types: CRC32(1), RSA-MD4(2),
 
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-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6),
RSA-MD5-DES(8) (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.
Line 216: Line 157:
 
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 of [RFC1964].
+
Section 1.2 of [[RFC1964]].
  
This document hereby recommends the reclassification of [RFC1510] as
+
This document hereby recommends the reclassification of [[RFC1510]] as
 
Historic.
 
Historic.
  
Line 239: Line 180:
 
secure encryption types.
 
secure encryption types.
  
The security considerations of [RFC4757] continue to apply to
+
The security considerations of [[RFC4757]] continue to apply to
 
RC4-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
Line 253: Line 194:
 
Johansson, Simon Josefsson, and Martin Rex have read the document and
 
Johansson, Simon Josefsson, and Martin Rex have read the document and
 
provided suggestions for improvements.  Sam Hartman proposed moving
 
provided suggestions for improvements.  Sam Hartman proposed moving
[RFC1510] to Historic.  Michiko Short provided information about the
+
[[RFC1510]] to Historic.  Michiko Short provided information about the
 
dates of end of support for Windows releases.
 
dates of end of support for Windows releases.
  
 +
== References ==
  
 +
=== Normative References ===
  
 +
[[RFC1964]]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 +
            [[RFC1964|RFC 1964]], June 1996.
  
 +
[[RFC2119]]  Bradner, S., "Key words for use in RFCs to Indicate
 +
            Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
  
 +
[[RFC3961]]  Raeburn, K., "Encryption and Checksum Specifications for
 +
            Kerberos 5", [[RFC3961|RFC 3961]], February 2005.
  
== References ==
+
[[RFC4120]]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 +
            Kerberos Network Authentication Service (V5)", [[RFC4120|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", [[RFC4121|RFC 4121]],
 +
            July 2005.
  
=== Normative References ===
+
[[RFC4757]]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
 +
            Kerberos Encryption Types Used by Microsoft Windows",
 +
            [[RFC4757|RFC 4757]], December 2006.
  
[RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",            [[RFC1964|RFC 1964]], June 1996.
 
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate            Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
 
[RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for            Kerberos 5", [[RFC3961|RFC 3961]], February 2005.
 
[RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The            Kerberos Network Authentication Service (V5)", [[RFC4120|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", [[RFC4121|RFC 4121]],            July 2005.
 
[RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC            Kerberos Encryption Types Used by Microsoft Windows",            [[RFC4757|RFC 4757]], December 2006.
 
 
=== Informative References ===
 
=== 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>.
+
[Break-DES] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A.,
[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>.
+
            and M. Schimmler, "How to break DES for EUR 8,980",
[DES-Crack] Scott, T., "DES Brute Force Cracking Efforts 1977 to            2010", 2010, <http://www.tjscott.net/security.extras/            des.crack.efforts.pdf>.
+
            SHARCS'06 - Special-purpose Hardware for Attacking
[DES-Transition-Plan]            National Institute of Standards and Technology, "DES            Transition Plan", May 2005, <http://csrc.nist.gov/groups/            STM/common_documents/DESTranPlan.pdf>.
+
            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)", [[RFC1510|RFC 1510]], September 1993.
  
 +
[[RFC4772]]  Kelly, S., "Security Implications of Using the Data
 +
            Encryption Standard (DES)", [[RFC4772|RFC 4772]], December 2006.
  
[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)", [[RFC1510|RFC 1510]], September 1993.
 
[RFC4772]  Kelly, S., "Security Implications of Using the Data            Encryption Standard (DES)", [[RFC4772|RFC 4772]], December 2006.
 
 
Authors' Addresses
 
Authors' Addresses
  
Line 294: Line 269:
  
  
 
  
 
Tom Yu
 
Tom Yu
Line 303: Line 277:
  
  
 +
 +
[[Category:Best Current Practice]]

Latest revision as of 15:57, 1 October 2020

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.

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.

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.

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.)

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.

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.

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.

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.

References

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.

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: [email protected]

Tom Yu MIT Kerberos Consortium 77 Massachusetts Ave. Cambridge, Massachusetts USA

EMail: [email protected]