1
2
3
4
5
6
7Network Working Group                                       J. Klensin
8Request for Comments: 2195                                    R. Catoe
9Category: Standards Track                                 P. Krumviede
10Obsoletes: 2095                                                    MCI
11                                                        September 1997
12
13
14       IMAP/POP AUTHorize Extension for Simple Challenge/Response
15
16Status 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
24Abstract
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
371. 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
58Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
59
60RFC 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
782. 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
114Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
115
116RFC 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
170Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
171
172RFC 2195              IMAP/POP AUTHorize Extension        September 1997
173
174
1753. 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
1984. 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
226Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
227
228RFC 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
2415. 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
2486. 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
282Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
283
284