One document matched: draft-ietf-kitten-digest-to-historic-00.txt
Kitten Working Group A. Melnikov
Internet-Draft Isode Limited
Intended status: Informational June 24, 2010
Expires: December 26, 2010
Moving DIGEST-MD5 to Historic
draft-ietf-kitten-digest-to-historic-00
Abstract
This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in
the IANA Registry of SASL mechanisms, and that RFC 2831 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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
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
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."
This Internet-Draft will expire on December 26, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Melnikov Expires December 26, 2010 [Page 1]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Melnikov Expires December 26, 2010 [Page 2]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Considerations . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
Melnikov Expires December 26, 2010 [Page 3]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
1. Overview
[RFC2831] defined how HTTP Digest Authentication [RFC2617] can be
used as a Simple Authentication and Security Layer (SASL) [RFC4422]
mechanism for any protocol that has a SASL profile. It was intended
both as an improvement over CRAM-MD5 [RFC2195] 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 widely implemented. For example,
DIGEST-MD5 allowed the "qop" directive to contain multiple
values, but it also allowed for multiple qop directives to be
specified. The 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 the
use of an 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], which allows an
extra construct and allows for "implied folding whitespace" to be
inserted in many places. The difference from ABNF [RFC5234] was
confusing for some implementors. As a result, many
implementations didn't accept folding whitespace in many places
where it was allowed.
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
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
Melnikov Expires December 26, 2010 [Page 4]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
DIGEST-MD5 clients had confusing UIs, 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 choose to store inner hashes instead of clear
text passwords. While this has some useful properties, such as
protection from compromise of authentication databases containing
the same username and password on other servers, if a server with
the username and password is compromised, however this was rarely
done in practice. Firstly, the inner hash is not compatible with
widely deployed Unix password databases, and second, changing the
username would invalidate the 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 unsuitable for use in protocols:
A. Lack of channel bindings.
B. Lack of hash agility.
C. Lack of SASLPrep [RFC4013] support. The original DIGEST-MD5
document predates SASLPrep and doesn't recommend any Unicode
character normalization.
8. The cryptographic primitives in DIGEST-MD5 are not up to today's
standards, in particular:
A. The MD5 hash is sufficiently weak to make a brute force
attack on DIGEST-MD5 easy with common hardware.
B. Using the RC4 algorithm for the security layer without
discarding the initial key stream output is prone to attack.
Note that most of the problems listed above are already present in
the HTTP Digest authentication mechanism.
Melnikov Expires December 26, 2010 [Page 5]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
Because DIGEST-MD5 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] 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, Kurt Zeilenga and Abhijit Menon-Sen.
[[anchor3: Various text was copied from other RFCs.]]
5. References
5.1. Normative References
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
Melnikov Expires December 26, 2010 [Page 6]
Internet-Draft Moving DIGEST-MD5 to Historic June 2010
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
5.2. Informative References
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Author's Address
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Melnikov Expires December 26, 2010 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 12:37:24 |