Network Working Group J Klensin
Internet Draft R Catoe
Document: draft-klensin-cram-00.txt P Krumviede
MCI
February 1996
IMAP/POP AUTHorize Extension for Simple Challenge/Response
Status of this Memo
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress``.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
A revised version of this draft document will be submitted to the
IESG for processing as a Proposed Standard for the Internet
Community, updating RFC 1731. Discussion and suggestions for
improvement are requested. This document will expire before July 15,
1996. Distribution of this draft is unlimited.
Abstract
While IMAP4 supports a number of strong authentication mechanisms
as described in RFC 1731, it lacks any mechanism that neither passes
cleartext, reusable passwords across the network nor requires a
significant security infrastructure. This specification provides a
simple challenge-response authentication protocol that is suitable for
use with IMAP4. Since it utilizes Keyed-MD5 digests and does not
require that the secret be stored in the clear on the server, it may
also constitute an improvement on APOP for POP3 use as specified in
RFC 1734.
1. Introduction
Existing Proposed Standards specify an AUTHENTICATE mechanism for
the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is intended
to be extensible; the four methods specified in [IMAP-AUTH] are all
fairly powerful and require some security infrastructure to support.
The base POP3 specification [POP3] also contains a lightweight
challenge-response mechanism called APOP. APOP is associated with
most of the risks associated with such protocols: in particular, it
requires that both the client and server machines have access to the
shared secret in cleartext form. CRAM offers a method for avoiding
such cleartext storage while retaining the algorithmic simplicity
of APOP in using only MD5, though in a "keyed" method.
At present, IMAP [IMAP] lacks any facility corresponding to APOP.
The only alternative to the strong mechanisms identified in
[IMAP-AUTH] is a cleartext username and password, supported through
the LOGIN command in [IMAP]. This document describes a simple
challenge-response mechanism, similar to APOP and PPP CHAP [PPP],
that can be used with IMAP (and, in principle, with POP3).
2. Challenge-Response Authentication Mechanism (CRAM)
The authentication type associated with CRAM is "CRAM".
The data encoded in the first ready response contains an
presumptively arbitrary string of random digits, a timestamp,
and the fully-qualified primary host name of the server. The
syntax of the 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 string
consisting of the user name, a space, and a 'digest'. The latter is
computed by applying the keyed MD5 algorithm from [KEYED-MD5]
where the key is a shared secret and the digested text is
the timestamp (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 in hexadecimal format, using lower-case ASCII characters.
When the server receives this client response, it verifies the digest
provided. If the digest is correct, the server should consider the
client authenticated and respond appropriately.
Keyed MD5 is chosen for this application because of the greater
security imparted to authentication of short messages. In addition,
the use of the techniques described in [KEYED-MD5] for
precomputation of intermediate results make it possible to avoid
storage of the shared secret on the server system by instead storing
the intermediate results which are known as "contexts".
CRAM does not support a protection mechanism.
Example:
The examples in this document show the use of the CRAM mechanism with
the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
the challenges and responses is part of the IMAP4 AUTHENTICATE
command, not part of the CRAM specification itself.
S: * OK IMAP4 Server
C: A0001 AUTHENTICATE CRAM
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
C: dGltIDljZjYxYjFlOTZiOGU1MGIxMmZlNTgxMjNhMzUyNDQy
S: A0001 OK CRAM authentication successful
In this example, the shared secret is the string 'tanstaaftanstaaf'.
Hence, the Keyed MD5 digest is produced by calculating
MD5(tanstaaftanstaaf, pad2,
MD5(tanstaaftanstaaf, pad1,
<1896.697170952@postoffice.reston.mci.net>))
where pad1 and pad2 are as defined in the keyed-MD5 draft
[KEYED-MD5] and the string shown in the challenge is the base64
encoding of <1896.697170952@postoffice.reston.mci.net>
This produces a digest value (in hexadecimal) of
9cf61b1e96b8e50b12fe58123a352442
The user name is then prepended to it, forming
tim 9cf61b1e96b8e50b12fe58123a352442
Which is then base64 encoded to meet the requirements of the IMAP4
AUTHENTICATE command (or the similar POP3 AUTH command), yielding
dGltIDljZjYxYjFlOTZiOGU1MGIxMmZlNTgxMjNhMzUyNDQy
3. References
[IMAP] Crispin, M. "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December, 1994.
[IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms",
RFC 1731, Carnegie Mellon, December, 1994
[KEYED-MD5] Krawczyk,H "Keyed-MD5 for Message Authentication"
work in progess (draft-krawczyk-keyed-md5-01.txt), IBM, November,
1995.
[MD5] Rivest, R. "The MD5 Message Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, April, 1992.
[POP3] Myers, J. "Post Office Protocol - Version 3 ",
RFC 1725, Carnegie Mellon, November, 1994
[POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie
Mellon, December, 1994.
4. Security Considerations
It is conjectured that use of the CRAM authentication mechanism
provides origin identification and replay protection for a session.
Accordingly, a server that implements both a cleartext password
command and this authentication type should not allow both methods of
access for a given user.
As the length of the shared secret increases, so does the difficulty
of deriving it.
See section 1 above for additional discussion.
13. Acknowledgements
This memo borrows ideas and some text liberally from [POP3] and
RFC-1731 and thanks are due the authors of those documents.
14. Authors' Addresses
John C. Klensin
MCI Telecommunications
800 Boylston St, 7th floor
Boston, MA 02199
USA
Email: klensin@mci.net
Tel: +1 617 859 1011
Randy Catoe
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA
Email: randy@mci.net
Tel: +1 703 715 7366
Paul Krumviede
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA
Email: paul@mci.net
Tel: +1 703 715 7251