7Internet Engineering Task Force (IETF) A. Melnikov
8Request for Comments: 6331 Isode Limited
9Obsoletes: 2831 July 2011
10Category: Informational
14 Moving DIGEST-MD5 to Historic
18 This memo describes problems with the DIGEST-MD5 Simple
19 Authentication and Security Layer (SASL) mechanism as specified in
20 RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of
21 SASL mechanisms and moves RFC 2831 to Historic status.
25 This document is not an Internet Standards Track specification; it is
26 published for informational purposes.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Not all documents
32 approved by the IESG are a candidate for any level of Internet
33 Standard; see Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6331.
41 Copyright (c) 2011 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Melnikov Informational [Page 1]
60RFC 6331 Moving DIGEST-MD5 to Historic July 2011
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
78 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5
79 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
80 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
82 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5
83 5.2. Informative References . . . . . . . . . . . . . . . . . . . 5
851. Introduction and Overview
87 [RFC2831] defines how HTTP Digest Authentication [RFC2617] can be
88 used as a Simple Authentication and Security Layer (SASL) [RFC4422]
89 mechanism for any protocol that has a SASL profile. It was intended
90 both as an improvement over CRAM-MD5 [RFC2195] and as a convenient
91 way to support a single authentication mechanism for web, email, the
92 Lightweight Directory Access Protocol (LDAP), and other protocols.
93 While it can be argued that it is an improvement over CRAM-MD5, many
94 implementors commented that the additional complexity of DIGEST-MD5
95 makes it difficult to implement fully and securely.
97 Below is an incomplete list of problems with the DIGEST-MD5 mechanism
98 as specified in [RFC2831]:
100 1. The mechanism has too many options and modes. Some of them are
101 not well described and are not widely implemented. For example,
102 DIGEST-MD5 allows the "qop" directive to contain multiple values,
103 but it also allows for multiple qop directives to be specified.
104 The handling of multiple options is not specified, which results
105 in minor interoperability problems. Some implementations
106 amalgamate multiple qop values into one, while others treat
107 multiple qops as an error. Another example is the use of an
108 empty authorization identity. In SASL, an empty authorization
109 identity means that the client is willing to authorize as the
110 authentication identity. The document is not clear on whether
114Melnikov Informational [Page 2]
116RFC 6331 Moving DIGEST-MD5 to Historic July 2011
119 the authzid must be omitted or if it can be specified with an
120 empty value to convey this. The requirement for backward
121 compatibility with HTTP Digest means that the situation is even
122 worse. For example, DIGEST-MD5 requires all usernames/passwords
123 that can be entirely represented in the ISO-8859-1 charset to be
124 down converted from UTF-8 [RFC3629] to ISO-8859-1 [ISO-8859-1].
125 Another example is the use of quoted strings. Handling of
126 characters that need escaping is not properly described, and the
127 DIGEST-MD5 document has no examples to demonstrate correct
130 2. The DIGEST-MD5 document uses ABNF from RFC 822 [RFC0822], which
131 allows an extra construct and allows for "implied folding
132 whitespace" to be inserted in many places. The difference from a
133 more common ABNF defined in [RFC5234] is confusing for some
134 implementors. As a result, many implementations do not accept
135 folding whitespace in many places where it is allowed.
137 3. The DIGEST-MD5 document uses the concept of a "realm" to define a
138 collection of accounts. A DIGEST-MD5 server can support one or
139 more realms. The DIGEST-MD5 document does not provide any
140 guidance on how realms should be named and, more importantly, how
141 they can be entered in User Interfaces (UIs). As a result, many
142 DIGEST-MD5 clients have confusing UIs, do not allow users to
143 enter a realm, and/or do not allow users to pick one of the
144 server-supported realms.
146 4. Use of username in the inner hash is problematic. The inner hash
147 of DIGEST-MD5 is an MD5 hash of colon-separated username, realm,
148 and password. Implementations may choose to store inner hashes
149 instead of clear text passwords. This has some useful
150 properties, such as protection from compromise of authentication
151 databases containing the same username and password on other
152 servers if a server with the username and password is
153 compromised; however, this is rarely done in practice. First,
154 the inner hash is not compatible with widely deployed Unix
155 password databases, and second, changing the username would
156 invalidate the inner hash.
158 5. Description of DES/3DES [DES] and RC4 security layers are
159 inadequate to produce independently developed interoperable
160 implementations. In the DES/3DES case, this is partly a problem
161 with existing DES APIs.
163 6. DIGEST-MD5 outer hash (the value of the "response" directive)
164 does not protect the whole authentication exchange, which makes
165 the mechanism vulnerable to "man-in-the-middle" (MITM) attacks,
166 such as modification of the list of supported qops or ciphers.
170Melnikov Informational [Page 3]
172RFC 6331 Moving DIGEST-MD5 to Historic July 2011
175 7. The following features are missing from DIGEST-MD5, making it
176 insecure or unsuitable for use in protocols:
178 A. Channel bindings [RFC5056].
180 B. Hash agility (i.e., no easy way to replace the MD5 hash
181 function with another one).
183 C. Support for SASLPrep [RFC4013] or any other type of Unicode
184 character normalization of usernames and passwords. The
185 original DIGEST-MD5 document predates SASLPrep and does not
186 recommend any Unicode character normalization.
188 8. The cryptographic primitives in DIGEST-MD5 are not up to today's
189 standards, in particular:
191 A. The MD5 hash is sufficiently weak to make a brute force
192 attack on DIGEST-MD5 easy with common hardware [RFC6151].
194 B. The RC4 algorithm is prone to attack when used as the
195 security layer without discarding the initial key stream
198 C. The DES cipher for the security layer is considered insecure
199 due to its small key space [RFC3766].
201 Note that most of the problems listed above are already present in
202 the HTTP Digest authentication mechanism.
204 Because DIGEST-MD5 is defined as an extensible mechanism, it is
205 possible to fix most of the problems listed above. However, this
206 would increase implementation complexity of an already complex
207 mechanism even further, so the effort is not worth the cost. In
208 addition, an implementation of a "fixed" DIGEST-MD5 specification
209 would likely either not interoperate with any existing implementation
210 of [RFC2831] or would be vulnerable to various downgrade attacks.
212 Note that despite DIGEST-MD5 seeing some deployment on the Internet,
213 this specification recommends obsoleting DIGEST-MD5 because DIGEST-
214 MD5, as implemented, is not a reasonable candidate for further
215 standardization and should be deprecated in favor of one or more new
216 password-based mechanisms currently being designed.
218 The Salted Challenge Response Authentication Mechanism (SCRAM) family
219 of SASL mechanisms [RFC5802] has been developed to provide similar
220 features as DIGEST-MD5 but with a better design.
226Melnikov Informational [Page 4]
228RFC 6331 Moving DIGEST-MD5 to Historic July 2011
2312. Security Considerations
233 Security issues are discussed throughout this document.
2353. IANA Considerations
237 IANA has changed the "Intended usage" of the DIGEST-MD5 mechanism
238 registration in the SASL mechanism registry to OBSOLETE. The SASL
239 mechanism registry is specified in [RFC4422] and is currently
242 http://www.iana.org/assignments/sasl-mechanisms
246 The author gratefully acknowledges the feedback provided by Chris
247 Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner, and Abhijit
248 Menon-Sen. Various text was copied from other RFCs, in particular,
2535.1. Normative References
255 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
256 S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
257 Authentication: Basic and Digest Access
258 Authentication", RFC 2617, June 1999.
260 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
261 as a SASL Mechanism", RFC 2831, May 2000.
2635.2. Informative References
265 [DES] National Institute of Standards and Technology, "Data
266 Encryption Standard (DES)", FIPS PUB 46-3,
269 [ISO-8859-1] International Organization for Standardization,
270 "Information technology - 8-bit single-byte coded
271 graphic character sets - Part 1: Latin alphabet No. 1",
272 ISO/IEC 8859-1, 1998.
274 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
275 text messages", STD 11, RFC 822, August 1982.
282Melnikov Informational [Page 5]
284RFC 6331 Moving DIGEST-MD5 to Historic July 2011
287 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
288 AUTHorize Extension for Simple Challenge/Response",
289 RFC 2195, September 1997.
291 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
292 10646", STD 63, RFC 3629, November 2003.
294 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
295 Public Keys Used For Exchanging Symmetric Keys",
296 BCP 86, RFC 3766, April 2004.
298 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
299 Names and Passwords", RFC 4013, February 2005.
301 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication
302 and Security Layer (SASL)", RFC 4422, June 2006.
304 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
305 Channels", RFC 5056, November 2007.
307 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
308 Specifications: ABNF", STD 68, RFC 5234, January 2008.
310 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
311 Williams, "Salted Challenge Response Authentication
312 Mechanism (SCRAM) SASL and GSS-API Mechanisms",
315 [RFC6151] Turner, S. and L. Chen, "Updated Security
316 Considerations for the MD5 Message-Digest and the HMAC-
317 MD5 Algorithms", RFC 6151, March 2011.
319 [RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for
320 the Stream Cipher RC4", RFC 6229, May 2011.
326 5 Castle Business Village
328 Hampton, Middlesex TW12 2BX
331 EMail: Alexey.Melnikov@isode.com
332 URI: http://www.melnikov.ca/
338Melnikov Informational [Page 6]