From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8429.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc8429.txt (limited to 'doc/rfc/rfc8429.txt') 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, + . + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February + 2005, . + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + DOI 10.17487/RFC4120, July 2005, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +10.2. Informative References + + [HEIMDAL] Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS- + API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation", + . + + [IANA-KRB] + IANA, "Kerberos Parameters", + . + + [MITKRB5] MIT, "Kerberos: The Network Authentication Protocol", + . + + + +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, + . + + [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, + . + + [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", + RFC 6150, DOI 10.17487/RFC6150, March 2011, + . + + [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, + . + + [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, + DOI 10.17487/RFC7465, February 2015, + . + +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] + -- cgit v1.2.3