idnits 2.17.1 draft-ietf-krb-wg-des-die-die-die-02.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. -- The draft header indicates that this document updates RFC4121, but the abstract doesn't seem to directly say this. It does mention RFC4121 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 9, 2012) is 4452 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 (==), 6 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: Standards Track February 9, 2012 7 Expires: August 12, 2012 9 Deprecate DES support for Kerberos 10 draft-ietf-krb-wg-des-die-die-die-02 12 Abstract 14 The Kerberos 5 network authentication protocol, originally specified 15 in RFC1510, can use the Data Encryption Standard (DES) for 16 encryption. Almost 30 years after first publishing DES, the National 17 Institute of Standards and Technology (NIST) finally withdrew the 18 standard in 2005, reflecting a long-established consensus that DES is 19 insufficiently secure. By 2008, commercial hardware costing less 20 than USD 15,000 could break DES keys in less than a day on average. 21 DES is long past its sell-by date. Accordingly, this document 22 updates RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in 23 Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, 24 this document reclassifies RFC1510 as Historic. This document also 25 deprecates the weak "export strength" RC4 enctype of RFC4757. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 12, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Requirements Notation 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Introduction 67 The original specification of the Kerberos 5 network authentication 68 protocol [RFC1510] supports only the Data Encryption Standard (DES) 69 for encryption. For many years, the cryptographic community has 70 regarded DES as providing inadequate security. Accordingly, this 71 document reclassifies [RFC1510] (obsoleted by [RFC4120]) as Historic, 72 and updates current Kerberos-related specifications [RFC1964], 73 [RFC4120], and [RFC4121] to deprecate the use of DES in Kerberos. 74 This document also deprecates the weak "export strength" RC4 enctype 75 of [RFC4757]. 77 3. Affected specifications 79 The original IETF specification of Kerberos 5 [RFC1510] only supports 80 DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the 81 Kerberos specification to include additional cryptographic 82 algorithms, but still permits the use of DES. [RFC3961] describes 83 the Kerberos cryptographic system and includes support for DES 84 encryption types, but it does not specify requirement levels for 85 them. 87 The specification of the Kerberos Generic Security Services 88 Application Programming Interface (GSS-API) mechanism [RFC1964] and 89 its updated version [RFC4121] define checksum and encryption 90 mechanisms based on DES. With the existence of newer encryption 91 types for Kerberos GSS-API defined in [RFC4121], Microsoft's RC4-HMAC 92 based GSS-API mechanism, and MIT's DES3, there is no need to support 93 the old DES based integrity (SGN) and confidentiality (SEAL) types. 95 [RFC4757] describes the RC4-HMAC encryption types used by Microsoft 96 Windows, and allows for a 56-bit "export strength" variant. (The 97 character constant "fortybits" used in the definition is a historical 98 reference and does not refer to the actual key size of the enctype.) 100 4. DES insecurity 102 The insecurity of DES has been evident for many years. The National 103 Institute of Standards and Technology (NIST) officially withdrew DES 104 in 2005 [DES-Withdrawal], and also announced a transition period that 105 ended on May 19, 2007 [DES-Transition-Plan]. The IETF has also 106 published its position in [RFC4772], in which the recommendation 107 summary is very clear: "don't use DES". 109 In 2006, researchers demonstrated the ability to brute force a DES 110 key in an average of less than 9 days using less than EUR 10,000 111 worth of hardware [Break-DES]. By 2008, a company was offering 112 hardware capable of breaking a DES key in less than a day on average 113 [DES-1day] that cost less than USD 15,000 [DES-crack]. Brute force 114 key searches of DES will only get faster and cheaper. (The 115 aforementioned company markets its device for one-click recovery of 116 lost DES keys.) It is clear that it is well past time to retire the 117 use of DES in Kerberos. 119 5. Recommendations 121 This document hereby removes the following RECOMMENDED types from 122 [RFC4120]: 123 Encryption: DES-CBC-MD5(3) 124 Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). 126 Kerberos implementations and deployments SHOULD NOT implement the 127 following single DES encryption types: DES-CBC-CRC(1), DES-CBC- 128 MD4(2), DES-CBC-MD5(3) (updates [RFC4120]). 130 Kerberos implementations and deployments SHOULD NOT implement the 131 following "export strength" RC4 encryption type: RC4-HMAC-EXP(24) 132 (updates [RFC4757]). 134 Kerberos implementations and deployments SHOULD NOT implement the 135 following checksum types: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES- 136 MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8) (updates 137 [RFC4120]). 139 It is possible to safely use the RSA-MD5(7) checksum type, but only 140 with additional protection, such as the protection that an encrypted 141 Authenticator provides. Implementations MAY use RSA-MD5 inside an 142 encrypted Authenticator for backward compatibility with systems that 143 do not support newer checksum types (updates [RFC4120]). One example 144 is that some legacy systems only support RC4-HMAC(23) [RFC4757] for 145 encryption when DES is not available; these systems use RSA-MD5 146 checksums inside Authenticators encrypted with RC4-HMAC. 148 Kerberos GSS mechanism implementations and deployments SHOULD NOT 149 implement the following SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES 150 MAC(0200) (updates [RFC1964]). 152 Kerberos GSS mechanism implementations and deployments SHOULD NOT 153 implement the following SEAL ALG: DES(0000) (updates [RFC1964]). 155 The effect of the two last sentences is that this document deprecates 156 section 1.2 in [RFC1964]. 158 This document hereby reclassifies [RFC1510] as Historic. 160 6. Acknowledgements 162 Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif 163 Johansson, and Simon Josefsson have read the document and provided 164 suggestions for improvements. Sam Hartman proposed moving [RFC1510] 165 to Historic. 167 7. Security Considerations 169 Removing support for single DES improves security, because DES is 170 considered to be insecure. 172 Kerberos defines some encryption types that are either underspecified 173 or that only have number assignments but no specifications. 174 Implementations should make sure that they only implement and enable 175 secure encryption types. 177 RC4, used in RC4-HMAC, is considered weak; however, the use in 178 Kerberos is vetted and considered secure for now. The main reason to 179 not actively discourage the use of RC4-HMAC is that it is the only 180 encryption type that interoperates with older versions of Microsoft 181 Windows once DES and RC4-HMAC-EXP are removed. 183 8. IANA Considerations 185 There are no IANA Considerations for this document. 187 9. References 189 9.1. Normative References 191 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 192 RFC 1964, June 1996. 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 198 Kerberos 5", RFC 3961, February 2005. 200 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 201 Kerberos Network Authentication Service (V5)", RFC 4120, 202 July 2005. 204 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 205 Version 5 Generic Security Service Application Program 206 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 207 July 2005. 209 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 210 Kerberos Encryption Types Used by Microsoft Windows", 211 RFC 4757, December 2006. 213 9.2. Informative References 215 [Break-DES] 216 Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., 217 and M. Schimmler, "How to break DES for EUR 8,980 - 218 SHARCS'06 - Special-purpose Hardware for Attacking 219 Cryptographic Systems", April 2006, . 222 [DES-1day] 223 SciEngines GmbH, "Break DES in less than a single day", . 227 [DES-Transition-Plan] 228 National Institute of Standards and Technology, "DES 229 Transition Plan", May 2005, . 232 [DES-Withdrawal] 233 National Institute of Standards and Technology, 234 "Announcing Approval of the Withdrawal of Federal 235 Information Processing Standard (FIPS) 46-3, Data 236 Encryption Standard (DES); FIPS 74, Guidelines for 237 Implementing and Using the NBS Data Encryption Standard; 238 and FIPS 81, DES Modes of Operation - Federal Register 239 Document 05-9945", 70 FR 28907-28908, May 2005, . 242 [DES-crack] 243 Scott, T., "DES Brute Force Cracking Efforts 1977 to 244 2010", 2010, . 247 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 248 Authentication Service (V5)", RFC 1510, September 1993. 250 [RFC4772] Kelly, S., "Security Implications of Using the Data 251 Encryption Standard (DES)", RFC 4772, December 2006. 253 Authors' Addresses 255 Love Hornquist Astrand 256 Apple, Inc 257 Cupertino 258 USA 260 Email: lha@apple.com 262 Tom Yu 263 MIT Kerberos Consortium 264 77 Massachusetts Ave 265 Cambridge, Massachusetts 266 USA 268 Email: tlyu@mit.edu