Internet DRAFT - draft-zeilenga-luis140219-crammd5-to-historic
draft-zeilenga-luis140219-crammd5-to-historic
Internet Engineering Task Force (IETF) Kurt D. Zeilenga
Internet-Draft Isode Limited
Obsoletes: 2195 (if approved) L. Camara
Intended Status: Informational Individual
Expires: December 31, 2017 June 29, 2017
CRAM-MD5 to Historic
draft-zeilenga-luis140219-crammd5-to-historic-00
[[RFC-Editor: non-ASCII (RFC 7997) characters WILL be added in AUTH48.]]
Abstract
This document recommends the retirement of the CRAM-MD5
authentication mechanism, and discusses the reasons for doing so.
This document recommends RFC 2195 and its predecessor, RFC 2095, be
moved to Historic status.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2017.
Copyright Notice
Copyright (c) 2017 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.
1. CRAM-MD5
CRAM-MD5 [RFC2195] is a authentication mechanism. It was originally
designed for use in Internet Messaging Access Protocol (IMAP)
[RFC3501] and Post Office Protocol (POP) [RFC1939]. It is also
Zeilenga & Camara [Page 1]
Internet-Draft CRAM-MD5 to Historic June 2017
registered as a Simple Authentication and Security Layer (SASL)
[RFC4422] mechanism [IANA-SASL], though it has not been formally
specified as SASL mechanism.
CRAM-MD5 is a simple challenge/response protocol for establishing
that both parties have knowledge of a shared secret derived from the
user's password, presumedly a sequence of characters.
While CRAM-MD5 is widely implemented and deployed on the Internet,
interoperability is only possible where the client and server have an
a priori agreement on the character set and encoding of the password,
and any normalization to be applied before input to the cryptographic
functions applied by both client and server. Even where the client
and server are implemented by the same developer, the client and
server will not operate properly in absence of an a priori agreement
(such as "passwords shall be a sequence of ASCII printable
characters, encoded in a octet with zero parity, with no
normalization").
CRAM-MD5 does not provide adequate security services for use on the
Internet. CRAM-MD5 does not protect the user's authentication
identifier from eavesdroppers. CRAM-MD5 challenge/response exchange
is subject to a number of passive and active attacks.
CRAM-MD5 does not provide any data security services nor channel
bindings [RFC5056] to data security services (e.g., TLS [RFC5246])
provided externally. Additionally, MD5 is fatally weak [RFC6151] and
renders CRAM-MD5 completely insecure in today's environment.
RFC 2195 states no recommendation (or mandate) that implementors only
offer CRAM-MD5 when external data security services are in place.
RFC 2195 does not recommend (or mandate) that implementations
supporting CRAM-MD5 implement any external data security service.
While it possible to revise RFC 2195 to address these and other
deficiencies of the authentication mechanism, these changes would be
disruptive to existing deployments. For instance, if a revision were
to specify that a particular character set, encoding, and
normalization of the password is to be used, this mandate would
disruptive to deployers who use an incompatible character set,
encoding, and/or normalization. Addition of additional security
features, such as channel bindings, seems more appropriately done by
introduced in a new mechanism.
2. Recommendations
It is recommended RFC 2195 and its predecessor, RFC 2095, be moved to
Historic status.
It is recommended that application protocol designers and deployers
Zeilenga & Camara [Page 2]
Internet-Draft CRAM-MD5 to Historic June 2017
consider the SASL PLAIN [RFC4616] mechanism protected by TLS
[RFC5246] and/or the SASL Salted Challenge Response Authentication
Mechanism (SCRAM) [RFC5802] as alternatives to CRAM-MD5.
3. Security Considerations
The retirement of CRAM-MD5 may lead to use of stronger authentication
mechanisms and, hence, may improve Internet security.
4. IANA Considerations
It is requested that IANA update the SASL CRAM-MD5 registration upon
publication approval of this document.
Subject: Updated Registration of SASL CRAM-MD5 mechanism
SASL mechanism (or prefix for the family): CRAM-MD5
Security considerations: see RFC XXXX
Published specification (recommended): RFC XXXX, RFC 2195
Person & email address to contact for further information:
Kurt Zeilenga <kurt.zeilenga@isode.com>
Intended usage: LIMITED
Owner/Change controller: IESG
5. References
5.1. Normative References
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
MECHANISMS",
<http://www.iana.org/assignments/sasl-mechanisms>.
5.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC2095] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2095, January 1997.
[RFC2195] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
Zeilenga & Camara [Page 3]
Internet-Draft CRAM-MD5 to Historic June 2017
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5246] Dierks, T. and, E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
Williams, "Salted Challenge Response Authentication
(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.
6. Authors' Addresses
Kurt D. Zeilenga
Isode Limited
Email: Kurt.Zeilenga@Isode.COM
Luis Camara (a.k.a. luis140219)
Praceta das Tilias 102 R/C A
2775-336 Parede
Portugal
EMail: luis.camara@live.com.pt
Appendix A: Notes about -01
[[Do not change the below note in any revision, but this appendix
WILL be removed in AUTH48.]]
("-00 draft" refers to the 2008 version.)
The new -00 draft is a revision of the 2008-11-20 -00 draft, that I
found expired and archived in the IETF Tools website.
The original draft was posted after November 10, 2008, so I have
put the RFC 5378 notice at the top of the draft.
I've replaced references to Internet-Drafts with the RFCs they've
turned onto (RFC 5802 and RFC 5056, respectively), as Kurt requested
in the -00 draft.
I've modernised the header: added "Internet Engineering Task Force
Zeilenga & Camara [Page 4]
Internet-Draft CRAM-MD5 to Historic June 2017
(IETF)", replaced the incorrect phrase "Expires in six months" with
"Expires December 31, 2017", added "(if approved)" to the Obsoletes
header, replaced "Category" with "Status" and moved headers around to
match the header order of a modern (2017-style) Internet-Draft.
The "Status of this Memo" section was renamed as a minor editorial
change to "Status of This Memo" (note casing) and was replaced using
the 2017-style boilerplate.
The abstract was moved to before the "Status of This Memo".
A sentence indicating MD5's fatal weaknesses was added to the end of
the 5th paragraph of Section 1, and an informative reference to
RFC 6151 was added.
RFC 2095 and RFC 2195 are normatively referenced in -00, but they
shouldn't be. The 2 references were moved to the informative
references section. The references were sorted by ASCII/UTF-8 order
of their names.
The indenting was changed from 2 to 3 spaces, and I've added myself
to the author's list.
There was also a reordering of the sections, correction of the
numbering, and removal of the "Acknowledgements" section, that
contained in -00 just "TBD" for almost 9 years.
The top line of every page except the first was changed to use
"CRAM-MD5 to Historic" instead of "CRAM-MD5", as this document moves
CRAM-MD5 to Historic instead of specifying CRAM-MD5.
Kurt, please update your email and affilliation if they've changed.
I've revived the draft because it is crucial that RFC 2195 (CRAM-MD5)
be moved to Historic.
The draft was taken off the SASL working group because it is
concluded. The new name is "zeilenga-luis140219-crammd5-to-historic".
-- luis140219 2017-06-29
Zeilenga & Camara [Page 5]
