summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8429.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8429.txt')
-rw-r--r--doc/rfc/rfc8429.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8429.txt b/doc/rfc/rfc8429.txt
new file mode 100644
index 0000000..d318bba
--- /dev/null
+++ b/doc/rfc/rfc8429.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+