idnits 2.17.1 draft-lha-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 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 RFC3961, but the abstract doesn't seem to mention this, which it should. 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 (July 10, 2010) is 5031 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: 1964, 1510, 3961, 4120, July 10, 2010 5 4121 (if approved) 6 Intended status: Standards Track 7 Expires: January 11, 2011 9 Deprecate DES support for Kerberos 10 draft-lha-des-die-die-die-05 12 Abstract 14 A long long time ago Data Encryption Standard (DES) was standardized. 15 Some 30 years later (2003) is was withdrawn as a standard by National 16 Institute of Standards and Technology (NIST), today 6 years later, 17 its time for DES to finally die. By 2008 it was possible to brute 18 force DES keys in 6.4 days using less than USD 10k worth of hardware. 19 So by 2008 DES had passed its sell-by date. This document updates 20 RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in 21 Kerberos. Because the version of Kerberos specified in RFC1510 only 22 supports DES and has been replaced by RFC4120, RFC1510 is 23 reclassified as historic. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 11, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Requirements Notation 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 2. Background 65 Kerberos 5 was defined in [RFC1510] and updated in [RFC4120], the 66 Kerberos crypto system is defined by [RFC3961] and includes support 67 for DES encryption types. This document updates [RFC1964], 68 [RFC4120], and [RFC4121] to deprecate the use of DES in Kerberos. 70 Because the version of Kerberos specified in [RFC1510] only supports 71 DES and has been replaced by [RFC4120], [RFC1510] is reclassified as 72 historic. 74 DES was withdrawn in [DES-Transition-Plan] by National Institute of 75 Standards and Technology (NIST). IETF have also published its the 76 position in [RFC4772], which in the recommendation summery is made 77 very clear: "don't use DES". 79 In Kerberos Generic Security Services Application Programming 80 Interface (GSS-API) mechanism [RFC1964] and the updated version 81 [RFC4121] the following checksum and encryption mechanism is defined: 82 three SGN ALG: 0000 - DES MAC MD5, 0100 - MD2.5 0200 - DES MAC and 83 one SEAL ALG 0000 - DES. With newer encryption types for Kerberos 84 defined in [RFC4121], Microsofts ARCFOUR4-HMAC based GSS-API mech, 85 and MITs DES3 , there is no need to support the old DES based SGN/ 86 SEAL types. 88 3. Recommendations 90 This document removes the RECOMMENDED types from [RFC4120]: 92 Encryption: DES-CBC-MD5(3) 94 Checksums: DES-MD5 (8, RSA-MD5-DES from [RFC3961]). 96 Kerberos implementation and deployments SHOULD NOT implement the 97 single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC- 98 MD5(3). 100 Kerberos implementation and deployments SHOULD NOT implement the 101 checksum type: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), DES- 102 MAC-K(5), RSA-MD4-MAC-K(6), DES-MD5(7), RSA-MD5-DES(8). 104 Note that RSA-MD5 might be with non-DES encryption types, for 105 example, when doing a TGS-REQ with a ARCFOUR-HMAC-MD5 some client 106 uses RSA-MD5 for the checksum that is stored inside the encrypted 107 part of the authenticator. This use of RSA-MD5 should probably be 108 considered safe, so the Kerberos implementation should make sure this 109 usage is not disabled when used with legacy system that can't handle 110 newer checksum types. 112 Kerberos GSS mechanism implementation and deployments SHOULD NOT 113 implement the SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES MAC(0200) 114 (updates [RFC1964]). 116 Kerberos GSS mechanism implementation and deployments SHOULD NOT 117 implement the SEAL ALG: DES(0000) (updates [RFC1964]). 119 The effect of the two last sentences is that this document deprecates 120 section 1.2 in [RFC1964]. 122 4. Acknowledgements 124 Jeffrey Hutzelman, Simon Josefsson, Mattias Amnefelt and Leif 125 Johansson have read the document and provided suggestions for 126 improvements. Sam hartman proposed moving [RFC1510] to historic. 128 5. Security Considerations 130 Removing support for single DES improves security since DES is 131 considered to be insecure. 133 6. IANA Considerations 135 There are no IANA Considerations for this document 137 7. References 139 7.1. Normative References 141 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 142 RFC 1964, June 1996. 144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 145 Requirement Levels", BCP 14, RFC 2119, March 1997. 147 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 148 Kerberos 5", RFC 3961, February 2005. 150 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 151 Kerberos Network Authentication Service (V5)", RFC 4120, 152 July 2005. 154 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 155 Version 5 Generic Security Service Application Program 156 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 157 July 2005. 159 7.2. Informative References 161 [DES-Transition-Plan] 162 National Institute of Standards and Technology, "DES 163 Transition Plan - Federal Register / Vol. 70, No. 96", 164 May 2006. 166 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 167 Authentication Service (V5)", RFC 1510, September 1993. 169 [RFC4772] Kelly, S., "Security Implications of Using the Data 170 Encryption Standard (DES)", RFC 4772, December 2006. 172 Author's Address 174 Love Hornquist Astrand 175 Apple, Inc 176 Cupertino 177 USA 179 Email: lha@apple.com