idnits 2.17.1 draft-kaduk-kitten-des-des-des-die-die-die-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4757, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3961, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3961, updated by this document, for RFC5378 checks: 2002-01-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 30, 2017) is 2583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Kaduk 3 Internet-Draft Akamai 4 Obsoletes: 4757 (if approved) M. Short 5 Updates: 3961 (if approved) Microsoft Corporation 6 Intended status: Informational March 30, 2017 7 Expires: October 1, 2017 9 Deprecate 3DES and RC4 in Kerberos 10 draft-kaduk-kitten-des-des-des-die-die-die-01 12 Abstract 14 The 3DES and RC4 encryption types are steadily weakening in 15 cryptographic strength, and the deprecation process should be begun 16 for their use in Kerberos. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 1, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 54 3. Affected Specifications . . . . . . . . . . . . . . . . . . . 2 55 4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 3 56 5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 3 58 5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 4 59 5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 4 60 5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 5 61 6. 3DES Weakness . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Password-based Keys . . . . . . . . . . . . . . . . . . . 5 63 6.2. Interoperability . . . . . . . . . . . . . . . . . . . . 6 64 6.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 10.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The 3DES and RC4 encryption types are steadily weakening in 77 cryptographic strength, and the deprecation process should be begun 78 for their use in Kerberos. 80 2. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Affected Specifications 88 The RC4 Kerberos encryption types are specified in [RFC4757], which 89 is moved to historic. 91 The des3-cbc-sha1-kd encryption type is specified in [RFC3961]. 92 Additional 3DES encryption types are in use with no formal 93 specification, in particular des3-cbc-md5 and des3-cbc-sha1. These 94 unspecified encryption types are also deprecated by this document. 96 4. Affected Encryption Types 98 The following encryption types are deprecated. The numbers are the 99 official identifiers; the names are only for convenience. 101 +----------------+--------------------------+ 102 | enctype number | enctype convenience name | 103 +----------------+--------------------------+ 104 | 5 | des3-cbc-md5 | 105 | | | 106 | 7 | des3-cbc-sha1 | 107 | | | 108 | 16 | des3-cbc-sha1-kd | 109 | | | 110 | 23 | rc4-hmac | 111 +----------------+--------------------------+ 113 5. RC4 Weakness 115 RC4's weakness as a TLS cipher due to statistical biases in the 116 keystream has been well-publicized [RFC7465], and these statistical 117 biases cause concern for any consumer of the RC4 cipher. However, 118 the RC4 Kerberos enctypes have additional flaws which reduce the 119 security of applications using them, including the weakness of the 120 password hashing algorithm, the reuse of key material across 121 protocols, and the lack of a salt when hashing the password. 123 5.1. Statistical Biases 125 The RC4 stream cipher is known to have statistical biases in its 126 output, which have led to practical attacks against protocols using 127 RC4, such as TLS ([RFC7465]). These attacks seem to rely on repeated 128 encryptions of thousands of copies of the same plaintext; whereas it 129 is easy for malicious javascript in a website to cause such traffic, 130 it is unclear that there is an easy way to induce a kerberized 131 application to generate such repeated encryptions. The statistical 132 biases are most pronounced for earlier bits in the output stream, 133 which is somewhat mitigated by the use of a confounder in kerberos 134 messages -- the first 64 bits of plaintext are a random confounder, 135 and are thus of no use to an attacker who can retrieve them. 137 Nonetheless, the statistical biases in the RC4 keystream extend well 138 past 64 bits, and provide potential attack surface to an attacker. 139 Continuing to use a known weak algorithm is inviting further 140 development of attacks. 142 5.2. Password Hash 144 Kerberos long-term keys can either be random (as might be used in a 145 service's keytab) or derived from a password (usable for individual 146 users to authenticate to a system). The specification for a Kerberos 147 encryption type must include a "string2key" algorithm for generating 148 a raw crypto key from a string (i.e., password). Modern encryption 149 types such as those using the AES and Camellia block ciphers use a 150 string2key function based on the PBKDF2 algorithm, which involves 151 many iterations of a cryptographic hash function, designed to 152 increase the computational effort required to perform a brute-force 153 password-guessing attack. There is an additional option to specify 154 an increased iteration count for a given principal, providing some 155 modicum of adaptability for increases in computing power. 157 It is also best practice when deriving cryptographic secrets from 158 user passwords, to include a value which is unique to both the user 159 and the realm of authentication as input to the has function; this 160 user-specific input is known as a "salt". The default salt for 161 Kerberos principals includes both the name of the principal and the 162 name of the realm, in accordance with these best practices. However, 163 the RC4 encryption types ignore the salt input to the string2key 164 function, which is a single iteration of the MD4 HMAC function 165 applied to the UTF-16 encoded password, with no salt at all. The MD4 166 hash function is very old, and is considered to be weak and 167 unsuitable for new cryptographic applications at this time. 168 [RFC6150] 170 The omission of a salt input to the hash is contrary to cryptographic 171 best practices, and allows an attacker to construct a "rainbow table" 172 of password hashes, which are applicable to all principals in all 173 Kerberos realms. Given the prevalance of poor-quality user-selected 174 password, it is likely that a rainbow table derived from a database 175 of common passwords would be able to compromise a sizable number of 176 Kerberos principals in any realm using RC4 encryption types for 177 password-derived keys. 179 5.3. Cross-Protocol Key Reuse 181 The selection of unsalted MD4 as the Kerberos string2key function was 182 deliberate, since it allowed systems to be converted in-place from 183 the old NTLM logon protocol [MS-NLMP] to use Kerberos. 185 Unfortunately, there still exist systems using NTLM for 186 authentication to applications, which can result in application 187 servers possessing the NT password hash of user passwords. Because 188 the RC4 string2key was chosen to be compatible with the NTLM scheme, 189 this means that these application servers also possess the long-term 190 Kerberos key for those users (even though the password is unknown). 191 The cross-protocol use of the long-term key/password hash was 192 convenient for migrating to Kerberos, but now provides a 193 vulnerability in Kerberos as NTLM continues to be used. 195 5.4. Interoperability Concerns 197 The RC4 Kerberos encryption type remains in use in many environments 198 because of interoperability requirements -- in those sites, RC4 is 199 the strongest enctype which allows two parties to use Kerberos to 200 communicate. In particular, the Kerberos implementions included with 201 Windows XP and Windows Server 2003 support only single-DES and RC4. 202 Since single-DES is deprecated ([RFC6649]), machines running those 203 operating systems must use RC4. 205 Similarly, there are cross-realm situations where the cross-realm key 206 was initially established when one peer only supported RC4, or where 207 machines only supporting RC4 will need to obtain a cross-realm TGT. 208 It can be difficult to inventory all clients in a Kerberos realm and 209 know what implementations will be used by those client principals; 210 this leads to concerns that disabling RC4 will cause breakage on 211 machines that are unknown to the realm administrators. 213 However, both Windows XP and Windows Server 2003 are already out of 214 their official support periods. It is now believed that all machines 215 that might be broken by disabling RC4 are unsupported, and concerns 216 about breaking them will be reduced. That should facilitate the 217 removal of RC4 from common use. 219 6. 3DES Weakness 221 The flaws in triple-DES as used for Kerberos are not quite as damning 222 as those in RC4, but there is still ample justification for 223 deprecating their use. As is the case for the RC4 enctypes, the 224 string2key algorithm is weak. Additionally, the 3DES encryption 225 types were never implemented in all Kerberos implementations, and the 226 64-bit blocksize may be problematic in some environments. 228 6.1. Password-based Keys 230 The string2key function used by the des-cbc-sha1-kd encryption type 231 is essentially just the same n-fold algorithm used by the single-DES 232 family of enctypes. It is known to not provide effective mixing of 233 the input bits, and is computationally easy to evaluate. As such, it 234 does not slow down brute-force attacks in the way that the 235 computationally demanding PBKDF2 algorithm used by more modern 236 encryption types does. The salt is used by des-cbc-sha1-kd's 237 string2key, in contrast to RC4, but a brute-force dictionary attack 238 on common passwords may still be feasible. 240 6.2. Interoperability 242 The triple-DES encryption types were implemented by MIT Kerberos 243 early in its development, but encryption types 17 and 18 (AES) 244 quickly followed, so there are only a small number of such 245 deployments which support 3DES but not AES. Similarly, the Heimdal 246 Kerberos implementation provided 3DES shortly followed by AES, and 247 has provided AES for nearly ten years. 249 The Kerberos implementation in Microsoft Windows does not currently 250 and has never implemented the 3DES encryption type. Support for AES 251 was introduced with Windows Vista and Windows Server 2008; older 252 versions such as Windows XP and Windows Server 2003 only supported 253 the RC4 encryption types. 255 The 3DES encryption type offers very slow encryption, especially 256 compared to the performance of AES using the hardware accelleration 257 available in modern CPUs. There are no areas where it offers 258 advantages over other encryption types except in the rare case where 259 AES is not available. 261 6.3. Block Size 263 Because triple-DES is based on the single-DES primitive, just using 264 additional key material and nested encryption, it inherits the 64-bit 265 cipher block size from single-DES. As a result, an attacker who can 266 collect approximately 2**32 blocks of ciphertext has a good chance of 267 finding a cipher block collision (the "birthday attack"), which would 268 potentially reveal a couple blocks of plaintext. 270 A cipher block collision would not necessarily cause the key itself 271 to be leaked, so the plaintext revealed by such a collision would be 272 limited. For some sites, that may be an acceptable risk, but it is 273 still considered a weakness in the encryption type. 275 7. Recommendations 277 This document hereby removes the following RECOMMENDED types from 278 [RFC4120]: 280 Encryption: DES3-CBC-SHA1-KD 282 Checksum: HMAC-SHA1-DES3-KD 283 Kerberos implementations and deployments SHOULD NOT implement or 284 deploy the following triple-DES encryption types: DES3-CBC-MD5(5), 285 DES3-CBC-SHA1(7), and DES3-CBC-SHA1-KD(16) (updates [RFC4120]). 287 Kerberos implementations and deployments SHOULD NOT implement or 288 deploy the RC4 encryption type RC4-HMAC(23). 290 Kerberos implementations and deployments SHOULD NOT implement or 291 deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9), 292 HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC4120]). 294 Kerberos GSS mechanism implementations and deployments SHOULD NOT 295 implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC 296 SHA1 DES3 KD (updates [RFC4757]). 298 Kerberos GSS mechanism implementations and deployments SHOULD NOT 299 implement or deploy the following SEAL_ALGs: RC4(1000) and 300 DES3KD(0400). 302 This document recommends the reclassification of [RFC4757] as 303 Historic. 305 8. Security Considerations 307 This document is entirely about security considerations, namely that 308 the use of the 3DES and RC4 Kerberos encryption types is not secure, 309 and they should not be used. 311 9. IANA Considerations 313 IANA is requested to update the registry of Kerberos Encryption Type 314 Numbers to note that encryption types 1, 2, 3, and 24 are deprecated, 315 with RFC 6649 ([RFC6649]) as the reference, and that encryption types 316 5, 7, 16, and 23 are deprecated, with this document as the reference. 318 Similarly, IANA Is requested to update the registry of Kerberos 319 Checksum Type Numbers to note that checksum types 1, 2, 3, 4, 5, 6, 320 and 8 are deprecated, with RFC 6649 as the reference, and that 321 checksum types 7, 12, and 13 are deprecated, with this document as 322 the reference. 324 10. References 326 10.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 334 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 335 2005, . 337 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 338 Kerberos Network Authentication Service (V5)", RFC 4120, 339 DOI 10.17487/RFC4120, July 2005, 340 . 342 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 343 RFC 6150, DOI 10.17487/RFC6150, March 2011, 344 . 346 10.2. Informative References 348 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 349 Kerberos Encryption Types Used by Microsoft Windows", 350 RFC 4757, DOI 10.17487/RFC4757, December 2006, 351 . 353 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 354 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 355 BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012, 356 . 358 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 359 DOI 10.17487/RFC7465, February 2015, 360 . 362 [MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) 363 Authentication Protocol", May 2014. 365 Appendix A. Acknowledgements 367 Many people have contributed to the understanding of the weaknesses 368 of these encryption types over the years, and they cannot all be 369 named here. 371 Authors' Addresses 372 Benjamin Kaduk 373 Akamai Technologies 375 Email: kaduk@mit.edu 377 Michiko Short 378 Microsoft Corporation 380 Email: michikos@microsoft.com