idnits 2.17.1 draft-ietf-krb-wg-des-die-die-die-04.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 RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. -- The draft header indicates that this document updates RFC4757, but the abstract doesn't seem to directly say this. It does mention RFC4757 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 RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- 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 (February 27, 2012) is 4441 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) ** Downref: Normative reference to an Historic RFC: RFC 4757 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Hornquist Astrand 3 Internet-Draft Apple, Inc 4 Updates: 1510, 1964, 4120, 4121, 4757 T. Yu 5 (if approved) MIT Kerberos Consortium 6 Intended status: BCP February 27, 2012 7 Expires: August 30, 2012 9 Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in 10 Kerberos 11 draft-ietf-krb-wg-des-die-die-die-04 13 Abstract 15 The Kerberos 5 network authentication protocol, originally specified 16 in RFC1510, can use the Data Encryption Standard (DES) for 17 encryption. Almost 30 years after first publishing DES, the National 18 Institute of Standards and Technology (NIST) finally withdrew the 19 standard in 2005, reflecting a long-established consensus that DES is 20 insufficiently secure. By 2008, commercial hardware costing less 21 than USD 15,000 could break DES keys in less than a day on average. 22 DES is long past its sell-by date. Accordingly, this document 23 updates RFC1964, RFC4120, RFC4121, and RFC4757 to deprecate the use 24 of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in 25 Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, 26 this document reclassifies RFC1510 as Historic. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 30, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 1. Requirements Notation 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 2. Introduction 68 The original specification of the Kerberos 5 network authentication 69 protocol [RFC1510] supports only the Data Encryption Standard (DES) 70 for encryption. For many years, the cryptographic community has 71 regarded DES as providing inadequate security, mostly because of its 72 small key size. Accordingly, this document reclassifies [RFC1510] 73 (obsoleted by [RFC4120]) as Historic, and updates current Kerberos- 74 related specifications [RFC1964], [RFC4120], and [RFC4121] to 75 deprecate the use of DES and other weak cryptographic algorithms in 76 Kerberos, including some unkeyed checksums and hashes, along with the 77 weak 56-bit "export strength" RC4 variant enctype of [RFC4757]. 79 3. Affected specifications 81 The original IETF specification of Kerberos 5 [RFC1510] only supports 82 DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the 83 Kerberos specification to include additional cryptographic 84 algorithms, but still permits the use of DES. [RFC3961] describes 85 the Kerberos cryptographic system and includes support for DES 86 encryption types, but it does not specify requirement levels for 87 them. 89 The specification of the Kerberos Generic Security Services 90 Application Programming Interface (GSS-API) mechanism [RFC1964] and 91 its updated version [RFC4121] define checksum and encryption 92 mechanisms based on DES. With the existence of newer encryption 93 types for Kerberos GSS-API defined in [RFC4121], Microsoft's RC4-HMAC 94 based GSS-API mechanism, and MIT's DES3 (which is not published as an 95 RFC), there is no need to support the old DES based integrity (SGN) 96 and confidentiality (SEAL) types. 98 [RFC4757] describes the RC4-HMAC encryption types used by Microsoft 99 Windows, and allows for a 56-bit "export strength" variant. (The 100 character constant "fortybits" used in the definition is a historical 101 reference and does not refer to the actual key size of the enctype.) 103 4. DES insecurity 105 The insecurity of DES has been evident for many years. Even around 106 the time of its first publication, cryptographers raised the 107 possibility that 56 bits was too small a key size for DES. The 108 National Institute of Standards and Technology (NIST) officially 109 withdrew DES in 2005 [DES-Withdrawal], and also announced a 110 transition period that ended on May 19, 2007 [DES-Transition-Plan]. 111 The IETF has also published its position in [RFC4772], in which the 112 recommendation summary is very clear: "don't use DES". 114 In 2006, researchers demonstrated the ability to brute force a DES 115 key in an average of less than 9 days using less than EUR 10,000 116 worth of hardware [Break-DES]. By 2008, a company was offering 117 hardware capable of breaking a DES key in less than a day on average 118 [DES-1day] that cost less than USD 15,000 [DES-crack]. Brute force 119 key searches of DES will only get faster and cheaper. (The 120 aforementioned company markets its device for one-click recovery of 121 lost DES keys.) It is clear that it is well past time to retire the 122 use of DES in Kerberos. 124 5. Recommendations 126 This document hereby removes the following RECOMMENDED types from 127 [RFC4120]: 128 Encryption: DES-CBC-MD5(3) 129 Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). 131 Kerberos implementations and deployments SHOULD NOT implement or 132 deploy the following single DES encryption types: DES-CBC-CRC(1), 133 DES-CBC-MD4(2), DES-CBC-MD5(3) (updates [RFC4120]). 135 Kerberos implementations and deployments SHOULD NOT implement or 136 deploy the following "export strength" RC4 variant encryption type: 137 RC4-HMAC-EXP(24) (updates [RFC4757]). This document does not add any 138 sort of requirement for conforming implementations to implement RC4- 139 HMAC(23). 141 Kerberos implementations and deployments SHOULD NOT implement or 142 deploy the following checksum types: CRC32(1), RSA-MD4(2), RSA-MD4- 143 DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8) 144 (updates [RFC4120]). 146 It is possible to safely use the RSA-MD5(7) checksum type, but only 147 with additional protection, such as the protection that an encrypted 148 Authenticator provides. Implementations MAY use RSA-MD5 inside an 149 encrypted Authenticator for backward compatibility with systems that 150 do not support newer checksum types (updates [RFC4120]). One example 151 is that some legacy systems only support RC4-HMAC(23) [RFC4757] for 152 encryption when DES is not available; these systems use RSA-MD5 153 checksums inside Authenticators encrypted with RC4-HMAC. 155 Kerberos GSS mechanism implementations and deployments SHOULD NOT 156 implement or deploy the following SGN ALG: DES MAC MD5(0000), 157 MD2.5(0100), DES MAC(0200) (updates [RFC1964]). 159 Kerberos GSS mechanism implementations and deployments SHOULD NOT 160 implement or deploy the following SEAL ALG: DES(0000) (updates 161 [RFC1964]). 163 The effect of the two last sentences is that this document deprecates 164 section 1.2 in [RFC1964]. 166 This document hereby reclassifies [RFC1510] as Historic. 168 6. Acknowledgements 170 Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif 171 Johansson, Simon Josefsson, and Martin Rex have read the document and 172 provided suggestions for improvements. Sam Hartman proposed moving 173 [RFC1510] to Historic. Michiko Short provided information about the 174 dates of end of support for Windows releases. 176 7. Security Considerations 178 Removing support for single DES improves security, because DES is 179 considered to be insecure. RC4-HMAC-EXP has a similarly inadequate 180 key size, so removing support for it also improves security. 182 Kerberos defines some encryption types that are either underspecified 183 or that only have number assignments but no specifications. 184 Implementations should make sure that they only implement and enable 185 secure encryption types. 187 The security considerations of [RFC4757] continue to apply to RC4- 188 HMAC, including the known weaknesses of RC4 and MD4, and this 189 document does not change the Informational status of [RFC4757] for 190 now. The main reason to not actively discourage the use of RC4-HMAC 191 is that it is the only encryption type that interoperates with older 192 versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. 193 These older versions of Microsoft Windows will likely be in use until 194 at least 2015. 196 8. IANA Considerations 198 There are no IANA Considerations for this document. 200 9. References 202 9.1. Normative References 204 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 205 RFC 1964, June 1996. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 211 Kerberos 5", RFC 3961, February 2005. 213 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 214 Kerberos Network Authentication Service (V5)", RFC 4120, 215 July 2005. 217 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 218 Version 5 Generic Security Service Application Program 219 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 220 July 2005. 222 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 223 Kerberos Encryption Types Used by Microsoft Windows", 224 RFC 4757, December 2006. 226 9.2. Informative References 228 [Break-DES] 229 Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., 230 and M. Schimmler, "How to break DES for EUR 8,980 - 231 SHARCS'06 - Special-purpose Hardware for Attacking 232 Cryptographic Systems", April 2006, . 235 [DES-1day] 236 SciEngines GmbH, "Break DES in less than a single day", . 240 [DES-Transition-Plan] 241 National Institute of Standards and Technology, "DES 242 Transition Plan", May 2005, . 245 [DES-Withdrawal] 246 National Institute of Standards and Technology, 247 "Announcing Approval of the Withdrawal of Federal 248 Information Processing Standard (FIPS) 46-3, Data 249 Encryption Standard (DES); FIPS 74, Guidelines for 250 Implementing and Using the NBS Data Encryption Standard; 251 and FIPS 81, DES Modes of Operation - Federal Register 252 Document 05-9945", 70 FR 28907-28908, May 2005, . 255 [DES-crack] 256 Scott, T., "DES Brute Force Cracking Efforts 1977 to 257 2010", 2010, . 260 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 261 Authentication Service (V5)", RFC 1510, September 1993. 263 [RFC4772] Kelly, S., "Security Implications of Using the Data 264 Encryption Standard (DES)", RFC 4772, December 2006. 266 Authors' Addresses 268 Love Hornquist Astrand 269 Apple, Inc 270 Cupertino 271 USA 273 Email: lha@apple.com 274 Tom Yu 275 MIT Kerberos Consortium 276 77 Massachusetts Ave 277 Cambridge, Massachusetts 278 USA 280 Email: tlyu@mit.edu