path: root/RFC/draft-klensin-cram-03.txt

Network Working Group                                        J Klensin
Internet Draft                                                 R Catoe
Document: draft-klensin-cram-03.txt                        P Krumviede  
                                                                   MCI
							September 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 reflects editorial
   comments received during the last call period; the protocol is
   unchanged from the previous version.  This draft will expire
   before February 22, 1997.  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 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.

   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". 
 
   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-MD5
     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
     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 XOR opad),
            MD5((tanstaaftanstaaf XOR ipad),
            <1896.697170952@postoffice.reston.mci.net>))

     where ipad and opad 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>. The
     shared secret is null-padded to a length of 64 bytes. If the
     shared secret is longer than 64 bytes, the MD5 digest of the
     shared secret is used as a 16 byte input to the keyed MD5
     calculation.

     This produces a digest value (in hexadecimal) of


	   b913a602c7eda7a495b4e6e7334d3890

     The user name is then prepended to it, forming

           tim b913a602c7eda7a495b4e6e7334d3890

     Which is then base64 encoded to meet the requirements of the IMAP4
     AUTHENTICATE command (or the similar POP3 AUTH command), yielding

           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw



3. References

   [CHAP]  Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
       RFC 1334, October 1992.

   [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 "HMAC-MD5: Keyed-MD5 for Message
       Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt),
       IBM, March 1996. 

   [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 ",
       RFC 1939 (STD 53), Carnegie Mellon, May 1996.

   [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.

   While the saving, on the server, of "contexts" (see section 2) is
   marginally better than saving the shared secrets in cleartext as is
   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
   protect the secrets if the server itself is compromised.
   Consequently, servers that store the secrets or contexts must both
   be protected to a level appropriate to the potential information
   value in user mailboxes and identities.

   As the length of the shared secret increases, so does the difficulty
   of deriving it.

   While there are now suggestions in the literature that the use of
   MD5 and keyed MD5 in authentication procedures probably has a
   limited effective lifetime, the technique is now widely deployed and
   widely understood.  It is believed that this general understanding
   may assist with the rapid replacement, by CRAM-MD5, of the current
   uses of permanent cleartext passwords in IMAP.   This document has
   been deliberately written to permit easy upgrading to use SHA (or
   whatever alternatives emerge) when they are considered to be widely
   available and adequately safe.

   Even with the use of CRAM, users are still vulnerable to active
   attacks.  An example of an increasingly common active attack is 'TCP
   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].

   See section 1 above for additional discussion.


5. Acknowledgements

   This memo borrows ideas and some text liberally from [POP3] and
   [RFC-1731] and thanks are due the authors of those documents.  Ran
   Atkinson made a number of valuable technical and editorial
   contributions to the current draft.


6. Authors' Addresses

 John C. Klensin
 MCI Telecommunications
 800 Boylston St, 7th floor
 Boston, MA 02199
 USA
    Email: klensin@mci.net
    Tel: +1 617 960 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