draft-ietf-kitten-digest-to-historic-04.txt   rfc6331.txt 
Kitten Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Limited Request for Comments: 6331 Isode Limited
Obsoletes: RFC 2831 (if approved) April 22, 2011 Obsoletes: 2831 July 2011
(if approved) Category: Informational
Intended status: Informational ISSN: 2070-1721
Expires: October 24, 2011
Moving DIGEST-MD5 to Historic Moving DIGEST-MD5 to Historic
draft-ietf-kitten-digest-to-historic-04
Abstract Abstract
This memo describes problems with the DIGEST-MD5 Simple This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of
SASL mechanisms, and moves RFC 2831 to Historic. status. SASL mechanisms and moves RFC 2831 to Historic status.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 24, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6331.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Security Considerations . . . . . . . . . . . . . . . . . . . 5 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction and Overview
5.1. Normative References . . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
1. Overview
[RFC2831] defined how HTTP Digest Authentication [RFC2617] can be [RFC2831] defines how HTTP Digest Authentication [RFC2617] can be
used as a Simple Authentication and Security Layer (SASL) [RFC4422] used as a Simple Authentication and Security Layer (SASL) [RFC4422]
mechanism for any protocol that has a SASL profile. It was intended mechanism for any protocol that has a SASL profile. It was intended
both as an improvement over CRAM-MD5 [RFC2195] and as a convenient both as an improvement over CRAM-MD5 [RFC2195] and as a convenient
way to support a single authentication mechanism for web, email, way to support a single authentication mechanism for web, email, the
LDAP, and other protocols. While it can be argued that it was an Lightweight Directory Access Protocol (LDAP), and other protocols.
improvement over CRAM-MD5, many implementors commented that the While it can be argued that it is an improvement over CRAM-MD5, many
additional complexity of DIGEST-MD5 made it difficult to implement implementors commented that the additional complexity of DIGEST-MD5
fully and securely. makes it difficult to implement fully and securely.
Below is an incomplete list of problems with DIGEST-MD5 mechanism as Below is an incomplete list of problems with the DIGEST-MD5 mechanism
specified in RFC 2831: as specified in [RFC2831]:
1. The mechanism had too many options and modes. Some of them were 1. The mechanism has too many options and modes. Some of them are
not well described and were not widely implemented. For example, not well described and are not widely implemented. For example,
DIGEST-MD5 allowed the "qop" directive to contain multiple DIGEST-MD5 allows the "qop" directive to contain multiple values,
values, but it also allowed for multiple qop directives to be but it also allows for multiple qop directives to be specified.
specified. The handling of multiple options was not specified, The handling of multiple options is not specified, which results
which resulted in minor interoperability problems. Some in minor interoperability problems. Some implementations
implementations amalgamated multiple qop values into one, while amalgamate multiple qop values into one, while others treat
others treated multiple qops as an error. Another example is the multiple qops as an error. Another example is the use of an
use of an empty authorization identity. In SASL an empty empty authorization identity. In SASL, an empty authorization
authorization identity means that the client is willing to identity means that the client is willing to authorize as the
authorize as the authentication identity. The document was not authentication identity. The document is not clear on whether
clear on whether the authzid must be omitted or can be specified the authzid must be omitted or if it can be specified with an
with the empty value to convey this. The requirement for empty value to convey this. The requirement for backward
backward compatibility with HTTP Digest meant that the situation compatibility with HTTP Digest means that the situation is even
was even worse. For example DIGEST-MD5 required all usernames/ worse. For example, DIGEST-MD5 requires all usernames/passwords
passwords which can be entirely represented in ISO-8859-1 charset that can be entirely represented in the ISO-8859-1 charset to be
to be down converted from UTF-8 to ISO-8859-1. Another example down converted from UTF-8 [RFC3629] to ISO-8859-1 [ISO-8859-1].
is use of quoted strings. Handling of characters that needed Another example is the use of quoted strings. Handling of
escaping was not properly described and the DIGEST-MD5 document characters that need escaping is not properly described, and the
had no examples to demonstrate correct behavior. DIGEST-MD5 document has no examples to demonstrate correct
behavior.
2. The document used ABNF from RFC 822 [RFC0822], which allows an 2. The DIGEST-MD5 document uses ABNF from RFC 822 [RFC0822], which
extra construct and allows for "implied folding whitespace" to be allows an extra construct and allows for "implied folding
inserted in many places. The difference from ABNF [RFC5234] was whitespace" to be inserted in many places. The difference from a
confusing for some implementors. As a result, many more common ABNF defined in [RFC5234] is confusing for some
implementations didn't accept folding whitespace in many places implementors. As a result, many implementations do not accept
where it was allowed. folding whitespace in many places where it is allowed.
3. The DIGEST-MD5 document uses the concept of a "realm" to define a 3. The DIGEST-MD5 document uses the concept of a "realm" to define a
collection of accounts. A DIGEST-MD5 server can support one or collection of accounts. A DIGEST-MD5 server can support one or
more realms. The DIGEST-MD5 document didn't provide any guidance more realms. The DIGEST-MD5 document does not provide any
on how realms should be named, and, more importantly, how they guidance on how realms should be named and, more importantly, how
can be entered in User Interfaces (UIs). As the result many they can be entered in User Interfaces (UIs). As a result, many
DIGEST-MD5 clients had confusing UIs, didn't allow users to enter DIGEST-MD5 clients have confusing UIs, do not allow users to
a realm and/or didn't allow users to pick one of the server enter a realm, and/or do not allow users to pick one of the
supported realms. server-supported realms.
4. Use of username in the inner hash. The inner hash of DIGEST-MD5 4. Use of username in the inner hash is problematic. The inner hash
is an MD5 hash of colon separated username, realm and password. of DIGEST-MD5 is an MD5 hash of colon-separated username, realm,
Implementations may choose to store inner hashes instead of clear and password. Implementations may choose to store inner hashes
text passwords. While this has some useful properties, such as instead of clear text passwords. This has some useful
protection from compromise of authentication databases containing properties, such as protection from compromise of authentication
the same username and password on other servers, if a server with databases containing the same username and password on other
the username and password is compromised, however this was rarely servers if a server with the username and password is
done in practice. Firstly, the inner hash is not compatible with compromised; however, this is rarely done in practice. First,
widely deployed Unix password databases, and second, changing the the inner hash is not compatible with widely deployed Unix
username would invalidate the inner hash. password databases, and second, changing the username would
invalidate the inner hash.
5. Description of DES/3DES [DES] and RC4 security layers are 5. Description of DES/3DES [DES] and RC4 security layers are
inadequate to produce independently-developed interoperable inadequate to produce independently developed interoperable
implementations. In the DES/3DES case this was partly a problem implementations. In the DES/3DES case, this is partly a problem
with existing DES APIs. with existing DES APIs.
6. DIGEST-MD5 outer hash (the value of the "response" directive) 6. DIGEST-MD5 outer hash (the value of the "response" directive)
didn't protect the whole authentication exchange, which made the does not protect the whole authentication exchange, which makes
mechanism vulnerable to "man in the middle" (MITM) attacks, such the mechanism vulnerable to "man-in-the-middle" (MITM) attacks,
as modification of the list of supported qops or ciphers. such as modification of the list of supported qops or ciphers.
7. The following features are missing from DIGEST-MD5, which make it 7. The following features are missing from DIGEST-MD5, making it
insecure or unsuitable for use in protocols: insecure or unsuitable for use in protocols:
A. Lack of channel bindings [RFC5056]. A. Channel bindings [RFC5056].
B. Lack of hash agility (i.e. no easy way to replace the MD5 B. Hash agility (i.e., no easy way to replace the MD5 hash
hash function with another one). function with another one).
C. Lack of support for SASLPrep [RFC4013] or any other type of C. Support for SASLPrep [RFC4013] or any other type of Unicode
Unicode character normalization of usernames and passwords. character normalization of usernames and passwords. The
The original DIGEST-MD5 document predates SASLPrep and original DIGEST-MD5 document predates SASLPrep and does not
doesn't recommend any Unicode character normalization. recommend any Unicode character normalization.
8. The cryptographic primitives in DIGEST-MD5 are not up to today's 8. The cryptographic primitives in DIGEST-MD5 are not up to today's
standards, in particular: standards, in particular:
A. The MD5 hash is sufficiently weak to make a brute force A. The MD5 hash is sufficiently weak to make a brute force
attack on DIGEST-MD5 easy with common hardware [RFC6151]. attack on DIGEST-MD5 easy with common hardware [RFC6151].
B. Using the RC4 algorithm for the security layer without B. The RC4 algorithm is prone to attack when used as the
discarding the initial key stream output is prone to attack security layer without discarding the initial key stream
[RC4]. output [RFC6229].
C. The DES cipher for the security layer is considered insecure C. The DES cipher for the security layer is considered insecure
due to its small key space [RFC3766]. due to its small key space [RFC3766].
Note that most of the problems listed above are already present in Note that most of the problems listed above are already present in
the HTTP Digest authentication mechanism. the HTTP Digest authentication mechanism.
Because DIGEST-MD5 was defined as an extensible mechanism, it would Because DIGEST-MD5 is defined as an extensible mechanism, it is
be possible to fix most of the problems listed above. However this possible to fix most of the problems listed above. However, this
would increase implementation complexity of an already complex would increase implementation complexity of an already complex
mechanism even further, so the effort would not be worth the cost. mechanism even further, so the effort is not worth the cost. In
In addition, an implementation of a "fixed" DIGEST-MD5 specification addition, an implementation of a "fixed" DIGEST-MD5 specification
would likely either not interoperate with any existing implementation would likely either not interoperate with any existing implementation
of RFC 2831, or would be vulnerable to various downgrade attacks. of [RFC2831] or would be vulnerable to various downgrade attacks.
Note that despite DIGEST-MD5 seeing some deployment on the Internet, Note that despite DIGEST-MD5 seeing some deployment on the Internet,
this specification recommends obsoleting DIGEST-MD5 because DIGEST- this specification recommends obsoleting DIGEST-MD5 because DIGEST-
MD5, as implemented, is not a reasonable candidate for further MD5, as implemented, is not a reasonable candidate for further
standardization and should be deprecated in favor of one or more new standardization and should be deprecated in favor of one or more new
password-based mechanisms currently being designed. password-based mechanisms currently being designed.
The SCRAM family of SASL mechanisms [RFC5802] has been developed to The Salted Challenge Response Authentication Mechanism (SCRAM) family
provide similar features as DIGEST-MD5 but with a better design. of SASL mechanisms [RFC5802] has been developed to provide similar
features as DIGEST-MD5 but with a better design.
2. Security Considerations 2. Security Considerations
Security issues are discussed through out this document. Security issues are discussed throughout this document.
3. IANA Considerations 3. IANA Considerations
IANA is requested to change the "Intended usage" of the DIGEST-MD5 IANA has changed the "Intended usage" of the DIGEST-MD5 mechanism
mechanism registration in the SASL mechanism registry to OBSOLETE. registration in the SASL mechanism registry to OBSOLETE. The SASL
The SASL mechanism registry is specified in [RFC4422] and is mechanism registry is specified in [RFC4422] and is currently
currently available at: available at:
http://www.iana.org/assignments/sasl-mechanisms http://www.iana.org/assignments/sasl-mechanisms
4. Acknowledgements 4. Acknowledgements
The author gratefully acknowledges the feedback provided by Chris The author gratefully acknowledges the feedback provided by Chris
Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner and Abhijit Newman, Simon Josefsson, Kurt Zeilenga, Sean Turner, and Abhijit
Menon-Sen. Various text was copied from other RFCs, in particular Menon-Sen. Various text was copied from other RFCs, in particular,
from RFC 2831. from [RFC2831].
5. References 5. References
5.1. Normative References 5.1. Normative References
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
Leach, P., Luotonen, A., and L. Stewart, "HTTP S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access
RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
SASL Mechanism", RFC 2831, May 2000. as a SASL Mechanism", RFC 2831, May 2000.
5.2. Informative References 5.2. Informative References
[DES] National Institute of Standards and Technology, "Data [DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. Encryption Standard (DES)", FIPS PUB 46-3,
October 1999.
[RC4] Strombergson, J. and S. Josefsson, "Test vectors for the [ISO-8859-1] International Organization for Standardization,
stream cipher RC4", "Information technology - 8-bit single-byte coded
draft-josefsson-rc4-test-vectors-02.txt (work in graphic character sets - Part 1: Latin alphabet No. 1",
progress), June 2010. ISO/IEC 8859-1, 1998.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997. RFC 2195, September 1997.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Public Keys Used For Exchanging Symmetric Keys", BCP 86, 10646", STD 63, RFC 3629, November 2003.
RFC 3766, April 2004.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
and Passwords", RFC 4013, February 2005. Public Keys Used For Exchanging Symmetric Keys",
BCP 86, RFC 3766, April 2004.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Security Layer (SASL)", RFC 4422, June 2006. Names and Passwords", RFC 4013, February 2005.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication
Channels", RFC 5056, November 2007. and Security Layer (SASL)", RFC 4422, June 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Specifications: ABNF", STD 68, RFC 5234, January 2008. Channels", RFC 5056, November 2007.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
"Salted Challenge Response Authentication Mechanism Specifications: ABNF", STD 68, RFC 5234, January 2008.
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", Williams, "Salted Challenge Response Authentication
RFC 6151, March 2011. Mechanism (SCRAM) SASL and GSS-API Mechanisms",
RFC 5802, July 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security
Considerations for the MD5 Message-Digest and the HMAC-
MD5 Algorithms", RFC 6151, March 2011.
[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for
the Stream Cipher RC4", RFC 6229, May 2011.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/ URI: http://www.melnikov.ca/
 End of changes. 47 change blocks. 
148 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/