idnits 2.17.1 draft-zeilenga-luis140219-crammd5-to-historic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document obsoletes RFC2195, but the abstract doesn't seem to directly say this. It does mention RFC2195 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2095' is defined on line 142, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Kurt D. Zeilenga 2 Internet-Draft Isode Limited 3 Obsoletes: 2195 (if approved) L. Camara 4 Intended Status: Informational Individual 5 Expires: December 31, 2017 June 29, 2017 7 CRAM-MD5 to Historic 8 draft-zeilenga-luis140219-crammd5-to-historic-00 10 [[RFC-Editor: non-ASCII (RFC 7997) characters WILL be added in AUTH48.]] 12 Abstract 14 This document recommends the retirement of the CRAM-MD5 15 authentication mechanism, and discusses the reasons for doing so. 16 This document recommends RFC 2195 and its predecessor, RFC 2095, be 17 moved to Historic status. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 31, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. CRAM-MD5 53 CRAM-MD5 [RFC2195] is a authentication mechanism. It was originally 54 designed for use in Internet Messaging Access Protocol (IMAP) 55 [RFC3501] and Post Office Protocol (POP) [RFC1939]. It is also 56 registered as a Simple Authentication and Security Layer (SASL) 57 [RFC4422] mechanism [IANA-SASL], though it has not been formally 58 specified as SASL mechanism. 60 CRAM-MD5 is a simple challenge/response protocol for establishing 61 that both parties have knowledge of a shared secret derived from the 62 user's password, presumedly a sequence of characters. 64 While CRAM-MD5 is widely implemented and deployed on the Internet, 65 interoperability is only possible where the client and server have an 66 a priori agreement on the character set and encoding of the password, 67 and any normalization to be applied before input to the cryptographic 68 functions applied by both client and server. Even where the client 69 and server are implemented by the same developer, the client and 70 server will not operate properly in absence of an a priori agreement 71 (such as "passwords shall be a sequence of ASCII printable 72 characters, encoded in a octet with zero parity, with no 73 normalization"). 75 CRAM-MD5 does not provide adequate security services for use on the 76 Internet. CRAM-MD5 does not protect the user's authentication 77 identifier from eavesdroppers. CRAM-MD5 challenge/response exchange 78 is subject to a number of passive and active attacks. 80 CRAM-MD5 does not provide any data security services nor channel 81 bindings [RFC5056] to data security services (e.g., TLS [RFC5246]) 82 provided externally. Additionally, MD5 is fatally weak [RFC6151] and 83 renders CRAM-MD5 completely insecure in today's environment. 85 RFC 2195 states no recommendation (or mandate) that implementors only 86 offer CRAM-MD5 when external data security services are in place. 87 RFC 2195 does not recommend (or mandate) that implementations 88 supporting CRAM-MD5 implement any external data security service. 90 While it possible to revise RFC 2195 to address these and other 91 deficiencies of the authentication mechanism, these changes would be 92 disruptive to existing deployments. For instance, if a revision were 93 to specify that a particular character set, encoding, and 94 normalization of the password is to be used, this mandate would 95 disruptive to deployers who use an incompatible character set, 96 encoding, and/or normalization. Addition of additional security 97 features, such as channel bindings, seems more appropriately done by 98 introduced in a new mechanism. 100 2. Recommendations 102 It is recommended RFC 2195 and its predecessor, RFC 2095, be moved to 103 Historic status. 105 It is recommended that application protocol designers and deployers 106 consider the SASL PLAIN [RFC4616] mechanism protected by TLS 107 [RFC5246] and/or the SASL Salted Challenge Response Authentication 108 Mechanism (SCRAM) [RFC5802] as alternatives to CRAM-MD5. 110 3. Security Considerations 112 The retirement of CRAM-MD5 may lead to use of stronger authentication 113 mechanisms and, hence, may improve Internet security. 115 4. IANA Considerations 117 It is requested that IANA update the SASL CRAM-MD5 registration upon 118 publication approval of this document. 120 Subject: Updated Registration of SASL CRAM-MD5 mechanism 121 SASL mechanism (or prefix for the family): CRAM-MD5 122 Security considerations: see RFC XXXX 123 Published specification (recommended): RFC XXXX, RFC 2195 124 Person & email address to contact for further information: 125 Kurt Zeilenga 126 Intended usage: LIMITED 127 Owner/Change controller: IESG 129 5. References 131 5.1. Normative References 133 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 134 MECHANISMS", 135 . 137 5.2. Informative References 139 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 140 3", STD 53, RFC 1939, May 1996. 142 [RFC2095] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP 143 AUTHorize Extension for Simple Challenge/Response", RFC 144 2095, January 1997. 146 [RFC2195] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP 147 AUTHorize Extension for Simple Challenge/Response", RFC 148 2195, September 1997. 150 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 151 4rev1", RFC 3501, March 2003. 153 [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple 154 Authentication and Security Layer (SASL)", RFC 4422, 155 June 2006. 157 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 158 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 160 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 161 Channels", RFC 5056, November 2007. 163 [RFC5246] Dierks, T. and, E. Rescorla, "The Transport Layer 164 Security (TLS) Protocol Version 1.2", RFC 5246, August 165 2008. 167 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. 168 Williams, "Salted Challenge Response Authentication 169 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 170 2010. 172 [RFC6151] Turner, S., and L. Chen, "Updated Security 173 Considerations for the MD5 Message-Digest and the 174 HMAC-MD5 Algorithms", RFC 6151, March 2011. 176 6. Authors' Addresses 178 Kurt D. Zeilenga 179 Isode Limited 181 Email: Kurt.Zeilenga@Isode.COM 183 Luis Camara (a.k.a. luis140219) 184 Praceta das Tilias 102 R/C A 185 2775-336 Parede 186 Portugal 188 EMail: luis.camara@live.com.pt 190 Appendix A: Notes about -01 192 [[Do not change the below note in any revision, but this appendix 193 WILL be removed in AUTH48.]] 195 ("-00 draft" refers to the 2008 version.) 197 The new -00 draft is a revision of the 2008-11-20 -00 draft, that I 198 found expired and archived in the IETF Tools website. 200 The original draft was posted after November 10, 2008, so I have 201 put the RFC 5378 notice at the top of the draft. 203 I've replaced references to Internet-Drafts with the RFCs they've 204 turned onto (RFC 5802 and RFC 5056, respectively), as Kurt requested 205 in the -00 draft. 207 I've modernised the header: added "Internet Engineering Task Force 208 (IETF)", replaced the incorrect phrase "Expires in six months" with 209 "Expires December 31, 2017", added "(if approved)" to the Obsoletes 210 header, replaced "Category" with "Status" and moved headers around to 211 match the header order of a modern (2017-style) Internet-Draft. 213 The "Status of this Memo" section was renamed as a minor editorial 214 change to "Status of This Memo" (note casing) and was replaced using 215 the 2017-style boilerplate. 217 The abstract was moved to before the "Status of This Memo". 219 A sentence indicating MD5's fatal weaknesses was added to the end of 220 the 5th paragraph of Section 1, and an informative reference to 221 RFC 6151 was added. 223 RFC 2095 and RFC 2195 are normatively referenced in -00, but they 224 shouldn't be. The 2 references were moved to the informative 225 references section. The references were sorted by ASCII/UTF-8 order 226 of their names. 228 The indenting was changed from 2 to 3 spaces, and I've added myself 229 to the author's list. 231 There was also a reordering of the sections, correction of the 232 numbering, and removal of the "Acknowledgements" section, that 233 contained in -00 just "TBD" for almost 9 years. 235 The top line of every page except the first was changed to use 236 "CRAM-MD5 to Historic" instead of "CRAM-MD5", as this document moves 237 CRAM-MD5 to Historic instead of specifying CRAM-MD5. 239 Kurt, please update your email and affilliation if they've changed. 240 I've revived the draft because it is crucial that RFC 2195 (CRAM-MD5) 241 be moved to Historic. 243 The draft was taken off the SASL working group because it is 244 concluded. The new name is "zeilenga-luis140219-crammd5-to-historic". 246 -- luis140219 2017-06-29