[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-sasl-crammd5-to-historic) 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/