idnits 2.17.1 draft-zeilenga-sasl-crammd5-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 209. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([SCRAM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document date (18 November 2008) is 5638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2095' is defined on line 149, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2095 (Obsoleted by RFC 2195) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- No information found for draft-newman-auth-scram-xx - is the name correct? -- No information found for draft-williams-on-channel-binding-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Informational Isode Limited 4 Expires in six months 18 November 2008 5 Obsoletes: 2195 7 CRAM-MD5 to historic 8 10 Status of this Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Informational document. 14 Distribution of this memo is unlimited. It is suggested that 15 technical discussion regarding this document take place on the IETF 16 SASL WG mailing list . Please send editorial 17 comments directly to the author . 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware have 21 been or will be disclosed, and any of which he or she becomes aware 22 will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright (C) The IETF Trust (2008). 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 This document recommends the retirement of the CRAM-MD5 authentication 47 mechanism, and discusses the reasons for doing so. This document 48 recommends RFC 2195 and its predecessor, RFC 2095, be moved to 49 Historic status. 51 [[Note to RFC Editor: please publish at same time that [SCRAM] is 52 published.]] 54 1. CRAM-MD5 56 CRAM-MD5 [RFC2195] is a authentication mechanism. It was originally 57 designed for use in Internet Messaging Access Protocol (IMAP) 58 [RFC3501] and Post Office Protocol (POP) [RFC1939]. It is also 59 registered as a Simple Authentication and Security Layer (SASL) 60 [RFC4422] mechanism [IANA-SASL], though it has not been formally 61 specified as SASL mechanism. 63 CRAM-MD5 is a simple challenge/response protocol for establishing that 64 both parties have knowledge of a shared secret derived from the user's 65 password, presumedly a sequence of characters. 67 While CRAM-MD5 is widely implemented and deployed on the Internet, 68 interoperability is only possible where the client and server have an 69 a priori agreement on the character set and encoding of the password, 70 and any normalization to be applied before input to the cryptographic 71 functions applied by both client and server. Even where the client 72 and server are implemented by the same developer, the client and 73 server will not operate properly in absence of an a priori agreement 74 (such as "passwords shall be a sequence of ASCII printable characters, 75 encoded in a octet with zero parity, with no normalization"). 77 CRAM-MD5 does not provide adequate security services for use on the 78 Internet. CRAM-MD5 does not protect the user's authentication 79 identifier from eavesdroppers. CRAM-MD5 challenge/response exchange 80 is subject to a number of passive and active attacks. 82 CRAM-MD5 does not provide any data security services nor channel 83 bindings [CBIND] to data security services (e.g., TLS [RFC5246]) 84 provided externally. 86 RFC 2195 states no recommendation (or mandate) that implementors only 87 offer CRAM-MD5 when external data security services are in place. RFC 88 2195 does not recommend (or mandate) that implementations supporting 89 CRAM-MD5 implement any external data security service. 91 While it possible to revise RFC 2195 to address these and other 92 deficiencies of the authentication mechanism, these changes would be 93 disruptive to existing deployments. For instance, if a revision were 94 to specify that a particular character set, encoding, and 95 normalization of the password is to be used, this mandate would 96 disruptive to deployers who use an incompatible character set, 97 encoding, and/or normalization. Addition of additional security 98 features, such as channel bindings, seems more appropriately done by 99 introduced in a new mechanism. 101 2. Recommendations 103 It is recommended RFC 2195 and its predecessor, RFC 2095, be moved to 104 Historic status. 106 It is recommended that application protocol designers and deployers 107 consider the SASL PLAIN [RFC4616] mechanism protected by TLS [RFC5246] 108 and/or the SASL Salted Challenge Response Authentication Mechanism 109 (SCRAM) [SCRAM] as alternatives to CRAM-MD5. 111 3. Security Considerations 113 The retirement of CRAM-MD5 may lead to use of stronger authentication 114 mechanisms and, hence, may improve Internet security. 116 4. IANA Considerations 118 It is requested that IANA update the SASL CRAM-MD5 registration upon 119 publication approval of this document. 121 Subject: Updated Registration of SASL CRAM-MD5 mechanism 122 SASL mechanism (or prefix for the family): CRAM-MD5 123 Security considerations: see RFC XXXX 124 Published specification (recommended): RFC XXXX 125 Person & email address to contact for further information: 126 Kurt Zeilenga 127 Intended usage: OBSOLETE 128 Owner/Change controller: IESG 130 7. Acknowledgments 132 TBD 134 8. Author's Address 136 Kurt D. Zeilenga 137 Isode Limited 139 Email: Kurt.Zeilenga@Isode.COM 141 9. References 143 [[Note to the RFC Editor: please replace the citation tags used in 144 referencing Internet-Drafts with tags of the form RFCnnnn where 145 possible.]] 147 9.1. Normative References 149 [RFC2095] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP 150 AUTHorize Extension for Simple Challenge/Response", RFC 151 2095, January 1997. 153 [RFC2195] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP 154 AUTHorize Extension for Simple Challenge/Response", RFC 155 2195, September 1997. 157 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 158 MECHANISMS", 159 . 161 9.2. Informative References 163 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 164 3", STD 53, RFC 1939, May 1996. 166 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 167 4rev1", RFC 3501, March 2003. 168 [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple 169 Authentication and Security Layer (SASL)", RFC 4422, 170 June 2006. 172 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 173 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 175 [RFC5246] Dierks, T. and, E. Rescorla, "The Transport Layer 176 Security (TLS) Protocol Version 1.2", RFC 5246, August 177 2008. 179 [SCRAM] Menon-Sen, Abhijit, C. Newman, "Salted Challenge 180 Response Authentication Mechanism (SCRAM)", draft- 181 newman-auth-scram-xx.txt, a work in progress. 183 [CBIND] Williams, N., "On the Use of Channel Bindings to Secure 184 Channels", draft-williams-on-channel-binding-xx.txt, a 185 work in progress. 187 Intellectual Property 189 The IETF takes no position regarding the validity or scope of any 190 Intellectual Property Rights or other rights that might be claimed to 191 pertain to the implementation or use of the technology described in 192 this document or the extent to which any license under such rights 193 might or might not be available; nor does it represent that it has 194 made any independent effort to identify any such rights. Information 195 on the procedures with respect to rights in RFC documents can be found 196 in BCP 78 and BCP 79. 198 Copies of IPR disclosures made to the IETF Secretariat and any 199 assurances of licenses to be made available, or the result of an 200 attempt made to obtain a general license or permission for the use of 201 such proprietary rights by implementers or users of this specification 202 can be obtained from the IETF on-line IPR repository at 203 http://www.ietf.org/ipr. 205 The IETF invites any interested party to bring to its attention any 206 copyrights, patents or patent applications, or other proprietary 207 rights that may cover technology that may be required to implement 208 this standard. Please address the information to the IETF at 209 ietf-ipr@ietf.org. 211 Full Copyright 213 Copyright (C) The IETF Trust (2008). 215 This document is subject to the rights, licenses and restrictions 216 contained in BCP 78, and except as set forth therein, the authors 217 retain all their rights. 219 This document and the information contained herein are provided on an 220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 222 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 223 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 224 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.