One document matched: draft-zeilenga-sasl-crammd5-00.txt
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational Isode Limited
Expires in six months 18 November 2008
Obsoletes: 2195
CRAM-MD5 to historic
<draft-zeilenga-sasl-crammd5-00.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Informational document.
Distribution of this memo is unlimited. It is suggested that
technical discussion regarding this document take place on the IETF
SASL WG mailing list <ietf-sasl@imc.org>. Please send editorial
comments directly to the author <Kurt.Zeilenga@Isode.COM>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The IETF Trust (2008).
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 1]
INTERNET-DRAFT CRAM-MD5 18 November 2008
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.
[[Note to RFC Editor: please publish at same time that [SCRAM] is
published.]]
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
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 [CBIND] to data security services (e.g., TLS [RFC5246])
provided externally.
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.
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 2]
INTERNET-DRAFT CRAM-MD5 18 November 2008
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
consider the SASL PLAIN [RFC4616] mechanism protected by TLS [RFC5246]
and/or the SASL Salted Challenge Response Authentication Mechanism
(SCRAM) [SCRAM] 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
Person & email address to contact for further information:
Kurt Zeilenga <kurt.zeilenga@isode.com>
Intended usage: OBSOLETE
Owner/Change controller: IESG
7. Acknowledgments
TBD
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 3]
INTERNET-DRAFT CRAM-MD5 18 November 2008
8. Author's Address
Kurt D. Zeilenga
Isode Limited
Email: Kurt.Zeilenga@Isode.COM
9. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
9.1. Normative References
[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.
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
MECHANISMS",
<http://www.iana.org/assignments/sasl-mechanisms>.
9.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[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.
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC5246] Dierks, T. and, E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 4]
INTERNET-DRAFT CRAM-MD5 18 November 2008
[SCRAM] Menon-Sen, Abhijit, C. Newman, "Salted Challenge
Response Authentication Mechanism (SCRAM)", draft-
newman-auth-scram-xx.txt, a work in progress.
[CBIND] Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-williams-on-channel-binding-xx.txt, a
work in progress.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 5]
INTERNET-DRAFT CRAM-MD5 18 November 2008
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga draft-zeilenga-sasl-crammd5-00 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 04:17:16 |