idnits 2.17.1 draft-melnikov-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 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 273. 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 (September 8, 2007) is 6047 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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: Standards Track September 8, 2007 5 Expires: March 11, 2008 7 Moving DIGEST-MD5 to Historic 8 draft-melnikov-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 March 11, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo documents problems with the DIGEST-MD5 Simple 42 Authentication and Security Layer (SASL) mechanism, as specified in 43 RFC 2831. This document recommends DIGEST-MD5 to be marked as 44 OBSOLETE in the IANA Registry of SASL mechanims and RFC 2831 to be 45 moved to Historic status. 47 Note 49 A revised version of this draft document will be submitted to the RFC 50 editor as a Proposed Standard for the Internet Community. Discussion 51 and suggestions for improvement are requested, and should be sent to 52 ietf-sasl@imc.org. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Informative References . . . . . . . . . . . . . . . . . . . 5 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 69 Intellectual Property and Copyright Statements . . . . . . . 7 71 1. Overview 73 [RFC2831] defined how HTTP Digest Authentication [RFC2617] can be 74 used as a Simple Authentication and Security Layer (SASL) [RFC4422] 75 mechanism for any protocol that has a SASL profile. It was intended 76 both as an improvement over CRAM-MD5 [RFC2195] and as a convenient 77 way to support a single authentication mechanism for web, mail, LDAP, 78 and other protocols. While it can be argued that it was an 79 improvement over CRAM-MD5, many implementors commented that the 80 additional complexity of DIGEST-MD5 made it difficult to implement 81 fully and securely. 83 Below is an incomplete list of problems with DIGEST-MD5 mechanism as 84 specified in RFC 2831: 86 1. The mechanism had too many options and modes. Some of them were 87 not well described and were not implemented. For example, 88 DIGEST-MD5 allowed the "qop" directive to contain multiple 89 values. But it also allowed for multiple qop directives to be 90 specified. Handling of multiple options was not specified, which 91 resulted in minor interoperability problems. Some 92 implementations amalgamated multiple qop values into one, while 93 others treated multiple qops as an error. Another example is use 94 of empty authorization identity. In SASL an empty authorization 95 identity means that the client is willing to authorize as the 96 authentication identity. The document was not clear on whether 97 the authzid must be omitted or can be specified with the empty 98 value to convey this. The requirement for backward compatibility 99 with HTTP Digest meant that the situation was even worse. For 100 example DIGEST-MD5 required all usernames/passwords which can be 101 entirely represented in ISO-8859-1 charset to be down converted 102 from UTF-8 to ISO-8859-1. Another example is use of quoted 103 strings. Handling of characters that needed escaping was not 104 properly described and the DIGEST-MD5 document had no examples to 105 demonstrate correct behavior. 107 2. The document used ABNF from RFC 822 [RFC0822], which allowes for 108 an extra construct and allows for "implied folding whitespace" to 109 be inserted in many places. Difference from ABNF [RFC4234] was 110 confusing for some implementors. As a result, many 111 implementations didn't allow for folding whitespaces in many 112 places where they were allowed. 114 3. The DIGEST-MD5 document uses a concept of "realm" to define a 115 collection of accounts. A DIGEST-MD5 server can support one or 116 more realms. The DIGEST-MD5 document didn't provide any guidance 117 on how realms should be named, and, more importantly, how they 118 can be entered in User Interfaces (UIs). As the result many 119 DIGEST-MD5 clients had confusing UI, didn't allow users to enter 120 a realm and/or didn't allow users to pick one of the server 121 supported realms. 123 4. Use of username in the inner hash. The inner hash of DIGEST-MD5 124 is an MD5 hash of colon separated username, realm and password. 125 Implementations may chose to store inner hashes instead of clear 126 text passwords. While this has some useful properties, such as 127 compromise of an authentication database on one server does not 128 automatically compromise an authentication database with the same 129 username and password on other servers, in practice this was 130 rarely done. Firstly, the inner hash is not compatible with 131 commonly deployed Unix password databases. Secondly, change of a 132 username invalidates the corresponding inner hash. 134 5. Description of DES/3DES and RC4 security layers are inadequate to 135 produce independently-developed interoperable implementations. 136 In the DES/3DES case this was partly a problem with existing DES 137 APIs. 139 6. DIGEST-MD5 outer hash (the value of the "response" directive) 140 didn't protect the whole authentication exchange, which made the 141 mechanism vulnerable to "man in the middle" MITM attacks, such as 142 modification of the list of supported qops or ciphers. 144 7. The following features are missing from DIGEST-MD5, which make it 145 insecure or insuitable for use in protocols: 147 A. Lack of channel bindings. 149 B. Lack of hash agility. MD5 hash is suffuciently weak to make 150 a brute force attack on DIGEST-MD5 easy with common hardware. 152 C. Lack of SASLPrep [RFC4013] support. The original DIGEST-MD5 153 document predates SASLPrep and doesn't recommend any Unicode 154 character normalization. 156 Note that most of the problems listed above are already present in 157 HTTP Digest authentication mechanism. 159 Bacause DIGEST-MD5 mechanism was defined as an extensible mechanism, 160 it would be possible to fix most of the problems listed above. 161 However this would increase implementation complexity of an already 162 complex mechanism even further, so the effort would not be worth the 163 cost. In addition, an implementation of a "fixed" DIGEST-MD5 164 specification would likely either not interoperate with any existing 165 implementation of RFC 2831, or would be vulnerable to various 166 downgrade attacks. 168 Note that despite DIGEST-MD5 seeing some deployment on the Internet, 169 this specification recommends obsoleting DIGEST-MD5 because DIGEST- 170 MD5, as implemented, is not a reasonable candidate for further 171 standardization and should be deprecated in favor of one or more new 172 password-based mechanisms currently being designed. 174 2. Security Considerations 176 Security issues are discussed through out this document. 178 3. IANA Considerations 180 IANA is requested to change the "Intended usage" of the DIGEST-MD5 181 mechanism registration in the SASL mechanism registry to OBSOLETE. 182 The SASL mechanism registry is specified in [RFC4422] and is 183 currently available at: 185 http://www.iana.org/assignments/sasl-mechanisms 187 4. Acknowledgements 189 The author gratefully acknowledges the feedback provided by Chris 190 Newman, Simon Josefsson and Kurt Zeilenga. [[anchor3: Various text 191 was copied from other RFCs.]] 193 5. References 195 5.1. Normative References 197 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 198 Leach, P., Luotonen, A., and L. Stewart, "HTTP 199 Authentication: Basic and Digest Access Authentication", 200 RFC 2617, June 1999. 202 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 203 SASL Mechanism", RFC 2831, May 2000. 205 5.2. Informative References 207 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 208 text messages", STD 11, RFC 822, August 1982. 210 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 211 AUTHorize Extension for Simple Challenge/Response", 212 RFC 2195, September 1997. 214 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 215 and Passwords", RFC 4013, February 2005. 217 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 218 Specifications: ABNF", RFC 4234, October 2005. 220 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 221 Security Layer (SASL)", RFC 4422, June 2006. 223 Author's Address 225 Alexey Melnikov 226 Isode Limited 227 5 Castle Business Village 228 36 Station Road 229 Hampton, Middlesex TW12 2BX 230 UK 232 Email: Alexey.Melnikov@isode.com 233 URI: http://www.melnikov.ca/ 235 Full Copyright Statement 237 Copyright (C) The IETF Trust (2007). 239 This document is subject to the rights, licenses and restrictions 240 contained in BCP 78, and except as set forth therein, the authors 241 retain all their rights. 243 This document and the information contained herein are provided on an 244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 246 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 247 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 248 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 251 Intellectual Property 253 The IETF takes no position regarding the validity or scope of any 254 Intellectual Property Rights or other rights that might be claimed to 255 pertain to the implementation or use of the technology described in 256 this document or the extent to which any license under such rights 257 might or might not be available; nor does it represent that it has 258 made any independent effort to identify any such rights. Information 259 on the procedures with respect to rights in RFC documents can be 260 found in BCP 78 and BCP 79. 262 Copies of IPR disclosures made to the IETF Secretariat and any 263 assurances of licenses to be made available, or the result of an 264 attempt made to obtain a general license or permission for the use of 265 such proprietary rights by implementers or users of this 266 specification can be obtained from the IETF on-line IPR repository at 267 http://www.ietf.org/ipr. 269 The IETF invites any interested party to bring to its attention any 270 copyrights, patents or patent applications, or other proprietary 271 rights that may cover technology that may be required to implement 272 this standard. Please address the information to the IETF at 273 ietf-ipr@ietf.org. 275 Acknowledgment 277 Funding for the RFC Editor function is provided by the IETF 278 Administrative Support Activity (IASA).