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