imapext-2007
view docs/rfc/rfc2195.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
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
14 IMAP/POP AUTHorize Extension for Simple Challenge/Response
16 Status of this Memo
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.
24 Abstract
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.
37 1. Introduction
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.
58 Klensin, Catoe & Krumviede Standards Track [Page 1]
60 RFC 2195 IMAP/POP AUTHorize Extension September 1997
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).
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.
78 2. Challenge-Response Authentication Mechanism (CRAM)
80 The authentication type associated with CRAM is "CRAM-MD5".
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].
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).
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.
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.
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".
114 Klensin, Catoe & Krumviede Standards Track [Page 2]
116 RFC 2195 IMAP/POP AUTHorize Extension September 1997
119 CRAM does not support a protection mechanism.
121 Example:
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.
128 S: * OK IMAP4 Server
129 C: A0001 AUTHENTICATE CRAM-MD5
130 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
131 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
132 S: A0001 OK CRAM authentication successful
134 In this example, the shared secret is the string
135 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
136 calculating
138 MD5((tanstaaftanstaaf XOR opad),
139 MD5((tanstaaftanstaaf XOR ipad),
140 <1896.697170952@postoffice.reston.mci.net>))
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.
150 This produces a digest value (in hexadecimal) of
152 b913a602c7eda7a495b4e6e7334d3890
154 The user name is then prepended to it, forming
156 tim b913a602c7eda7a495b4e6e7334d3890
158 Which is then base64 encoded to meet the requirements of the IMAP4
159 AUTHENTICATE command (or the similar POP3 AUTH command), yielding
161 dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
170 Klensin, Catoe & Krumviede Standards Track [Page 3]
172 RFC 2195 IMAP/POP AUTHorize Extension September 1997
175 3. References
177 [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
178 RFC 1334, October 1992.
180 [IMAP] Crispin, M., "Internet Message Access Protocol - Version
181 4rev1", RFC 2060, University of Washington, December 1996.
183 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
184 RFC 1731, Carnegie Mellon, December 1994.
186 [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
187 Message Authentication", RFC 2104, February 1997.
189 [MD5] Rivest, R., "The MD5 Message Digest Algorithm",
190 RFC 1321, MIT Laboratory for Computer Science, April 1992.
192 [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
193 STD 53, RFC 1939, Carnegie Mellon, May 1996.
195 [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
196 Carnegie Mellon, December, 1994.
198 4. Security Considerations
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.
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.
214 As the length of the shared secret increases, so does the difficulty
215 of deriving it.
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
226 Klensin, Catoe & Krumviede Standards Track [Page 4]
228 RFC 2195 IMAP/POP AUTHorize Extension September 1997
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.
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].
239 See section 1 above for additional discussion.
241 5. Acknowledgements
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.
248 6. Authors' Addresses
250 John C. Klensin
251 MCI Telecommunications
252 800 Boylston St, 7th floor
253 Boston, MA 02199
254 USA
256 EMail: klensin@mci.net
257 Phone: +1 617 960 1011
259 Randy Catoe
260 MCI Telecommunications
261 2100 Reston Parkway
262 Reston, VA 22091
263 USA
265 EMail: randy@mci.net
266 Phone: +1 703 715 7366
268 Paul Krumviede
269 MCI Telecommunications
270 2100 Reston Parkway
271 Reston, VA 22091
272 USA
274 EMail: paul@mci.net
275 Phone: +1 703 715 7251
282 Klensin, Catoe & Krumviede Standards Track [Page 5]