idnits 2.17.00 (12 Aug 2021) /tmp/idnits16758/draft-ietf-curdle-des-des-des-die-die-die-05.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 updates RFC4120, 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 directly say this. It does mention RFC3961 though, so this could be OK. 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 (September 18, 2017) is 1699 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) 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 Updates: 3961,4120 (if approved) M. Short 5 Intended status: Best Current Practice Microsoft Corporation 6 Expires: March 22, 2018 September 18, 2017 8 Deprecate 3DES and RC4 in Kerberos 9 draft-ietf-curdle-des-des-des-die-die-die-05 11 Abstract 13 The 3DES and RC4 encryption types are steadily weakening in 14 cryptographic strength, and the deprecation process should be begun 15 for their use in Kerberos. Accordingly, RFC 4757 is moved to 16 Historic status, as none of the encryption types it specifies should 17 be used, and RFC 3961 is updated to note the deprecation of the 18 triple-DES encryption types. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 22, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 56 3. Affected Specifications . . . . . . . . . . . . . . . . . . . 2 57 4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 3 58 5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 3 60 5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 4 61 5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 5 62 5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 5 63 6. 3DES Weakness . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Password-based Keys . . . . . . . . . . . . . . . . . . . 6 65 6.2. Block Size . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.3. Interoperability . . . . . . . . . . . . . . . . . . . . 6 67 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The 3DES and RC4 encryption types are steadily weakening in 79 cryptographic strength, and the deprecation process should be begun 80 for their use in Kerberos. Accordingly, RFC 4757 is moved to 81 Historic status, as none of the encryption types it specifies should 82 be used, and RFC 3961 is updated to note the deprecation of the 83 triple-DES encryption types. 85 2. Requirements Notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Affected Specifications 93 The RC4 Kerberos encryption types are specified in [RFC4757], which 94 is moved to historic. 96 The des3-cbc-sha1-kd encryption type is specified in [RFC3961]. 97 Additional 3DES encryption types are in use with no formal 98 specification, in particular des3-cbc-md5 and des3-cbc-sha1. These 99 unspecified encryption types are also deprecated by this document. 101 Though the RC4 and 3DES encryption types are still in use in some 102 deployments, the above status changes are made to discourage their 103 use. 105 4. Affected Encryption Types 107 The following encryption types are deprecated. The numbers are the 108 official identifiers; the names are only for convenience. 110 +----------------+--------------------------+ 111 | enctype number | enctype convenience name | 112 +----------------+--------------------------+ 113 | 5 | des3-cbc-md5 | 114 | | | 115 | 7 | des3-cbc-sha1 | 116 | | | 117 | 16 | des3-cbc-sha1-kd | 118 | | | 119 | 23 | rc4-hmac | 120 +----------------+--------------------------+ 122 5. RC4 Weakness 124 RC4's weakness as a TLS cipher due to statistical biases in the 125 keystream has been well-publicized [RFC7465], and these statistical 126 biases cause concern for any consumer of the RC4 cipher. However, 127 the RC4 Kerberos enctypes have additional flaws which reduce the 128 security of applications using them, including the weakness of the 129 password hashing algorithm, the reuse of key material across 130 protocols, and the lack of a salt when hashing the password. 132 5.1. Statistical Biases 134 The RC4 stream cipher is known to have statistical biases in its 135 output, which have led to practical attacks against protocols using 136 RC4, such as TLS ([RFC7465]). At least some of these attacks rely on 137 repeated encryptions of thousands of copies of the same plaintext; 138 whereas it is easy for malicious javascript in a website to cause 139 such traffic, it is unclear that there is an easy way to induce a 140 kerberized application to generate such repeated encryptions. The 141 statistical biases are most pronounced for earlier bits in the output 142 stream, which is somewhat mitigated by the use of a confounder in 143 kerberos messages -- the first 64 bits of plaintext are a random 144 confounder, and are thus of no use to an attacker who can retrieve 145 them. 147 Nonetheless, the statistical biases in the RC4 keystream extend well 148 past 64 bits, and provide potential attack surface to an attacker. 149 Continuing to use a known weak algorithm is inviting further 150 development of attacks. 152 5.2. Password Hash 154 Kerberos long-term keys can either be random (as might be used in a 155 service's keytab) or derived from a password (usable for individual 156 users to authenticate to a system). The specification for a Kerberos 157 encryption type must include a "string2key" algorithm for generating 158 a raw crypto key from a string (i.e., password). Modern encryption 159 types, such as those using the AES and Camellia block ciphers, use a 160 string2key function based on the PBKDF2 algorithm, which involves 161 many iterations of a cryptographic hash function, designed to 162 increase the computational effort required to perform a brute-force 163 password-guessing attack. There is an additional option to specify 164 an increased iteration count for a given principal, providing some 165 modicum of adaptability for increases in computing power. 167 It is also best practice, when deriving cryptographic secrets from 168 user passwords, to include a value which is unique to both the user 169 and the realm of authentication as input to the hash function; this 170 user-specific input is known as a "salt". The default salt for 171 Kerberos principals includes both the name of the principal and the 172 name of the realm, in accordance with these best practices. However, 173 the RC4 encryption types ignore the salt input to the string2key 174 function, which is a single iteration of the MD4 hash function 175 applied to the UTF-16 encoded password, with no salt at all. The MD4 176 hash function is very old, and is considered to be weak and 177 unsuitable for new cryptographic applications at this time. 178 [RFC6150] 180 The omission of a salt input to the hash is contrary to cryptographic 181 best practices, and allows an attacker to construct a "rainbow table" 182 of password hashes, which are applicable to all principals in all 183 Kerberos realms. Given the prevalance of poor-quality user-selected 184 password, it is likely that a rainbow table derived from a database 185 of common passwords would be able to compromise a sizable number of 186 Kerberos principals in any realm using RC4 encryption types for 187 password-derived keys. 189 5.3. Cross-Protocol Key Reuse 191 The selection of unsalted MD4 as the Kerberos string2key function was 192 deliberate, since it allowed systems to be converted in-place from 193 the old NTLM logon protocol [MS-NLMP] to use Kerberos. 195 Unfortunately, there still exist systems using NTLM for 196 authentication to applications, which can result in application 197 servers possessing the NT password hash of user passwords. Because 198 the RC4 string2key was chosen to be compatible with the NTLM scheme, 199 these application servers also possess the long-term Kerberos key for 200 those users even though the password is unknown. The cross-protocol 201 use of the long-term key/password hash was convenient for migrating 202 to Kerberos, but now provides a vulnerability in Kerberos as NTLM 203 continues to be used. 205 5.4. Interoperability Concerns 207 The RC4 Kerberos encryption type remains in use in many environments 208 because of interoperability requirements -- in those sites, RC4 is 209 the strongest enctype which allows two parties to use Kerberos to 210 communicate. In particular, the Kerberos implementions included with 211 Windows XP and Windows Server 2003 support only single-DES and RC4. 212 Since single-DES is deprecated ([RFC6649]), machines running those 213 operating systems must use RC4. 215 Similarly, there are cross-realm deployments where the cross-realm 216 key was initially established when one peer only supported RC4, or 217 where machines only supporting RC4 will need to obtain a cross-realm 218 Ticket-Granting Ticket. It can be difficult to inventory all clients 219 in a Kerberos realm and know what implementations will be used by 220 those client principals; this leads to concerns that disabling RC4 221 will cause breakage on machines that are unknown to the realm 222 administrators. 224 Fortunately, modern (i.e., supported) Kerberos implementations 225 support a secure alternative to RC4, in the form of AES. Windows has 226 supported AES since 2007-2008 with the release of Windows Vista and 227 Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported 228 AES (including the GSSAPI mechanism) since 2004 with the release of 229 version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005 230 with the release of version 0.7. Though there may still be issues 231 running ten-year-old unsupported software in mixed environments with 232 new software, issues of that sort seem unlikely to be unique to 233 Kerberos, and the aministrators of such environments are expected to 234 be capable of devising workarounds. 236 6. 3DES Weakness 238 The flaws in triple-DES as used for Kerberos are not quite as damning 239 as those in RC4, but there is still ample justification for 240 deprecating its use. As is the case for the RC4 enctypes, the 241 string2key algorithm is weak. Additionally, the 3DES encryption 242 types were not implemented in all Kerberos implementations, and the 243 64-bit block size may be problematic in some environments. 245 6.1. Password-based Keys 247 The n-fold-based string2key function used by the des3-cbc-sha1-kd 248 encryption type is an ad-hoc construction that should not be 249 considered cryptographically sound. It is known to not provide 250 effective mixing of the input bits, and is computationally easy to 251 evaluate. As such, it does not slow down brute-force attacks in the 252 way that the computationally demanding PBKDF2 algorithm used by more 253 modern encryption types does. The salt is used by des3-cbc-sha1-kd's 254 string2key, in contrast to RC4, but a brute-force dictionary attack 255 on common passwords may still be feasible. 257 6.2. Block Size 259 Because triple-DES is based on the single-DES primitive, just using 260 additional key material and nested encryption, it inherits the 64-bit 261 cipher block size from single-DES. As a result, an attacker who can 262 collect approximately 2**32 blocks of ciphertext has a good chance of 263 finding a cipher block collision (the "birthday attack"), which would 264 potentially reveal a couple of blocks of plaintext. 266 A cipher block collision would not necessarily cause the key itself 267 to be leaked, so the plaintext revealed by such a collision would be 268 limited. For some sites, that may be an acceptable risk, but it is 269 still considered a weakness in the encryption type. 271 6.3. Interoperability 273 The triple-DES encryption types were implemented by MIT Kerberos 274 early in its development (ca. 1999) and present in the 1.2 release, 275 but were superseded when encryption types 17 and 18 (AES) were 276 implemented by 2003 and present in the 1.3 release. The Heimdal 277 Kerberos implementation also provided a version of 3DES in 1999 278 (though the GSSAPI portions remained non-interoperable with MIT for 279 some time after that), and gained support for AES in 2005 with its 280 0.7 release. Both Heimdal and MIT krb5 have supported the AES 281 enctypes for some 12 years, and it is expected that deployments that 282 support 3DES but not AES are quite rare. 284 The Kerberos implementation in Microsoft Windows does not currently 285 and has never implemented the 3DES encryption type. Support for AES 286 was introduced with Windows Vista and Windows Server 2008; older 287 versions such as Windows XP and Windows Server 2003 only supported 288 the RC4 encryption types. 290 The 3DES encryption type offers very slow encryption, especially 291 compared to the performance of AES using the hardware accelleration 292 available in modern CPUs. There are no areas where it offers 293 advantages over other encryption types except in the rare case where 294 AES is not available. 296 7. Recommendations 298 This document hereby removes the following RECOMMENDED types from 299 [RFC4120]: 301 Encryption: DES3-CBC-SHA1-KD 303 Checksum: HMAC-SHA1-DES3-KD 305 Kerberos implementations and deployments SHOULD NOT implement or 306 deploy the following triple-DES encryption types: DES3-CBC-MD5(5), 307 DES3-CBC-SHA1(7), and DES3-CBC-SHA1-KD(16) (updates [RFC3961], 308 [RFC4120]). 310 Kerberos implementations and deployments SHOULD NOT implement or 311 deploy the RC4 encryption type RC4-HMAC(23). 313 Kerberos implementations and deployments SHOULD NOT implement or 314 deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9), 315 HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC3961], 316 [RFC4120]). 318 Kerberos GSS mechanism implementations and deployments SHOULD NOT 319 implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC 320 SHA1 DES3 KD (updates [RFC4757]). 322 Kerberos GSS mechanism implementations and deployments SHOULD NOT 323 implement or deploy the following SEAL_ALGs: RC4(1000) and 324 DES3KD(0400). 326 This document recommends the reclassification of [RFC4757] as 327 Historic. 329 8. Security Considerations 331 This document is entirely about security considerations, namely that 332 the use of the 3DES and RC4 Kerberos encryption types is not secure, 333 and they should not be used. 335 9. IANA Considerations 337 IANA is requested to update the registry of Kerberos Encryption Type 338 Numbers [IANA-KRB] to note that encryption types 1, 2, 3, and 24 are 339 deprecated, with RFC 6649 ([RFC6649]) as the reference, and that 340 encryption types 5, 7, 16, and 23 are deprecated, with this document 341 as the reference. 343 Similarly, IANA is requested to update the registry of Kerberos 344 Checksum Type Numbers [IANA-KRB] to note that checksum types 1, 2, 3, 345 4, 5, 6, and 8 are deprecated, with RFC 6649 as the reference, and 346 that checksum types 7, 12, and 13 are deprecated, with this document 347 as the reference. 349 10. References 351 10.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 359 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 360 2005, . 362 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 363 Kerberos Network Authentication Service (V5)", RFC 4120, 364 DOI 10.17487/RFC4120, July 2005, 365 . 367 10.2. Informative References 369 [HEIMDAL] Heimdal Project, "Heimdal Kerberos Implementation", April 370 2017, . 372 [IANA-KRB] 373 Internet Assigned Numbers Authority, "IANA Kerberos 374 Parameters Registry", March 2017, 375 . 378 [MITKRB5] MIT, "MIT Kerberos Implementation", March 2017, 379 . 381 [MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) 382 Authentication Protocol", May 2014, 383 . 385 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 386 Kerberos Encryption Types Used by Microsoft Windows", 387 RFC 4757, DOI 10.17487/RFC4757, December 2006, 388 . 390 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 391 RFC 6150, DOI 10.17487/RFC6150, March 2011, 392 . 394 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 395 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 396 BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012, 397 . 399 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 400 DOI 10.17487/RFC7465, February 2015, 401 . 403 Appendix A. Acknowledgements 405 Many people have contributed to the understanding of the weaknesses 406 of these encryption types over the years, and they cannot all be 407 named here. 409 Authors' Addresses 411 Benjamin Kaduk 412 Akamai Technologies 414 Email: kaduk@mit.edu 416 Michiko Short 417 Microsoft Corporation 419 Email: michikos@microsoft.com