IMAP/POP AUTHorize Extension for Simple Challenge/Response
RFC 2195

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                       J. Klensin
Request for Comments: 2195                                    R. Catoe
Category: Standards Track                                 P. Krumviede
Obsoletes: 2095                                                    MCI
                                                        September 1997

       IMAP/POP AUTHorize Extension for Simple Challenge/Response

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo 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 either
   a significant security infrastructure or that the mail server update
   a mail-system-wide user authentication file on each mail access.
   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.

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, 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'
   [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 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                     [Page 2]