idnits 2.17.1 draft-ietf-kitten-digest-to-historic-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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2831, but the abstract doesn't seem to directly say this. It does mention RFC2831 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 == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2011) is 4747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kitten Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Obsoletes: RFC 2831 (if approved) April 22, 2011 5 (if approved) 6 Intended status: Informational 7 Expires: October 24, 2011 9 Moving DIGEST-MD5 to Historic 10 draft-ietf-kitten-digest-to-historic-04 12 Abstract 14 This memo describes problems with the DIGEST-MD5 Simple 15 Authentication and Security Layer (SASL) mechanism as specified in 16 RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of 17 SASL mechanisms, and moves RFC 2831 to Historic. status. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 24, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 75 5.2. Informative References . . . . . . . . . . . . . . . . . . . 6 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Overview 81 [RFC2831] defined how HTTP Digest Authentication [RFC2617] can be 82 used as a Simple Authentication and Security Layer (SASL) [RFC4422] 83 mechanism for any protocol that has a SASL profile. It was intended 84 both as an improvement over CRAM-MD5 [RFC2195] and as a convenient 85 way to support a single authentication mechanism for web, email, 86 LDAP, and other protocols. While it can be argued that it was an 87 improvement over CRAM-MD5, many implementors commented that the 88 additional complexity of DIGEST-MD5 made it difficult to implement 89 fully and securely. 91 Below is an incomplete list of problems with DIGEST-MD5 mechanism as 92 specified in RFC 2831: 94 1. The mechanism had too many options and modes. Some of them were 95 not well described and were not widely implemented. For example, 96 DIGEST-MD5 allowed the "qop" directive to contain multiple 97 values, but it also allowed for multiple qop directives to be 98 specified. The handling of multiple options was not specified, 99 which resulted in minor interoperability problems. Some 100 implementations amalgamated multiple qop values into one, while 101 others treated multiple qops as an error. Another example is the 102 use of an empty authorization identity. In SASL an empty 103 authorization identity means that the client is willing to 104 authorize as the authentication identity. The document was not 105 clear on whether the authzid must be omitted or can be specified 106 with the empty value to convey this. The requirement for 107 backward compatibility with HTTP Digest meant that the situation 108 was even worse. For example DIGEST-MD5 required all usernames/ 109 passwords which can be entirely represented in ISO-8859-1 charset 110 to be down converted from UTF-8 to ISO-8859-1. Another example 111 is use of quoted strings. Handling of characters that needed 112 escaping was not properly described and the DIGEST-MD5 document 113 had no examples to demonstrate correct behavior. 115 2. The document used ABNF from RFC 822 [RFC0822], which allows an 116 extra construct and allows for "implied folding whitespace" to be 117 inserted in many places. The difference from ABNF [RFC5234] was 118 confusing for some implementors. As a result, many 119 implementations didn't accept folding whitespace in many places 120 where it was allowed. 122 3. The DIGEST-MD5 document uses the concept of a "realm" to define a 123 collection of accounts. A DIGEST-MD5 server can support one or 124 more realms. The DIGEST-MD5 document didn't provide any guidance 125 on how realms should be named, and, more importantly, how they 126 can be entered in User Interfaces (UIs). As the result many 127 DIGEST-MD5 clients had confusing UIs, didn't allow users to enter 128 a realm and/or didn't allow users to pick one of the server 129 supported realms. 131 4. Use of username in the inner hash. The inner hash of DIGEST-MD5 132 is an MD5 hash of colon separated username, realm and password. 133 Implementations may choose to store inner hashes instead of clear 134 text passwords. While this has some useful properties, such as 135 protection from compromise of authentication databases containing 136 the same username and password on other servers, if a server with 137 the username and password is compromised, however this was rarely 138 done in practice. Firstly, the inner hash is not compatible with 139 widely deployed Unix password databases, and second, changing the 140 username would invalidate the inner hash. 142 5. Description of DES/3DES [DES] and RC4 security layers are 143 inadequate to produce independently-developed interoperable 144 implementations. In the DES/3DES case this was partly a problem 145 with existing DES APIs. 147 6. DIGEST-MD5 outer hash (the value of the "response" directive) 148 didn't protect the whole authentication exchange, which made the 149 mechanism vulnerable to "man in the middle" (MITM) attacks, such 150 as modification of the list of supported qops or ciphers. 152 7. The following features are missing from DIGEST-MD5, which make it 153 insecure or unsuitable for use in protocols: 155 A. Lack of channel bindings [RFC5056]. 157 B. Lack of hash agility (i.e. no easy way to replace the MD5 158 hash function with another one). 160 C. Lack of support for SASLPrep [RFC4013] or any other type of 161 Unicode character normalization of usernames and passwords. 162 The original DIGEST-MD5 document predates SASLPrep and 163 doesn't recommend any Unicode character normalization. 165 8. The cryptographic primitives in DIGEST-MD5 are not up to today's 166 standards, in particular: 168 A. The MD5 hash is sufficiently weak to make a brute force 169 attack on DIGEST-MD5 easy with common hardware [RFC6151]. 171 B. Using the RC4 algorithm for the security layer without 172 discarding the initial key stream output is prone to attack 173 [RC4]. 175 C. The DES cipher for the security layer is considered insecure 176 due to its small key space [RFC3766]. 178 Note that most of the problems listed above are already present in 179 the HTTP Digest authentication mechanism. 181 Because DIGEST-MD5 was defined as an extensible mechanism, it would 182 be possible to fix most of the problems listed above. However this 183 would increase implementation complexity of an already complex 184 mechanism even further, so the effort would not be worth the cost. 185 In addition, an implementation of a "fixed" DIGEST-MD5 specification 186 would likely either not interoperate with any existing implementation 187 of RFC 2831, or would be vulnerable to various downgrade attacks. 189 Note that despite DIGEST-MD5 seeing some deployment on the Internet, 190 this specification recommends obsoleting DIGEST-MD5 because DIGEST- 191 MD5, as implemented, is not a reasonable candidate for further 192 standardization and should be deprecated in favor of one or more new 193 password-based mechanisms currently being designed. 195 The SCRAM family of SASL mechanisms [RFC5802] has been developed to 196 provide similar features as DIGEST-MD5 but with a better design. 198 2. Security Considerations 200 Security issues are discussed through out this document. 202 3. IANA Considerations 204 IANA is requested to change the "Intended usage" of the DIGEST-MD5 205 mechanism registration in the SASL mechanism registry to OBSOLETE. 206 The SASL mechanism registry is specified in [RFC4422] and is 207 currently available at: 209 http://www.iana.org/assignments/sasl-mechanisms 211 4. Acknowledgements 213 The author gratefully acknowledges the feedback provided by Chris 214 Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner and Abhijit 215 Menon-Sen. Various text was copied from other RFCs, in particular 216 from RFC 2831. 218 5. References 220 5.1. Normative References 222 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 223 Leach, P., Luotonen, A., and L. Stewart, "HTTP 224 Authentication: Basic and Digest Access Authentication", 225 RFC 2617, June 1999. 227 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 228 SASL Mechanism", RFC 2831, May 2000. 230 5.2. Informative References 232 [DES] National Institute of Standards and Technology, "Data 233 Encryption Standard (DES)", FIPS PUB 46-3, October 1999. 235 [RC4] Strombergson, J. and S. Josefsson, "Test vectors for the 236 stream cipher RC4", 237 draft-josefsson-rc4-test-vectors-02.txt (work in 238 progress), June 2010. 240 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 241 text messages", STD 11, RFC 822, August 1982. 243 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 244 AUTHorize Extension for Simple Challenge/Response", 245 RFC 2195, September 1997. 247 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 248 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 249 RFC 3766, April 2004. 251 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 252 and Passwords", RFC 4013, February 2005. 254 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 255 Security Layer (SASL)", RFC 4422, June 2006. 257 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 258 Channels", RFC 5056, November 2007. 260 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 261 Specifications: ABNF", STD 68, RFC 5234, January 2008. 263 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 264 "Salted Challenge Response Authentication Mechanism 265 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 267 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 268 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 269 RFC 6151, March 2011. 271 Author's Address 273 Alexey Melnikov 274 Isode Limited 275 5 Castle Business Village 276 36 Station Road 277 Hampton, Middlesex TW12 2BX 278 UK 280 Email: Alexey.Melnikov@isode.com 281 URI: http://www.melnikov.ca/