1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2195.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,283 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                       J. Klensin
    1.11 +Request for Comments: 2195                                    R. Catoe
    1.12 +Category: Standards Track                                 P. Krumviede
    1.13 +Obsoletes: 2095                                                    MCI
    1.14 +                                                        September 1997
    1.15 +
    1.16 +
    1.17 +       IMAP/POP AUTHorize Extension for Simple Challenge/Response
    1.18 +
    1.19 +Status of this Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Abstract
    1.28 +
    1.29 +   While IMAP4 supports a number of strong authentication mechanisms as
    1.30 +   described in RFC 1731, it lacks any mechanism that neither passes
    1.31 +   cleartext, reusable passwords across the network nor requires either
    1.32 +   a significant security infrastructure or that the mail server update
    1.33 +   a mail-system-wide user authentication file on each mail access.
    1.34 +   This specification provides a simple challenge-response
    1.35 +   authentication protocol that is suitable for use with IMAP4.  Since
    1.36 +   it utilizes Keyed-MD5 digests and does not require that the secret be
    1.37 +   stored in the clear on the server, it may also constitute an
    1.38 +   improvement on APOP for POP3 use as specified in RFC 1734.
    1.39 +
    1.40 +1. Introduction
    1.41 +
    1.42 +   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
    1.43 +   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
    1.44 +   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
    1.45 +   intended to be extensible; the four methods specified in [IMAP-AUTH]
    1.46 +   are all fairly powerful and require some security infrastructure to
    1.47 +   support.  The base POP3 specification [POP3] also contains a
    1.48 +   lightweight challenge-response mechanism called APOP.  APOP is
    1.49 +   associated with most of the risks associated with such protocols: in
    1.50 +   particular, it requires that both the client and server machines have
    1.51 +   access to the shared secret in cleartext form. CRAM offers a method
    1.52 +   for avoiding such cleartext storage while retaining the algorithmic
    1.53 +   simplicity of APOP in using only MD5, though in a "keyed" method.
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 2195              IMAP/POP AUTHorize Extension        September 1997
    1.64 +
    1.65 +
    1.66 +   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
    1.67 +   The only alternative to the strong mechanisms identified in [IMAP-
    1.68 +   AUTH] is a presumably cleartext username and password, supported
    1.69 +   through the LOGIN command in [IMAP].  This document describes a
    1.70 +   simple challenge-response mechanism, similar to APOP and PPP CHAP
    1.71 +   [PPP], that can be used with IMAP (and, in principle, with POP3).
    1.72 +
    1.73 +   This mechanism also has the advantage over some possible alternatives
    1.74 +   of not requiring that the server maintain information about email
    1.75 +   "logins" on a per-login basis.  While mechanisms that do require such
    1.76 +   per-login history records may offer enhanced security, protocols such
    1.77 +   as IMAP, which may have several connections between a given client
    1.78 +   and server open more or less simultaneous, may make their
    1.79 +   implementation particularly challenging.
    1.80 +
    1.81 +2. Challenge-Response Authentication Mechanism (CRAM)
    1.82 +
    1.83 +   The authentication type associated with CRAM is "CRAM-MD5".
    1.84 +
    1.85 +   The data encoded in the first ready response contains an
    1.86 +   presumptively arbitrary string of random digits, a timestamp, and the
    1.87 +   fully-qualified primary host name of the server.  The syntax of the
    1.88 +   unencoded form must correspond to that of an RFC 822 'msg-id'
    1.89 +   [RFC822] as described in [POP3].
    1.90 +
    1.91 +   The client makes note of the data and then responds with a string
    1.92 +   consisting of the user name, a space, and a 'digest'.  The latter is
    1.93 +   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
    1.94 +   the key is a shared secret and the digested text is the timestamp
    1.95 +   (including angle-brackets).
    1.96 +
    1.97 +   This shared secret is a string known only to the client and server.
    1.98 +   The `digest' parameter itself is a 16-octet value which is sent in
    1.99 +   hexadecimal format, using lower-case ASCII characters.
   1.100 +
   1.101 +   When the server receives this client response, it verifies the digest
   1.102 +   provided.  If the digest is correct, the server should consider the
   1.103 +   client authenticated and respond appropriately.
   1.104 +
   1.105 +   Keyed MD5 is chosen for this application because of the greater
   1.106 +   security imparted to authentication of short messages. In addition,
   1.107 +   the use of the techniques described in [KEYED-MD5] for precomputation
   1.108 +   of intermediate results make it possible to avoid explicit cleartext
   1.109 +   storage of the shared secret on the server system by instead storing
   1.110 +   the intermediate results which are known as "contexts".
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 2195              IMAP/POP AUTHorize Extension        September 1997
   1.120 +
   1.121 +
   1.122 +   CRAM does not support a protection mechanism.
   1.123 +
   1.124 +   Example:
   1.125 +
   1.126 +   The examples in this document show the use of the CRAM mechanism with
   1.127 +   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
   1.128 +   the challenges and responses is part of the IMAP4 AUTHENTICATE
   1.129 +   command, not part of the CRAM specification itself.
   1.130 +
   1.131 +     S: * OK IMAP4 Server
   1.132 +     C: A0001 AUTHENTICATE CRAM-MD5
   1.133 +     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
   1.134 +     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
   1.135 +     S: A0001 OK CRAM authentication successful
   1.136 +
   1.137 +      In this example, the shared secret is the string
   1.138 +      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
   1.139 +      calculating
   1.140 +
   1.141 +        MD5((tanstaaftanstaaf XOR opad),
   1.142 +            MD5((tanstaaftanstaaf XOR ipad),
   1.143 +            <1896.697170952@postoffice.reston.mci.net>))
   1.144 +
   1.145 +      where ipad and opad are as defined in the keyed-MD5 Work in
   1.146 +      Progress [KEYED-MD5] and the string shown in the challenge is the
   1.147 +      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
   1.148 +      shared secret is null-padded to a length of 64 bytes. If the
   1.149 +      shared secret is longer than 64 bytes, the MD5 digest of the
   1.150 +      shared secret is used as a 16 byte input to the keyed MD5
   1.151 +      calculation.
   1.152 +
   1.153 +      This produces a digest value (in hexadecimal) of
   1.154 +
   1.155 +           b913a602c7eda7a495b4e6e7334d3890
   1.156 +
   1.157 +      The user name is then prepended to it, forming
   1.158 +
   1.159 +           tim b913a602c7eda7a495b4e6e7334d3890
   1.160 +
   1.161 +      Which is then base64 encoded to meet the requirements of the IMAP4
   1.162 +      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
   1.163 +
   1.164 +           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
   1.165 +
   1.166 +
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 2195              IMAP/POP AUTHorize Extension        September 1997
   1.176 +
   1.177 +
   1.178 +3. References
   1.179 +
   1.180 +   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
   1.181 +       RFC 1334, October 1992.
   1.182 +
   1.183 +   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
   1.184 +       4rev1", RFC 2060, University of Washington, December 1996.
   1.185 +
   1.186 +   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
   1.187 +       RFC 1731, Carnegie Mellon, December 1994.
   1.188 +
   1.189 +   [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
   1.190 +       Message Authentication", RFC 2104, February 1997.
   1.191 +
   1.192 +   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
   1.193 +       RFC 1321, MIT Laboratory for Computer Science, April 1992.
   1.194 +
   1.195 +   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
   1.196 +       STD 53, RFC 1939, Carnegie Mellon, May 1996.
   1.197 +
   1.198 +   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
   1.199 +       Carnegie Mellon, December, 1994.
   1.200 +
   1.201 +4. Security Considerations
   1.202 +
   1.203 +   It is conjectured that use of the CRAM authentication mechanism
   1.204 +   provides origin identification and replay protection for a session.
   1.205 +   Accordingly, a server that implements both a cleartext password
   1.206 +   command and this authentication type should not allow both methods of
   1.207 +   access for a given user.
   1.208 +
   1.209 +   While the saving, on the server, of "contexts" (see section 2) is
   1.210 +   marginally better than saving the shared secrets in cleartext as is
   1.211 +   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
   1.212 +   protect the secrets if the server itself is compromised.
   1.213 +   Consequently, servers that store the secrets or contexts must both be
   1.214 +   protected to a level appropriate to the potential information value
   1.215 +   in user mailboxes and identities.
   1.216 +
   1.217 +   As the length of the shared secret increases, so does the difficulty
   1.218 +   of deriving it.
   1.219 +
   1.220 +   While there are now suggestions in the literature that the use of MD5
   1.221 +   and keyed MD5 in authentication procedures probably has a limited
   1.222 +   effective lifetime, the technique is now widely deployed and widely
   1.223 +   understood.  It is believed that this general understanding may
   1.224 +   assist with the rapid replacement, by CRAM-MD5, of the current uses
   1.225 +   of permanent cleartext passwords in IMAP.   This document has been
   1.226 +
   1.227 +
   1.228 +
   1.229 +Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 2195              IMAP/POP AUTHorize Extension        September 1997
   1.232 +
   1.233 +
   1.234 +   deliberately written to permit easy upgrading to use SHA (or whatever
   1.235 +   alternatives emerge) when they are considered to be widely available
   1.236 +   and adequately safe.
   1.237 +
   1.238 +   Even with the use of CRAM, users are still vulnerable to active
   1.239 +   attacks.  An example of an increasingly common active attack is 'TCP
   1.240 +   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
   1.241 +
   1.242 +   See section 1 above for additional discussion.
   1.243 +
   1.244 +5. Acknowledgements
   1.245 +
   1.246 +   This memo borrows ideas and some text liberally from [POP3] and
   1.247 +   [RFC-1731] and thanks are due the authors of those documents.  Ran
   1.248 +   Atkinson made a number of valuable technical and editorial
   1.249 +   contributions to the document.
   1.250 +
   1.251 +6. Authors' Addresses
   1.252 +
   1.253 +   John C. Klensin
   1.254 +   MCI Telecommunications
   1.255 +   800 Boylston St, 7th floor
   1.256 +   Boston, MA 02199
   1.257 +   USA
   1.258 +
   1.259 +   EMail: klensin@mci.net
   1.260 +   Phone: +1 617 960 1011
   1.261 +
   1.262 +   Randy Catoe
   1.263 +   MCI Telecommunications
   1.264 +   2100 Reston Parkway
   1.265 +   Reston, VA 22091
   1.266 +   USA
   1.267 +
   1.268 +   EMail: randy@mci.net
   1.269 +   Phone: +1 703 715 7366
   1.270 +
   1.271 +   Paul Krumviede
   1.272 +   MCI Telecommunications
   1.273 +   2100 Reston Parkway
   1.274 +   Reston, VA 22091
   1.275 +   USA
   1.276 +
   1.277 +   EMail: paul@mci.net
   1.278 +   Phone: +1 703 715 7251
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
   1.286 +