path: root/doc/rfc/rfc8429.txt

Internet Engineering Task Force (IETF)                          B. Kaduk
Request for Comments: 8429                                        Akamai
BCP: 218                                                        M. Short
Updates: 3961, 4120                                Microsoft Corporation
Category: Best Current Practice                             October 2018
ISSN: 2070-1721


            Deprecate Triple-DES (3DES) and RC4 in Kerberos

Abstract

   The triple-DES (3DES) and RC4 encryption types are steadily weakening
   in cryptographic strength, and the deprecation process should begin
   for their use in Kerberos.  Accordingly, RFC 4757 has been moved to
   Historic status, as none of the encryption types it specifies should
   be used, and RFC 3961 has been updated to note the deprecation of the
   triple-DES encryption types.  RFC 4120 is likewise updated to remove
   the recommendation to implement triple-DES encryption and checksum
   types.

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

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8429.

















Kaduk & Short             Best Current Practice                 [Page 1]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Affected Specifications . . . . . . . . . . . . . . . . . . .   3
   4.  Affected Encryption Types . . . . . . . . . . . . . . . . . .   4
   5.  RC4 Weakness  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Statistical Biases  . . . . . . . . . . . . . . . . . . .   4
     5.2.  Password Hash . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Cross-Protocol Key Reuse  . . . . . . . . . . . . . . . .   5
     5.4.  Interoperability Concerns . . . . . . . . . . . . . . . .   6
   6.  Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Password-Based Keys . . . . . . . . . . . . . . . . . . .   7
     6.2.  Block Size  . . . . . . . . . . . . . . . . . . . . . . .   7
     6.3.  Interoperability Concerns . . . . . . . . . . . . . . . .   7
   7.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10













Kaduk & Short             Best Current Practice                 [Page 2]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


1.  Introduction

   The triple-DES (3DES) and RC4 encryption types (enctypes) are
   steadily weakening in cryptographic strength, and the deprecation
   process should begin for their use in Kerberos.  Accordingly, RFC
   4757 has been moved to Historic status, as none of the encryption
   types it specifies should be used, and RFC 3961 has been updated to
   note the deprecation of the triple-DES encryption types.  RFC 4120 is
   likewise updated to remove the recommendation to implement triple-DES
   encryption and checksum types.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Affected Specifications

   The RC4 Kerberos encryption types (including rc4-hmac) are specified
   in [RFC4757], which has been moved to Historic status.

   The des3-cbc-sha1-kd encryption type is specified in [RFC3961].
   Additional triple-DES encryption type codepoints are in use and in
   the IANA registry with no formal specification, in particular
   des3-cbc-md5 and des3-cbc-sha1.  These unspecified encryption types
   are also deprecated by this document.

   The Kerberos specification ([RFC4120]) includes recommendations for
   which encryption and checksum types to implement; the deprecated
   encryption and checksum types are now disrecommended to implement.

   Though the RC4 and triple-DES encryption types are still in use in
   some deployments, the above status changes are made to discourage
   their use.














Kaduk & Short             Best Current Practice                 [Page 3]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


4.  Affected Encryption Types

   The following encryption types are deprecated.  The numbers are the
   official identifiers; the names are only for convenience.

               +----------------+--------------------------+
               | enctype number | enctype convenience name |
               +----------------+--------------------------+
               |       5        |       des3-cbc-md5       |
               |                |                          |
               |       7        |      des3-cbc-sha1       |
               |                |                          |
               |       16       |     des3-cbc-sha1-kd     |
               |                |                          |
               |       23       |         rc4-hmac         |
               +----------------+--------------------------+

5.  RC4 Weakness

   RC4's weakness as a TLS cipher due to statistical biases in the
   keystream has been well publicized [RFC7465], and these statistical
   biases cause concern for any consumer of the RC4 cipher.  However,
   the RC4 Kerberos enctypes have additional flaws.  These flaws reduce
   the security of applications that use the enctypes; the weakening
   occurs for various reasons, including the weakness of the password
   hashing algorithm, the reuse of key material across protocols, and
   the lack of a salt when hashing the password.

5.1.  Statistical Biases

   The RC4 stream cipher is known to have statistical biases in its
   output, which have led to practical attacks against protocols such as
   TLS that use RC4 [RFC7465].  At least some of these attacks rely on
   repeated encryptions of thousands of copies of the same plaintext;
   although it is easy for malicious javascript in a website to cause
   such traffic, it is unclear whether there is an easy way to induce a
   kerberized application to generate such repeated encryptions.  The
   statistical biases are most pronounced for earlier bits in the output
   stream, which is somewhat mitigated by the use of a confounder in
   Kerberos messages: the first 64 bits of plaintext are a random
   confounder, and are thus of no use to an attacker who can retrieve
   them.

   Nonetheless, the statistical biases in the RC4 keystream extend well
   past 64 bits and provide potential attack surface to an attacker.
   Continuing to use a known weak algorithm is inviting further
   development of attacks.




Kaduk & Short             Best Current Practice                 [Page 4]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


5.2.  Password Hash

   Kerberos long-term keys can be either random (as might be used in a
   service's keytab) or derived from a password (e.g., for individual
   users to authenticate to a system).  The specification for a Kerberos
   encryption type must include a "string2key" algorithm for generating
   a raw crypto key from a string (i.e., password).  Modern encryption
   types, such as those using the AES and Camellia block ciphers, use a
   string2key function based on the Password-Based Key Derivation
   Function 2 (PBKDF2) algorithm.  This algorithm involves many
   iterations of a cryptographic hash function, designed to increase the
   computational effort required to perform a brute-force password-
   guessing attack.  There is an additional option to specify an
   increased iteration count for a given principal, providing some
   modicum of adaptability for increases in computing power.

   It is also best practice, when deriving cryptographic secrets from
   user passwords, to include as input to the hash function a value that
   is unique to both the user and the realm of authentication; this
   user-specific input is known as a "salt".  The default salt for
   Kerberos principals includes both the name of the principal and the
   name of the realm, in accordance with these best practices.  However,
   the RC4 encryption types ignore the salt input to the string2key
   function; the function itself is a single iteration of the MD4 hash
   function applied to the UTF-16 encoded password, with no salt at all.
   The MD4 hash function is very old and considered to be weak and
   unsuitable for new cryptographic applications at this time [RFC6150].

   The omission of a salt input to the hash is contrary to cryptographic
   best practices and allows an attacker to construct a "rainbow table"
   of password hashes; such tables are applicable to all principals in
   all Kerberos realms.  Given the prevalence of poor-quality user-
   selected passwords, it is likely that a rainbow table derived from a
   database of common passwords would be able to compromise a sizable
   number of Kerberos principals in any realm using RC4 encryption types
   for password-derived keys.

5.3.  Cross-Protocol Key Reuse

   The selection of unsalted MD4 as the Kerberos string2key function was
   deliberate, since it allowed systems to be converted in-place from
   the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use
   Kerberos.

   Unfortunately, there still exist systems using NTLM for
   authentication to applications, which can result in application
   servers possessing the NT password hash of user passwords.  Because
   the RC4 string2key function was chosen to be compatible with the NTLM



Kaduk & Short             Best Current Practice                 [Page 5]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


   scheme, these application servers also possess the long-term Kerberos
   key for those users, even though the password is unknown.  The cross-
   protocol use of the long-term key/password hash was convenient for
   migrating to Kerberos, but it now provides a vulnerability in
   Kerberos as NTLM continues to be used.

5.4.  Interoperability Concerns

   The RC4 Kerberos encryption type remains in use in many environments
   because of interoperability requirements.  In those sites, RC4 is the
   strongest enctype that allows two parties to use Kerberos to
   communicate.  In particular, the Kerberos implementations included
   with Windows XP and Windows Server 2003 support only single-DES and
   RC4.  Since single-DES is deprecated [RFC6649], machines running
   those operating systems must use RC4.

   Similarly, there are cross-realm deployments in which the cross-realm
   key was initially established when one peer only supported RC4, or
   machines only supporting RC4 need to obtain a cross-realm Ticket-
   Granting Ticket.  It can be difficult to inventory all clients in a
   Kerberos realm and know what implementations will be used by those
   client principals; this leads to concerns that disabling RC4 will
   cause breakage on machines that are unknown to the realm
   administrators.

   Fortunately, modern (i.e., supported) Kerberos implementations
   support a secure alternative to RC4 in the form of AES.  Windows has
   supported AES since 2007-2008 with the release of Windows Vista and
   Server 2008.  MIT Kerberos [MITKRB5] has fully supported AES enctypes
   since 2004 with the release of version 1.3.2, including the Kerberos
   mechanism for the Generic Security Service Application Program
   Interface (GSSAPI).  Heimdal [HEIMDAL] has fully supported AES since
   2005 with the release of version 0.7.  Though there may still be
   issues running ten-year-old unsupported software in mixed
   environments with new software, issues of that sort seem unlikely to
   be unique to Kerberos, and the administrators of such environments
   are expected to be capable of devising workarounds.

6.  Triple-DES Weakness

   The flaws in triple-DES as used for Kerberos are not quite as damning
   as those in RC4, but there is still ample justification for
   deprecating its use.  As is the case for the RC4 enctypes, the
   string2key algorithm is weak.  Additionally, the triple-DES
   encryption types were not implemented in all Kerberos
   implementations, and the 64-bit block size may be problematic in some
   environments.




Kaduk & Short             Best Current Practice                 [Page 6]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


6.1.  Password-Based Keys

   The n-fold-based string2key function used by the des3-cbc-sha1-kd
   encryption type is an ad hoc construction that should not be
   considered cryptographically sound.  It is known to not provide
   effective mixing of the input bits and is computationally easy to
   evaluate.  As such, it does not slow down brute-force attacks in the
   way that the computationally demanding PBKDF2 algorithm used by more
   modern encryption types does.  The salt is used by des3-cbc-sha1-kd's
   string2key function, in contrast to RC4, but a brute-force dictionary
   attack on common passwords may still be feasible.

6.2.  Block Size

   Triple-DES is based on the single-DES primitive, simply using
   additional key material and nested encryption.  Therefore, it
   inherits the 64-bit cipher block size from single-DES.  As a result,
   an attacker who can collect approximately 2**32 blocks of ciphertext
   has a good chance of finding a cipher block collision (the "birthday
   attack"), which would potentially reveal a couple of blocks of
   plaintext.

   A cipher block collision would not necessarily cause the key itself
   to be leaked, so the plaintext revealed by such a collision would be
   limited.  For some sites, that may be an acceptable risk, but it is
   still considered a weakness in the encryption type.

6.3.  Interoperability Concerns

   The triple-DES encryption types were implemented by MIT Kerberos
   early in its development (ca. 1999) and present in the 1.2 release,
   but they were superseded when encryption types 17 and 18 (AES) were
   implemented (by 2003); the AES enctypes were present in the 1.3
   release.  The Heimdal Kerberos implementation also provided a version
   of triple-DES in 1999 (though the GSSAPI portions remained non-
   interoperable with MIT for some time after that), gaining support for
   AES in 2005 with its 0.7 release.  Both Heimdal and MIT krb5 have
   supported the AES enctypes for some 12 years, and it is expected that
   deployments that support triple-DES but not AES are quite rare.

   The Kerberos implementation in Microsoft Windows has never
   implemented the triple-DES encryption type.  Support for AES was
   introduced with Windows Vista and Windows Server 2008; older versions
   such as Windows XP and Windows Server 2003 only supported the RC4 and
   single-DES encryption types.






Kaduk & Short             Best Current Practice                 [Page 7]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


   The triple-DES encryption type offers very slow encryption,
   especially compared to the performance of AES using the hardware
   acceleration available in modern CPUs.  There are no areas where
   triple-DES offers advantages over other encryption types except in
   the rare case where AES is not available.

7.  Recommendations

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

      Encryption: DES3-CBC-SHA1-KD

      Checksum: HMAC-SHA1-DES3-KD

   Kerberos implementations and deployments SHOULD NOT implement or
   deploy the following triple-DES encryption types: DES3-CBC-MD5(5),
   DES3-CBC-SHA1(7), and DES3-CBC-SHA1-KD(16) (updates [RFC3961] and
   [RFC4120]).

   Kerberos implementations and deployments SHOULD NOT implement or
   deploy the RC4 encryption type RC4-HMAC(23).

   Kerberos implementations and deployments SHOULD NOT implement or
   deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9),
   HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC3961] and
   [RFC4120]).

   Kerberos GSS mechanism implementations and deployments SHOULD NOT
   implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC
   SHA1 DES3 KD(0400).  (With all its content now deprecated, [RFC4757]
   has been made Historic by this document.)

   Kerberos GSS mechanism implementations and deployments SHOULD NOT
   implement or deploy the following SEAL_ALGs: RC4(1000) and
   DES3KD(0200).

   Per this document, [RFC4757] has been reclassified as Historic.

8.  Security Considerations

   This document is entirely about security considerations, namely that
   the use of the triple-DES and RC4 Kerberos encryption types is not
   secure, and they should not be used.







Kaduk & Short             Best Current Practice                 [Page 8]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


9.  IANA Considerations

   IANA has updated the "Kerberos Encryption Type Numbers" registry
   [IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are
   deprecated, with [RFC6649] as the reference and that 2) encryption
   types 5, 7, 16, and 23 are deprecated, with this document as the
   reference.

   Similarly, IANA has updated the "Kerberos Checksum Type Numbers"
   registry [IANA-KRB] to note that 1) checksum type values 1, 2, 3, 4,
   5, 6, and 8 are deprecated, with [RFC6649] as the reference, and that
   2) checksum type values 7, 12, and 13 are deprecated, with this
   document as the reference.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
              2005, <https://www.rfc-editor.org/info/rfc3961>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <https://www.rfc-editor.org/info/rfc4120>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [HEIMDAL]  Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS-
              API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation",
              <https://www.h5l.org/>.

   [IANA-KRB]
              IANA, "Kerberos Parameters",
              <https://www.iana.org/assignments/kerberos-parameters/>.

   [MITKRB5]  MIT, "Kerberos: The Network Authentication Protocol",
              <https://web.mit.edu/kerberos/>.



Kaduk & Short             Best Current Practice                 [Page 9]
^L
RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018


   [MS-NLMP]  Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM)
              Authentication Protocol", September 2017,
              <https://msdn.microsoft.com/en-us/library/cc236621.aspx>.

   [RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
              Kerberos Encryption Types Used by Microsoft Windows",
              RFC 4757, DOI 10.17487/RFC4757, December 2006,
              <https://www.rfc-editor.org/info/rfc4757>.

   [RFC6150]  Turner, S. and L. Chen, "MD4 to Historic Status",
              RFC 6150, DOI 10.17487/RFC6150, March 2011,
              <https://www.rfc-editor.org/info/rfc6150>.

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

   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,
              <https://www.rfc-editor.org/info/rfc7465>.

Acknowledgements

   Many people have contributed to the understanding of the weaknesses
   of these encryption types over the years, and they cannot all be
   named here.

Authors' Addresses

   Benjamin Kaduk
   Akamai Technologies

   Email: kaduk@mit.edu


   Michiko Short
   Microsoft Corporation

   Email: michikos@microsoft.com











Kaduk & Short             Best Current Practice                [Page 10]
^L