As per Relevance of the word mechanism, we have this rfc below:
Network Working Group J.
Request for Comments: 2195 R.
Category: Standards Track P.
Obsoletes: 2095
September 1997
IMAP/POP AUTHorize Extension for Simple Challenge/
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
While IMAP4 supports a number of strong authentication mechanisms
described in RFC 1731, it lacks any mechanism that neither
cleartext, reusable passwords across the network nor requires
a significant security infrastructure or that the mail server
a mail-system-wide user authentication file on each mail access
This specification provides a simple challenge-
authentication protocol that is suitable for use with IMAP4.
it utilizes Keyed-MD5 digests and does not require that the secret
stored in the clear on the server, it may also constitute
improvement on APOP for POP3 use as specified in RFC 1734.
1.
Existing Proposed Standards specify an AUTHENTICATE mechanism for
IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism
the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism
intended to be extensible; the four methods specified in [IMAP-AUTH
are all fairly powerful and require some security infrastructure
support. The base POP3 specification [POP3] also contains
lightweight challenge-response mechanism called APOP. APOP
associated with most of the risks associated with such protocols:
particular, it requires that both the client and server machines
access to the shared secret in cleartext form. CRAM offers a
for avoiding such cleartext storage while retaining the
simplicity of APOP in using only MD5, though in a "keyed" method
Klensin, Catoe & Krumviede Standards Track [Page 1]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
At present, IMAP [IMAP] lacks any facility corresponding to APOP
The only alternative to the strong mechanisms identified in [IMAP
AUTH] is a presumably cleartext username and password,
through the LOGIN command in [IMAP]. This document describes
simple challenge-response mechanism, similar to APOP and PPP
[PPP], that can be used with IMAP (and, in principle, with POP3).
This mechanism also has the advantage over some possible
of not requiring that the server maintain information about
"logins" on a per-login basis. While mechanisms that do require
per-login history records may offer enhanced security, protocols
as IMAP, which may have several connections between a given
and server open more or less simultaneous, may make
implementation particularly challenging
2. Challenge-Response Authentication Mechanism (CRAM
The authentication type associated with CRAM is "CRAM-MD5".
The data encoded in the first ready response contains
presumptively arbitrary string of random digits, a timestamp, and
fully-qualified primary host name of the server. The syntax of
unencoded form must correspond to that of an RFC 822 'msg-id
[RFC822] as described in [POP3].
The client makes note of the data and then responds with a
consisting of the user name, a space, and a 'digest'. The latter
computed by applying the keyed MD5 algorithm from [KEYED-MD5]
the key is a shared secret and the digested text is the
(including angle-brackets).
This shared secret is a string known only to the client and server
The `digest' parameter itself is a 16-octet value which is sent
hexadecimal format, using lower-case ASCII characters
When the server receives this client response, it verifies the
provided. If the digest is correct, the server should consider
client authenticated and respond appropriately
Keyed MD5 is chosen for this application because of the
security imparted to authentication of short messages. In addition
the use of the techniques described in [KEYED-MD5] for
of intermediate results make it possible to avoid explicit
storage of the shared secret on the server system by instead
the intermediate results which are known as "contexts".
Klensin, Catoe & Krumviede Standards Track [Page 2]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
CRAM does not support a protection mechanism
Example
The examples in this document show the use of the CRAM mechanism
the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding
the challenges and responses is part of the IMAP4
command, not part of the CRAM specification itself
S: * OK IMAP4
C: A0001 AUTHENTICATE CRAM-MD
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ
C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0
S: A0001 OK CRAM authentication
In this example, the shared secret is the
'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced
MD5((tanstaaftanstaaf XOR opad),
MD5((tanstaaftanstaaf XOR ipad),
<1896.697170952@postoffice.reston.mci.net>))
where ipad and opad are as defined in the keyed-MD5 Work
Progress [KEYED-MD5] and the string shown in the challenge is
base64 encoding of <1896.697170952@postoffice.reston.mci.net>.
shared secret is null-padded to a length of 64 bytes. If
shared secret is longer than 64 bytes, the MD5 digest of
shared secret is used as a 16 byte input to the keyed MD
calculation
This produces a digest value (in hexadecimal)
b913a602c7eda7a495b4e6e7334d3890
The user name is then prepended to it,
tim b913a602c7eda7a495b4e6e7334d3890
Which is then base64 encoded to meet the requirements of the IMAP
AUTHENTICATE command (or the similar POP3 AUTH command),
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0
Klensin, Catoe & Krumviede Standards Track [Page 3]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
3.
[CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992.
[IMAP] Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, University of Washington, December 1996.
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
RFC 1731, Carnegie Mellon, December 1994.
[KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing
Message Authentication", RFC 2104, February 1997.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, April 1992.
[POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, Carnegie Mellon, May 1996.
[POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
Carnegie Mellon, December, 1994.
4. Security
It is conjectured that use of the CRAM authentication
provides origin identification and replay protection for a session
Accordingly, a server that implements both a cleartext
command and this authentication type should not allow both methods
access for a given user
While the saving, on the server, of "contexts" (see section 2)
marginally better than saving the shared secrets in cleartext as
required by CHAP [CHAP] and APOP [POP3], it is not sufficient
protect the secrets if the server itself is compromised
Consequently, servers that store the secrets or contexts must both
protected to a level appropriate to the potential information
in user mailboxes and identities
As the length of the shared secret increases, so does the
of deriving it
While there are now suggestions in the literature that the use of MD
and keyed MD5 in authentication procedures probably has a
effective lifetime, the technique is now widely deployed and
understood. It is believed that this general understanding
assist with the rapid replacement, by CRAM-MD5, of the current
of permanent cleartext passwords in IMAP. This document has
Klensin, Catoe & Krumviede Standards Track [Page 4]
RFC 2195 IMAP/POP AUTHorize Extension September 1997
deliberately written to permit easy upgrading to use SHA (or
alternatives emerge) when they are considered to be widely
and adequately safe
Even with the use of CRAM, users are still vulnerable to
attacks. An example of an increasingly common active attack is '
Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
See section 1 above for additional discussion
5.
This memo borrows ideas and some text liberally from [POP3]
[RFC-1731] and thanks are due the authors of those documents.
Atkinson made a number of valuable technical and
contributions to the document
6. Authors'
John C.
MCI
800 Boylston St, 7th
Boston, MA 02199
EMail: klensin@mci.
Phone: +1 617 960 1011
Randy
MCI
2100 Reston
Reston, VA 22091
EMail: randy@mci.
Phone: +1 703 715 7366
Paul
MCI
2100 Reston
Reston, VA 22091
EMail: paul@mci.
Phone: +1 703 715 7251
Klensin, Catoe & Krumviede Standards Track [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
