RFC 2095 (rfc2095) - Page 2 of 5

IMAP/POP AUTHorize Extension for Simple Challenge/Response

RFC 2095              IMAP/POP AUTHorize Extension          January 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, 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).

   This mechanism also has the advantage over some possible alternatives
   of not requiring that the server maintain information about email
   "logins" on a per-login basis.  While mechanisms that do require such
   per-login history records may offer enhanced security, protocols such
   as IMAP, which may have several connections between a given client
   and server open more or less simultaneous, may make their
   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 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'
   [RFC 822] 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 explicit cleartext
   storage of the shared secret on the server system by instead storing
   the intermediate results which are known as "contexts".






Klensin, Catoe & Krumviede  Standards Track