rfc1731.txt (11433B)
1 2 3 4 5 6 7 Network Working Group J. Myers 8 Request for Comments: 1731 Carnegie Mellon 9 Category: Standards Track December 1994 10 11 12 IMAP4 Authentication Mechanisms 13 14 Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 23 1. Introduction 24 25 The Internet Message Access Protocol, Version 4 [IMAP4] contains the 26 AUTHENTICATE command, for identifying and authenticating a user to an 27 IMAP4 server and for optionally negotiating a protection mechanism 28 for subsequent protocol interactions. This document describes 29 several authentication mechanisms for use by the IMAP4 AUTHENTICATE 30 command. 31 32 33 2. Kerberos version 4 authentication mechanism 34 35 The authentication type associated with Kerberos version 4 is 36 "KERBEROS_V4". 37 38 The data encoded in the first ready response contains a random 32-bit 39 number in network byte order. The client should respond with a 40 Kerberos ticket and an authenticator for the principal 41 "imap.hostname@realm", where "hostname" is the first component of the 42 host name of the server with all letters in lower case and where 43 "realm" is the Kerberos realm of the server. The encrypted checksum 44 field included within the Kerberos authenticator should contain the 45 server provided 32-bit number in network byte order. 46 47 Upon decrypting and verifying the ticket and authenticator, the 48 server should verify that the contained checksum field equals the 49 original server provided random 32-bit number. Should the 50 verification be successful, the server must add one to the checksum 51 and construct 8 octets of data, with the first four octets containing 52 the incremented checksum in network byte order, the fifth octet 53 containing a bit-mask specifying the protection mechanisms supported 54 by the server, and the sixth through eighth octets containing, in 55 56 57 58 Myers [Page 1] 59 60 RFC 1731 IMAP4 Authentication Mechanisms December 1994 61 62 63 network byte order, the maximum cipher-text buffer size the server is 64 able to receive. The server must encrypt the 8 octets of data in the 65 session key and issue that encrypted data in a second ready response. 66 The client should consider the server authenticated if the first four 67 octets the un-encrypted data is equal to one plus the checksum it 68 previously sent. 69 70 The client must construct data with the first four octets containing 71 the original server-issued checksum in network byte order, the fifth 72 octet containing the bit-mask specifying the selected protection 73 mechanism, the sixth through eighth octets containing in network byte 74 order the maximum cipher-text buffer size the client is able to 75 receive, and the following octets containing a user name string. The 76 client must then append from one to eight octets so that the length 77 of the data is a multiple of eight octets. The client must then PCBC 78 encrypt the data with the session key and respond to the second ready 79 response with the encrypted data. The server decrypts the data and 80 verifies the contained checksum. The username field identifies the 81 user for whom subsequent IMAP operations are to be performed; the 82 server must verify that the principal identified in the Kerberos 83 ticket is authorized to connect as that user. After these 84 verifications, the authentication process is complete. 85 86 The protection mechanisms and their corresponding bit-masks are as 87 follows: 88 89 1 No protection mechanism 90 2 Integrity (krb_mk_safe) protection 91 4 Privacy (krb_mk_priv) protection 92 93 94 EXAMPLE: The following are two Kerberos version 4 login scenarios 95 (note that the line breaks in the sample authenticators are for 96 editorial clarity and are not in real authenticators) 97 98 S: * OK IMAP4 Server 99 C: A001 AUTHENTICATE KERBEROS_V4 100 S: + AmFYig== 101 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 102 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 103 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 104 S: + or//EoAADZI= 105 C: DiAF5A4gA+oOIALuBkAAmw== 106 S: A001 OK Kerberos V4 authentication successful 107 108 109 110 111 112 113 114 Myers [Page 2] 115 116 RFC 1731 IMAP4 Authentication Mechanisms December 1994 117 118 119 S: * OK IMAP4 Server 120 C: A001 AUTHENTICATE KERBEROS_V4 121 S: + gcfgCA== 122 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 123 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 124 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 125 S: A001 NO Kerberos V4 authentication failed 126 127 128 3. GSSAPI authentication mechanism 129 130 The authentication type associated with all mechanisms employing the 131 GSSAPI [RFC1508] is "GSSAPI". 132 133 The first ready response issued by the server contains no data. The 134 client should call GSS_Init_sec_context, passing in 0 for 135 input_context_handle (initially) and a targ_name equal to output_name 136 from GSS_Import_Name called with input_name_type of NULL and 137 input_name_string of "SERVICE:imap@hostname" where "hostname" is the 138 fully qualified host name of the server with all letters in lower 139 case. The client must then respond with the resulting output_token. 140 If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client 141 should expect the server to issue a token in a subsequent ready 142 response. The client must pass the token to another call to 143 GSS_Init_sec_context. 144 145 If GSS_Init_sec_context returns GSS_COMPLETE, then the client should 146 respond with any resulting output_token. If there is no 147 output_token, the client should respond with no data. The client 148 should then expect the server to issue a token in a subsequent ready 149 response. The client should pass this token to GSS_Unseal and 150 interpret the first octet of resulting cleartext as a bit-mask 151 specifying the protection mechanisms supported by the server and the 152 second through fourth octets as the maximum size output_message to 153 send to the server. The client should construct data, with the first 154 octet containing the bit-mask specifying the selected protection 155 mechanism, the second through fourth octets containing in network 156 byte order the maximum size output_message the client is able to 157 receive, and the remaining octets containing a user name string. The 158 client must pass the data to GSS_Seal with conf_flag set to FALSE, 159 and respond with the generated output_message. The client can then 160 consider the server authenticated. 161 162 The server must issue a ready response with no data and pass the 163 resulting client supplied token to GSS_Accept_sec_context as 164 input_token, setting acceptor_cred_handle to NULL (for "use default 165 credentials"), and 0 for input_context_handle (initially). If 166 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should 167 168 169 170 Myers [Page 3] 171 172 RFC 1731 IMAP4 Authentication Mechanisms December 1994 173 174 175 return the generated output_token to the client in a ready response 176 and pass the resulting client supplied token to another call to 177 GSS_Accept_sec_context. 178 179 If GSS_Accept_sec_context returns GSS_COMPLETE, then if an 180 output_token is returned, the server should return it to the client 181 in a ready response and expect a reply from the client with no data. 182 Whether or not an output_token was returned, the server then should 183 then construct 4 octets of data, with the first octet containing a 184 bit-mask specifying the protection mechanisms supported by the server 185 and the second through fourth octets containing in network byte order 186 the maximum size output_token the server is able to receive. The 187 server must then pass the plaintext to GSS_Seal with conf_flag set to 188 FALSE and issue the generated output_message to the client in a ready 189 response. The server must then pass the resulting client supplied 190 token to GSS_Unseal and interpret the first octet of resulting 191 cleartext as the bit-mask for the selected protection mechanism, the 192 second through fourth octets as the maximum size output_message to 193 send to the client, and the remaining octets as the user name. Upon 194 verifying the src_name is authorized to authenticate as the user 195 name, The server should then consider the client authenticated. 196 197 The protection mechanisms and their corresponding bit-masks are as 198 follows: 199 200 1 No protection mechanism 201 2 Integrity protection. 202 Sender calls GSS_Seal with conf_flag set to FALSE 203 4 Privacy protection. 204 Sender calls GSS_Seal with conf_flag set to TRUE 205 206 207 4. S/Key authentication mechanism 208 209 The authentication type associated with S/Key [SKEY] is "SKEY". 210 211 The first ready response issued by the server contains no data. The 212 client responds with the user name string. 213 214 The data encoded in the second ready response contains the decimal 215 sequence number followed by a single space and the seed string for 216 the indicated user. The client responds with the one-time-password, 217 as either a 64-bit value in network byte order or encoded in the "six 218 English words" format. 219 220 Upon successful verification of the one-time-password, the server 221 should consider the client authenticated. 222 223 224 225 226 Myers [Page 4] 227 228 RFC 1731 IMAP4 Authentication Mechanisms December 1994 229 230 231 S/Key authentication does not provide for any protection mechanisms. 232 233 234 EXAMPLE: The following are two S/Key login scenarios. 235 236 S: * OK IMAP4 Server 237 C: A001 AUTHENTICATE SKEY 238 S: + 239 C: bW9yZ2Fu 240 S: + OTUgUWE1ODMwOA== 241 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 242 S: A001 OK S/Key authentication successful 243 244 245 S: * OK IMAP4 Server 246 C: A001 AUTHENTICATE SKEY 247 S: + 248 C: c21pdGg= 249 S: + OTUgUWE1ODMwOA== 250 C: BsAY3g4gBNo= 251 S: A001 NO S/Key authentication failed 252 253 254 5. References 255 256 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 257 RFC 1730, University of Washington, December 1994. 258 259 [RFC1508] Linn, J., "Generic Security Service Application Program 260 Interface", RFC 1508, Geer Zolot Associates, September 1993. 261 262 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", 263 Bellcore, Morristown, New Jersey, October 1993, 264 thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 Myers [Page 5] 283 284 RFC 1731 IMAP4 Authentication Mechanisms December 1994 285 286 287 6. Security Considerations 288 289 Security issues are discussed throughout this memo. 290 291 292 7. Author's Address 293 294 John G. Myers 295 Carnegie-Mellon University 296 5000 Forbes Ave. 297 Pittsburgh PA, 15213-3890 298 299 EMail: jgm+@cmu.edu 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 Myers [Page 6] 339