idnits 2.17.1 draft-ietf-krb-wg-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 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 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 8, 2012) is 4460 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) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 0 errors (**), 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 T. Yu 5 (if approved) MIT Kerberos Consortium 6 Intended status: Standards Track February 8, 2012 7 Expires: August 11, 2012 9 Deprecate DES support for Kerberos 10 draft-ietf-krb-wg-des-die-die-die-01 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 also reclassifies RFC1510 as Historic. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 11, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Requirements Notation 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 2. Introduction 66 The original specification of the Kerberos 5 network authentication 67 protocol [RFC1510] supports only the Data Encryption Standard (DES) 68 for encryption. For many years, the cryptographic community has 69 regarded DES as providing inadequate security. Accordingly, this 70 document reclassifies [RFC1510] (obsoleted by [RFC4120]) as Historic, 71 and updates current Kerberos-related specifications [RFC1964], 72 [RFC4120], and [RFC4121] to deprecate the use of DES in Kerberos. 74 3. Affected specifications 76 The original IETF specification of Kerberos 5 [RFC1510] only supports 77 DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the 78 Kerberos specification to include additional cryptographic 79 algorithms, but still permits the use of DES. 81 The specification of the Kerberos Generic Security Services 82 Application Programming Interface (GSS-API) mechanism [RFC1964] and 83 its updated version [RFC4121] define checksum and encryption 84 mechanisms based on DES. With the existence of newer encryption 85 types for Kerberos GSS-API defined in [RFC4121], Microsoft's ARCFOUR- 86 HMAC based GSS-API mechanism, and MIT's DES3, there is no need to 87 support the old DES based integrity (SGN) and confidentiality (SEAL) 88 types. 90 4. DES insecurity 92 The insecurity of DES has been evident for many years. The National 93 Institute of Standards and Technology (NIST) officially withdrew DES 94 in 2005 [DES-Withdrawal], and also announced a transition period that 95 ended on May 19, 2007 [DES-Transition-Plan]. The IETF has also 96 published its position in [RFC4772], in which the recommendation 97 summary is very clear: "don't use DES". 99 In 2006, researchers demonstrated the ability to brute force a DES 100 key in an average of less than 9 days using less than EUR 10,000 101 worth of hardware [Break-DES]. By 2008, a company was offering 102 hardware capable of breaking a DES key in less than a day on average 103 [DES-1day] that cost less than USD 15,000 [DES-crack]. Brute force 104 key searches of DES will only get faster and cheaper. (The 105 aforementioned company markets its device for one-click recovery of 106 lost DES keys.) It is clear that it is well past time to retire the 107 use of DES in Kerberos. 109 5. Recommendations 111 This document hereby removes the following RECOMMENDED types from 112 [RFC4120]: 113 Encryption: DES-CBC-MD5(3) 114 Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). 116 Kerberos implementations and deployments SHOULD NOT implement the 117 single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC- 118 MD5(3). 120 Kerberos implementations and deployments SHOULD NOT implement the 121 checksum types: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), 122 DES-MAC-K(5), RSA-MD4-MAC-K(6), RSA-MD5-DES(8). 124 It is possible to safely use the RSA-MD5(7) checksum type, but only 125 with additional protection, such as the protection that an encrypted 126 Authenticator provides. Implementations MAY use RSA-MD5 inside an 127 encrypted Authenticator for backward compatibility with systems that 128 do not support newer checksum types. One example is that some legacy 129 systems only support ARCFOUR-HMAC-MD5 for encryption when DES is not 130 available; these systems use RSA-MD5 checksums inside Authenticators 131 encrypted with ARCFOUR-HMAC-MD5. 133 Kerberos GSS mechanism implementations and deployments SHOULD NOT 134 implement the SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES MAC(0200) 135 (updates [RFC1964]). 137 Kerberos GSS mechanism implementations and deployments SHOULD NOT 138 implement the SEAL ALG: DES(0000) (updates [RFC1964]). 140 The effect of the two last sentences is that this document deprecates 141 section 1.2 in [RFC1964]. 143 This document hereby reclassifies [RFC1510] as Historic. 145 6. Acknowledgements 147 Jeffrey Hutzelman, Simon Josefsson, Mattias Amnefelt, Leif Johansson, 148 and Ran Atkinson have read the document and provided suggestions for 149 improvements. Sam Hartman proposed moving [RFC1510] to Historic. 151 7. Security Considerations 153 Removing support for single DES improves security, because DES is 154 considered to be insecure. 156 Kerberos defines some encryption types that are either underspecified 157 or that only have number assignments but no specifications. 158 Implementations should make sure that they only implement and enable 159 secure encryption types. 161 RC4, used in ARCFOUR-HMAC, is considered weak; however, the use in 162 Kerberos is vetted and considered secure for now. The main reason to 163 not actively discourage the use of ARCFOUR-HMAC is that it is the 164 only encryption type that interoperates with older versions of 165 Microsoft Windows once DES is removed. 167 8. IANA Considerations 169 There are no IANA Considerations for this document. 171 9. References 173 9.1. Normative References 175 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 176 RFC 1964, June 1996. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 182 Kerberos Network Authentication Service (V5)", RFC 4120, 183 July 2005. 185 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 186 Version 5 Generic Security Service Application Program 187 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 188 July 2005. 190 9.2. Informative References 192 [Break-DES] 193 Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., 194 and M. Schimmler, "How to break DES for EUR 8,980 - 195 SHARCS'06 - Special-purpose Hardware for Attacking 196 Cryptographic Systems", April 2006, . 199 [DES-1day] 200 SciEngines GmbH, "Break DES in less than a single day", . 204 [DES-Transition-Plan] 205 National Institute of Standards and Technology, "DES 206 Transition Plan", May 2005, . 209 [DES-Withdrawal] 210 National Institute of Standards and Technology, 211 "Announcing Approval of the Withdrawal of Federal 212 Information Processing Standard (FIPS) 46-3, Data 213 Encryption Standard (DES); FIPS 74, Guidelines for 214 Implementing and Using the NBS Data Encryption Standard; 215 and FIPS 81, DES Modes of Operation - Federal Register 216 Document 05-9945", 70 FR 28907-28908, May 2005, . 219 [DES-crack] 220 Scott, T., "DES Brute Force Cracking Efforts 1977 to 221 2010", 2010, . 224 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 225 Authentication Service (V5)", RFC 1510, September 1993. 227 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 228 Kerberos 5", RFC 3961, February 2005. 230 [RFC4772] Kelly, S., "Security Implications of Using the Data 231 Encryption Standard (DES)", RFC 4772, December 2006. 233 Authors' Addresses 235 Love Hornquist Astrand 236 Apple, Inc 237 Cupertino 238 USA 240 Email: lha@apple.com 242 Tom Yu 243 MIT Kerberos Consortium 244 77 Massachusetts Ave 245 Cambridge, Massachusetts 246 USA 248 Email: tlyu@mit.edu