rfc2095.txt (10446B)
1 2 3 4 5 6 7 Network Working Group J. Klensin 8 Request for Comments: 2095 R. Catoe 9 Category: Standards Track P. Krumviede 10 MCI 11 January 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 60 RFC 2095 IMAP/POP AUTHorize Extension January 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 116 RFC 2095 IMAP/POP AUTHorize Extension January 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 172 RFC 2095 IMAP/POP AUTHorize Extension January 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, H., "HMAC-MD5: Keyed-MD5 for Message 187 Authentication", Work in Progess. 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 228 RFC 2095 IMAP/POP AUTHorize Extension January 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