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