idnits 2.17.1 draft-ietf-sasl-digest-to-historic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2008) is 5750 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SASL Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Informational July 29, 2008 5 Expires: January 30, 2009 7 Moving DIGEST-MD5 to Historic 8 draft-ietf-sasl-digest-to-historic-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 30, 2009. 35 Abstract 37 This memo describes problems with the DIGEST-MD5 Simple 38 Authentication and Security Layer (SASL) mechanism as specified in 39 RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in 40 the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to 41 Historic status. 43 Note 45 A revised version of this draft document will be submitted to the RFC 46 editor as a Proposed Standard for the Internet Community. Discussion 47 and suggestions for improvement are requested, and should be sent to 48 ietf-sasl@imc.org. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 5.2. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 65 Intellectual Property and Copyright Statements . . . . . . . 7 67 1. Overview 69 [RFC2831] defined how HTTP Digest Authentication [RFC2617] can be 70 used as a Simple Authentication and Security Layer (SASL) [RFC4422] 71 mechanism for any protocol that has a SASL profile. It was intended 72 both as an improvement over CRAM-MD5 [RFC2195] and as a convenient 73 way to support a single authentication mechanism for web, mail, LDAP, 74 and other protocols. While it can be argued that it was an 75 improvement over CRAM-MD5, many implementors commented that the 76 additional complexity of DIGEST-MD5 made it difficult to implement 77 fully and securely. 79 Below is an incomplete list of problems with DIGEST-MD5 mechanism as 80 specified in RFC 2831: 82 1. The mechanism had too many options and modes. Some of them were 83 not well described and were not widely implemented. For example, 84 DIGEST-MD5 allowed the "qop" directive to contain multiple 85 values, but it also allowed for multiple qop directives to be 86 specified. The handling of multiple options was not specified, 87 which resulted in minor interoperability problems. Some 88 implementations amalgamated multiple qop values into one, while 89 others treated multiple qops as an error. Another example is the 90 use of an empty authorization identity. In SASL an empty 91 authorization identity means that the client is willing to 92 authorize as the authentication identity. The document was not 93 clear on whether the authzid must be omitted or can be specified 94 with the empty value to convey this. The requirement for 95 backward compatibility with HTTP Digest meant that the situation 96 was even worse. For example DIGEST-MD5 required all usernames/ 97 passwords which can be entirely represented in ISO-8859-1 charset 98 to be down converted from UTF-8 to ISO-8859-1. Another example 99 is use of quoted strings. Handling of characters that needed 100 escaping was not properly described and the DIGEST-MD5 document 101 had no examples to demonstrate correct behavior. 103 2. The document used ABNF from RFC 822 [RFC0822], which allows an 104 extra construct and allows for "implied folding whitespace" to be 105 inserted in many places. The difference from ABNF [RFC4234] was 106 confusing for some implementors. As a result, many 107 implementations didn't accept folding whitespace in many places 108 where it was allowed. 110 3. The DIGEST-MD5 document uses the concept of a "realm" to define a 111 collection of accounts. A DIGEST-MD5 server can support one or 112 more realms. The DIGEST-MD5 document didn't provide any guidance 113 on how realms should be named, and, more importantly, how they 114 can be entered in User Interfaces (UIs). As the result many 115 DIGEST-MD5 clients had confusing UIs, didn't allow users to enter 116 a realm and/or didn't allow users to pick one of the server 117 supported realms. 119 4. Use of username in the inner hash. The inner hash of DIGEST-MD5 120 is an MD5 hash of colon separated username, realm and password. 121 Implementations may choose to store inner hashes instead of clear 122 text passwords. While this has some useful properties, such as 123 protection from compromise of authentication databases containing 124 the same username and password on other servers, if a server with 125 the username and password is compromised, however this was rarely 126 done in practice. Firstly, the inner hash is not compatible with 127 widely deployed Unix password databases, and second, changing the 128 username would invalidate the inner hash. 130 5. Description of DES/3DES and RC4 security layers are inadequate to 131 produce independently-developed interoperable implementations. 132 In the DES/3DES case this was partly a problem with existing DES 133 APIs. 135 6. DIGEST-MD5 outer hash (the value of the "response" directive) 136 didn't protect the whole authentication exchange, which made the 137 mechanism vulnerable to "man in the middle" (MITM) attacks, such 138 as modification of the list of supported qops or ciphers. 140 7. The following features are missing from DIGEST-MD5, which make it 141 insecure or unsuitable for use in protocols: 143 A. Lack of channel bindings. 145 B. Lack of hash agility. 147 C. Lack of SASLPrep [RFC4013] support. The original DIGEST-MD5 148 document predates SASLPrep and doesn't recommend any Unicode 149 character normalization. 151 8. The cryptographic primitives in DIGEST-MD5 are not up to today's 152 standards, in particular: 154 A. The MD5 hash is sufficiently weak to make a brute force 155 attack on DIGEST-MD5 easy with common hardware. 157 B. Using the RC4 algorithm for the security layer without 158 discarding the initial key stream output is prone to attack. 160 Note that most of the problems listed above are already present in 161 the HTTP Digest authentication mechanism. 163 Because DIGEST-MD5 was defined as an extensible mechanism, it would 164 be possible to fix most of the problems listed above. However this 165 would increase implementation complexity of an already complex 166 mechanism even further, so the effort would not be worth the cost. 167 In addition, an implementation of a "fixed" DIGEST-MD5 specification 168 would likely either not interoperate with any existing implementation 169 of RFC 2831, or would be vulnerable to various downgrade attacks. 171 Note that despite DIGEST-MD5 seeing some deployment on the Internet, 172 this specification recommends obsoleting DIGEST-MD5 because DIGEST- 173 MD5, as implemented, is not a reasonable candidate for further 174 standardization and should be deprecated in favor of one or more new 175 password-based mechanisms currently being designed. 177 2. Security Considerations 179 Security issues are discussed through out this document. 181 3. IANA Considerations 183 IANA is requested to change the "Intended usage" of the DIGEST-MD5 184 mechanism registration in the SASL mechanism registry to OBSOLETE. 185 The SASL mechanism registry is specified in [RFC4422] and is 186 currently available at: 188 http://www.iana.org/assignments/sasl-mechanisms 190 4. Acknowledgements 192 The author gratefully acknowledges the feedback provided by Chris 193 Newman, Simon Josefsson, Kurt Zeilenga and Abhijit Menon-Sen. 194 [[anchor3: Various text was copied from other RFCs.]] 196 5. References 198 5.1. Normative References 200 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 201 Leach, P., Luotonen, A., and L. Stewart, "HTTP 202 Authentication: Basic and Digest Access Authentication", 203 RFC 2617, June 1999. 205 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 206 SASL Mechanism", RFC 2831, May 2000. 208 5.2. Informative References 210 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 211 text messages", STD 11, RFC 822, August 1982. 213 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 214 AUTHorize Extension for Simple Challenge/Response", 215 RFC 2195, September 1997. 217 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 218 and Passwords", RFC 4013, February 2005. 220 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 221 Specifications: ABNF", RFC 4234, October 2005. 223 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 224 Security Layer (SASL)", RFC 4422, June 2006. 226 Author's Address 228 Alexey Melnikov 229 Isode Limited 230 5 Castle Business Village 231 36 Station Road 232 Hampton, Middlesex TW12 2BX 233 UK 235 Email: Alexey.Melnikov@isode.com 236 URI: http://www.melnikov.ca/ 238 Full Copyright Statement 240 Copyright (C) The IETF Trust (2008). 242 This document is subject to the rights, licenses and restrictions 243 contained in BCP 78, and except as set forth therein, the authors 244 retain all their rights. 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 249 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 250 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 251 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Intellectual Property 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org.