Moving DIGEST-MD5 to Historic
draft-melnikov-digest-to-historic-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 11, 2008.

Abstract

This memo documents problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism, as specified in RFC 2831. This document recommends DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanims and RFC 2831 to be moved to Historic status.

Note

A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-sasl@imc.org.

Table of Contents

1.  Overview

2.  Security Considerations

3.  IANA Considerations

4.  Acknowledgements

5.  References
5.1.  Normative References
5.2.  Informative References

§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Overview

[RFC2831] (Leach, P. and C. Newman, “Using Digest Authentication as a SASL Mechanism,” May 2000.) defined how HTTP Digest Authentication [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) can be used as a Simple Authentication and Security Layer (SASL) [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) mechanism for any protocol that has a SASL profile. It was intended both as an improvement over CRAM-MD5 [RFC2195] (Klensin, J., Catoe, R., and P. Krumviede, “IMAP/POP AUTHorize Extension for Simple Challenge/Response,” September 1997.) and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. While it can be argued that it was an improvement over CRAM-MD5, many implementors commented that the additional complexity of DIGEST-MD5 made it difficult to implement fully and securely.

Below is an incomplete list of problems with DIGEST-MD5 mechanism as specified in RFC 2831:

1. The mechanism had too many options and modes. Some of them were not well described and were not implemented. For example, DIGEST-MD5 allowed the "qop" directive to contain multiple values. But it also allowed for multiple qop directives to be specified. Handling of multiple options was not specified, which resulted in minor interoperability problems. Some implementations amalgamated multiple qop values into one, while others treated multiple qops as an error. Another example is use of empty authorization identity. In SASL an empty authorization identity means that the client is willing to authorize as the authentication identity. The document was not clear on whether the authzid must be omitted or can be specified with the empty value to convey this. The requirement for backward compatibility with HTTP Digest meant that the situation was even worse. For example DIGEST-MD5 required all usernames/passwords which can be entirely represented in ISO-8859-1 charset to be down converted from UTF-8 to ISO-8859-1. Another example is use of quoted strings. Handling of characters that needed escaping was not properly described and the DIGEST-MD5 document had no examples to demonstrate correct behavior.
2. The document used ABNF from RFC 822 [RFC0822] (Crocker, D., “Standard for the format of ARPA Internet text messages,” August 1982.), which allowes for an extra construct and allows for "implied folding whitespace" to be inserted in many places. Difference from ABNF [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) was confusing for some implementors. As a result, many implementations didn't allow for folding whitespaces in many places where they were allowed.
3. The DIGEST-MD5 document uses a concept of "realm" to define a collection of accounts. A DIGEST-MD5 server can support one or more realms. The DIGEST-MD5 document didn't provide any guidance on how realms should be named, and, more importantly, how they can be entered in User Interfaces (UIs). As the result many DIGEST-MD5 clients had confusing UI, didn't allow users to enter a realm and/or didn't allow users to pick one of the server supported realms.
4. Use of username in the inner hash. The inner hash of DIGEST-MD5 is an MD5 hash of colon separated username, realm and password. Implementations may chose to store inner hashes instead of clear text passwords. While this has some useful properties, such as compromise of an authentication database on one server does not automatically compromise an authentication database with the same username and password on other servers, in practice this was rarely done. Firstly, the inner hash is not compatible with commonly deployed Unix password databases. Secondly, change of a username invalidates the corresponding inner hash.
5. Description of DES/3DES and RC4 security layers are inadequate to produce independently-developed interoperable implementations. In the DES/3DES case this was partly a problem with existing DES APIs.
6. DIGEST-MD5 outer hash (the value of the "response" directive) didn't protect the whole authentication exchange, which made the mechanism vulnerable to "man in the middle" MITM attacks, such as modification of the list of supported qops or ciphers.
7. The following features are missing from DIGEST-MD5, which make it insecure or insuitable for use in protocols:

   A.

   Lack of channel bindings.

   B.

   Lack of hash agility. MD5 hash is suffuciently weak to make a brute force attack on DIGEST-MD5 easy with common hardware.

   C.

   Lack of SASLPrep [RFC4013] (Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.) support. The original DIGEST-MD5 document predates SASLPrep and doesn't recommend any Unicode character normalization.

Note that most of the problems listed above are already present in HTTP Digest authentication mechanism.

Bacause DIGEST-MD5 mechanism was defined as an extensible mechanism, it would be possible to fix most of the problems listed above. However this would increase implementation complexity of an already complex mechanism even further, so the effort would not be worth the cost. In addition, an implementation of a "fixed" DIGEST-MD5 specification would likely either not interoperate with any existing implementation of RFC 2831, or would be vulnerable to various downgrade attacks.

Note that despite DIGEST-MD5 seeing some deployment on the Internet, this specification recommends obsoleting DIGEST-MD5 because DIGEST-MD5, as implemented, is not a reasonable candidate for further standardization and should be deprecated in favor of one or more new password-based mechanisms currently being designed.

2.  Security Considerations

Security issues are discussed through out this document.

3.  IANA Considerations

IANA is requested to change the "Intended usage" of the DIGEST-MD5 mechanism registration in the SASL mechanism registry to OBSOLETE. The SASL mechanism registry is specified in [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) and is currently available at:

   http://www.iana.org/assignments/sasl-mechanisms

4.  Acknowledgements

The author gratefully acknowledges the feedback provided by Chris Newman, Simon Josefsson and Kurt Zeilenga. [anchor3] (Various text was copied from other RFCs.)

5.  References

5.1. Normative References

5.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.