summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6331.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6331.txt')
-rw-r--r--doc/rfc/rfc6331.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6331.txt b/doc/rfc/rfc6331.txt
new file mode 100644
index 0000000..3d4172f
--- /dev/null
+++ b/doc/rfc/rfc6331.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Melnikov
+Request for Comments: 6331 Isode Limited
+Obsoletes: 2831 July 2011
+Category: Informational
+ISSN: 2070-1721
+
+
+ Moving DIGEST-MD5 to Historic
+
+Abstract
+
+ This memo describes problems with the DIGEST-MD5 Simple
+ Authentication and Security Layer (SASL) mechanism as specified in
+ RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of
+ SASL mechanisms and moves RFC 2831 to Historic status.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ 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.
+
+ 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 (c) 2011 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
+ (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.
+
+
+
+
+
+Melnikov Informational [Page 1]
+
+RFC 6331 Moving DIGEST-MD5 to Historic July 2011
+
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
+ 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ 5.2. Informative References . . . . . . . . . . . . . . . . . . . 5
+
+1. Introduction and Overview
+
+ [RFC2831] defines 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, email, the
+ Lightweight Directory Access Protocol (LDAP), and other protocols.
+ While it can be argued that it is an improvement over CRAM-MD5, many
+ implementors commented that the additional complexity of DIGEST-MD5
+ makes it difficult to implement fully and securely.
+
+ Below is an incomplete list of problems with the DIGEST-MD5 mechanism
+ as specified in [RFC2831]:
+
+ 1. The mechanism has too many options and modes. Some of them are
+ not well described and are not widely implemented. For example,
+ DIGEST-MD5 allows the "qop" directive to contain multiple values,
+ but it also allows for multiple qop directives to be specified.
+ The handling of multiple options is not specified, which results
+ in minor interoperability problems. Some implementations
+ amalgamate multiple qop values into one, while others treat
+ 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 is not clear on whether
+
+
+
+Melnikov Informational [Page 2]
+
+RFC 6331 Moving DIGEST-MD5 to Historic July 2011
+
+
+ the authzid must be omitted or if it can be specified with an
+ empty value to convey this. The requirement for backward
+ compatibility with HTTP Digest means that the situation is even
+ worse. For example, DIGEST-MD5 requires all usernames/passwords
+ that can be entirely represented in the ISO-8859-1 charset to be
+ down converted from UTF-8 [RFC3629] to ISO-8859-1 [ISO-8859-1].
+ Another example is the use of quoted strings. Handling of
+ characters that need escaping is not properly described, and the
+ DIGEST-MD5 document has no examples to demonstrate correct
+ behavior.
+
+ 2. The DIGEST-MD5 document uses 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 a
+ more common ABNF defined in [RFC5234] is confusing for some
+ implementors. As a result, many implementations do not accept
+ folding whitespace in many places where it is 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 does not provide any
+ guidance on how realms should be named and, more importantly, how
+ they can be entered in User Interfaces (UIs). As a result, many
+ DIGEST-MD5 clients have confusing UIs, do not allow users to
+ enter a realm, and/or do not allow users to pick one of the
+ server-supported realms.
+
+ 4. Use of username in the inner hash is problematic. 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. 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 is rarely done in practice. First,
+ 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 [DES] and RC4 security layers are
+ inadequate to produce independently developed interoperable
+ implementations. In the DES/3DES case, this is partly a problem
+ with existing DES APIs.
+
+ 6. DIGEST-MD5 outer hash (the value of the "response" directive)
+ does not protect the whole authentication exchange, which makes
+ the mechanism vulnerable to "man-in-the-middle" (MITM) attacks,
+ such as modification of the list of supported qops or ciphers.
+
+
+
+Melnikov Informational [Page 3]
+
+RFC 6331 Moving DIGEST-MD5 to Historic July 2011
+
+
+ 7. The following features are missing from DIGEST-MD5, making it
+ insecure or unsuitable for use in protocols:
+
+ A. Channel bindings [RFC5056].
+
+ B. Hash agility (i.e., no easy way to replace the MD5 hash
+ function with another one).
+
+ C. Support for SASLPrep [RFC4013] or any other type of Unicode
+ character normalization of usernames and passwords. The
+ original DIGEST-MD5 document predates SASLPrep and does not
+ 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 [RFC6151].
+
+ B. The RC4 algorithm is prone to attack when used as the
+ security layer without discarding the initial key stream
+ output [RFC6229].
+
+ C. The DES cipher for the security layer is considered insecure
+ due to its small key space [RFC3766].
+
+ Note that most of the problems listed above are already present in
+ the HTTP Digest authentication mechanism.
+
+ Because DIGEST-MD5 is defined as an extensible mechanism, it is
+ 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 is not worth the cost. In
+ addition, an implementation of a "fixed" DIGEST-MD5 specification
+ would likely either not interoperate with any existing implementation
+ of [RFC2831] 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.
+
+ The Salted Challenge Response Authentication Mechanism (SCRAM) family
+ of SASL mechanisms [RFC5802] has been developed to provide similar
+ features as DIGEST-MD5 but with a better design.
+
+
+
+
+
+Melnikov Informational [Page 4]
+
+RFC 6331 Moving DIGEST-MD5 to Historic July 2011
+
+
+2. Security Considerations
+
+ Security issues are discussed throughout this document.
+
+3. IANA Considerations
+
+ IANA has changed 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, Sean Turner, and Abhijit
+ Menon-Sen. Various text was copied from other RFCs, in particular,
+ from [RFC2831].
+
+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.
+
+ [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
+ as a SASL Mechanism", RFC 2831, May 2000.
+
+5.2. Informative References
+
+ [DES] National Institute of Standards and Technology, "Data
+ Encryption Standard (DES)", FIPS PUB 46-3,
+ October 1999.
+
+ [ISO-8859-1] International Organization for Standardization,
+ "Information technology - 8-bit single-byte coded
+ graphic character sets - Part 1: Latin alphabet No. 1",
+ ISO/IEC 8859-1, 1998.
+
+ [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
+ text messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+Melnikov Informational [Page 5]
+
+RFC 6331 Moving DIGEST-MD5 to Historic July 2011
+
+
+ [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response",
+ RFC 2195, September 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
+ Public Keys Used For Exchanging Symmetric Keys",
+ BCP 86, RFC 3766, April 2004.
+
+ [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.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
+ Williams, "Salted Challenge Response Authentication
+ 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
+
+ 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 Informational [Page 6]
+