doc/specification/rfc2195.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       J. Klensin
   8 Request for Comments: 2195                                    R. Catoe
   9 Category: Standards Track                                 P. Krumviede
  10 Obsoletes: 2095                                                    MCI
  11                                                         September 1997
  12
  13
  14        IMAP/POP AUTHorize Extension for Simple Challenge/Response
  15
  16 Status of this Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Abstract
  25
  26    While IMAP4 supports a number of strong authentication mechanisms as
  27    described in RFC 1731, it lacks any mechanism that neither passes
  28    cleartext, reusable passwords across the network nor requires either
  29    a significant security infrastructure or that the mail server update
  30    a mail-system-wide user authentication file on each mail access.
  31    This specification provides a simple challenge-response
  32    authentication protocol that is suitable for use with IMAP4.  Since
  33    it utilizes Keyed-MD5 digests and does not require that the secret be
  34    stored in the clear on the server, it may also constitute an
  35    improvement on APOP for POP3 use as specified in RFC 1734.
  36
  37 1. Introduction
  38
  39    Existing Proposed Standards specify an AUTHENTICATE mechanism for the
  40    IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
  41    the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
  42    intended to be extensible; the four methods specified in [IMAP-AUTH]
  43    are all fairly powerful and require some security infrastructure to
  44    support.  The base POP3 specification [POP3] also contains a
  45    lightweight challenge-response mechanism called APOP.  APOP is
  46    associated with most of the risks associated with such protocols: in
  47    particular, it requires that both the client and server machines have
  48    access to the shared secret in cleartext form. CRAM offers a method
  49    for avoiding such cleartext storage while retaining the algorithmic
  50    simplicity of APOP in using only MD5, though in a "keyed" method.
  51
  52
  53
  54
  55
  56
  57
  58 Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
  59 \f
  60 RFC 2195              IMAP/POP AUTHorize Extension        September 1997
  61
  62
  63    At present, IMAP [IMAP] lacks any facility corresponding to APOP.
  64    The only alternative to the strong mechanisms identified in [IMAP-
  65    AUTH] is a presumably cleartext username and password, supported
  66    through the LOGIN command in [IMAP].  This document describes a
  67    simple challenge-response mechanism, similar to APOP and PPP CHAP
  68    [PPP], that can be used with IMAP (and, in principle, with POP3).
  69
  70    This mechanism also has the advantage over some possible alternatives
  71    of not requiring that the server maintain information about email
  72    "logins" on a per-login basis.  While mechanisms that do require such
  73    per-login history records may offer enhanced security, protocols such
  74    as IMAP, which may have several connections between a given client
  75    and server open more or less simultaneous, may make their
  76    implementation particularly challenging.
  77
  78 2. Challenge-Response Authentication Mechanism (CRAM)
  79
  80    The authentication type associated with CRAM is "CRAM-MD5".
  81
  82    The data encoded in the first ready response contains an
  83    presumptively arbitrary string of random digits, a timestamp, and the
  84    fully-qualified primary host name of the server.  The syntax of the
  85    unencoded form must correspond to that of an RFC 822 'msg-id'
  86    [RFC822] as described in [POP3].
  87
  88    The client makes note of the data and then responds with a string
  89    consisting of the user name, a space, and a 'digest'.  The latter is
  90    computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
  91    the key is a shared secret and the digested text is the timestamp
  92    (including angle-brackets).
  93
  94    This shared secret is a string known only to the client and server.
  95    The `digest' parameter itself is a 16-octet value which is sent in
  96    hexadecimal format, using lower-case ASCII characters.
  97
  98    When the server receives this client response, it verifies the digest
  99    provided.  If the digest is correct, the server should consider the
 100    client authenticated and respond appropriately.
 101
 102    Keyed MD5 is chosen for this application because of the greater
 103    security imparted to authentication of short messages. In addition,
 104    the use of the techniques described in [KEYED-MD5] for precomputation
 105    of intermediate results make it possible to avoid explicit cleartext
 106    storage of the shared secret on the server system by instead storing
 107    the intermediate results which are known as "contexts".
 108
 109
 110
 111
 112
 113
 114 Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
 115 \f
 116 RFC 2195              IMAP/POP AUTHorize Extension        September 1997
 117
 118
 119    CRAM does not support a protection mechanism.
 120
 121    Example:
 122
 123    The examples in this document show the use of the CRAM mechanism with
 124    the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
 125    the challenges and responses is part of the IMAP4 AUTHENTICATE
 126    command, not part of the CRAM specification itself.
 127
 128      S: * OK IMAP4 Server
 129      C: A0001 AUTHENTICATE CRAM-MD5
 130      S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 131      C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 132      S: A0001 OK CRAM authentication successful
 133
 134       In this example, the shared secret is the string
 135       'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
 136       calculating
 137
 138         MD5((tanstaaftanstaaf XOR opad),
 139             MD5((tanstaaftanstaaf XOR ipad),
 140             <1896.697170952@postoffice.reston.mci.net>))
 141
 142       where ipad and opad are as defined in the keyed-MD5 Work in
 143       Progress [KEYED-MD5] and the string shown in the challenge is the
 144       base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
 145       shared secret is null-padded to a length of 64 bytes. If the
 146       shared secret is longer than 64 bytes, the MD5 digest of the
 147       shared secret is used as a 16 byte input to the keyed MD5
 148       calculation.
 149
 150       This produces a digest value (in hexadecimal) of
 151
 152            b913a602c7eda7a495b4e6e7334d3890
 153
 154       The user name is then prepended to it, forming
 155
 156            tim b913a602c7eda7a495b4e6e7334d3890
 157
 158       Which is then base64 encoded to meet the requirements of the IMAP4
 159       AUTHENTICATE command (or the similar POP3 AUTH command), yielding
 160
 161            dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 162
 163
 164
 165
 166
 167
 168
 169
 170 Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
 171 \f
 172 RFC 2195              IMAP/POP AUTHorize Extension        September 1997
 173
 174
 175 3. References
 176
 177    [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
 178        RFC 1334, October 1992.
 179
 180    [IMAP] Crispin, M., "Internet Message Access Protocol - Version
 181        4rev1", RFC 2060, University of Washington, December 1996.
 182
 183    [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
 184        RFC 1731, Carnegie Mellon, December 1994.
 185
 186    [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
 187        Message Authentication", RFC 2104, February 1997.
 188
 189    [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
 190        RFC 1321, MIT Laboratory for Computer Science, April 1992.
 191
 192    [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
 193        STD 53, RFC 1939, Carnegie Mellon, May 1996.
 194
 195    [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
 196        Carnegie Mellon, December, 1994.
 197
 198 4. Security Considerations
 199
 200    It is conjectured that use of the CRAM authentication mechanism
 201    provides origin identification and replay protection for a session.
 202    Accordingly, a server that implements both a cleartext password
 203    command and this authentication type should not allow both methods of
 204    access for a given user.
 205
 206    While the saving, on the server, of "contexts" (see section 2) is
 207    marginally better than saving the shared secrets in cleartext as is
 208    required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
 209    protect the secrets if the server itself is compromised.
 210    Consequently, servers that store the secrets or contexts must both be
 211    protected to a level appropriate to the potential information value
 212    in user mailboxes and identities.
 213
 214    As the length of the shared secret increases, so does the difficulty
 215    of deriving it.
 216
 217    While there are now suggestions in the literature that the use of MD5
 218    and keyed MD5 in authentication procedures probably has a limited
 219    effective lifetime, the technique is now widely deployed and widely
 220    understood.  It is believed that this general understanding may
 221    assist with the rapid replacement, by CRAM-MD5, of the current uses
 222    of permanent cleartext passwords in IMAP.   This document has been
 223
 224
 225
 226 Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
 227 \f
 228 RFC 2195              IMAP/POP AUTHorize Extension        September 1997
 229
 230
 231    deliberately written to permit easy upgrading to use SHA (or whatever
 232    alternatives emerge) when they are considered to be widely available
 233    and adequately safe.
 234
 235    Even with the use of CRAM, users are still vulnerable to active
 236    attacks.  An example of an increasingly common active attack is 'TCP
 237    Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
 238
 239    See section 1 above for additional discussion.
 240
 241 5. Acknowledgements
 242
 243    This memo borrows ideas and some text liberally from [POP3] and
 244    [RFC-1731] and thanks are due the authors of those documents.  Ran
 245    Atkinson made a number of valuable technical and editorial
 246    contributions to the document.
 247
 248 6. Authors' Addresses
 249
 250    John C. Klensin
 251    MCI Telecommunications
 252    800 Boylston St, 7th floor
 253    Boston, MA 02199
 254    USA
 255
 256    EMail: klensin@mci.net
 257    Phone: +1 617 960 1011
 258
 259    Randy Catoe
 260    MCI Telecommunications
 261    2100 Reston Parkway
 262    Reston, VA 22091
 263    USA
 264
 265    EMail: randy@mci.net
 266    Phone: +1 703 715 7366
 267
 268    Paul Krumviede
 269    MCI Telecommunications
 270    2100 Reston Parkway
 271    Reston, VA 22091
 272    USA
 273
 274    EMail: paul@mci.net
 275    Phone: +1 703 715 7251
 276
 277
 278
 279
 280
 281
 282 Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
 283 \f