1 ../imapserver/server.go:138
2
3
4
5
6
7Network Working Group R. Siemborski
8Request for Comments: 4959 Google, Inc.
9Category: Standards Track A. Gulbrandsen
10 Oryx Mail Systems GmbH
11 September 2007
12
13
14 IMAP Extension for Simple Authentication and Security Layer (SASL)
15 Initial Client Response
16
17Status of This Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25Abstract
26
27 To date, the Internet Message Access Protocol (IMAP) has used a
28 Simple Authentication and Security Layer (SASL) profile which always
29 required at least one complete round trip for an authentication, as
30 it did not support an initial client response argument. This
31 additional round trip at the beginning of the session is undesirable,
32 especially when round-trip costs are high.
33
34 This document defines an extension to IMAP which allows clients and
35 servers to avoid this round trip by allowing an initial client
36 response argument to the IMAP AUTHENTICATE command.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Siemborski & Gulbrandsen Standards Track [Page 1]
59
60RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
61
62
631. Introduction
64
65 The SASL initial client response extension is present in any IMAP
66 [RFC3501] server implementation which returns "SASL-IR" as one of the
67 supported capabilities in its CAPABILITY response.
68
69 Servers which support this extension will accept an optional initial
70 client response with the AUTHENTICATE command for any SASL [RFC4422]
71 mechanisms which support it.
72
732. Conventions Used in This Document
74
75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
77 document are to be interpreted as described in [RFC2119].
78
79 In examples, "C:" and "S:" indicate lines sent by the client and
80 server, respectively.
81
82 Formal syntax is defined by [RFC4234] as extended by [RFC3501].
83
843. IMAP Changes to the IMAP AUTHENTICATE Command 9051:1407 ../imapserver/server.go:1543
85
86 This extension adds an optional second argument to the AUTHENTICATE
87 command that is defined in Section 6.2.2 of [RFC3501]. If this
88 second argument is present, it represents the contents of the
89 "initial client response" defined in Section 5.1 of [RFC4422].
90
91 As with any other client response, this initial client response MUST
92 be encoded as defined in Section 4 of [RFC4648]. It also MUST be
93 transmitted outside of a quoted string or literal. To send a zero-
94 length initial response, the client MUST send a single pad character
95 ("="). This indicates that the response is present, but is a zero-
96 length string.
97
98 When decoding the BASE64 [RFC4648] data in the initial client
99 response, decoding errors MUST be treated as IMAP [RFC3501] would
100 handle them in any normal SASL client response. In particular, the
101 server should check for any characters not explicitly allowed by the
102 BASE64 alphabet, as well as any sequence of BASE64 characters that
103 contains the pad character ('=') anywhere other than the end of the
104 string (e.g., "=AAA" and "AAA=BBB" are not allowed).
105
106 If the client uses an initial response with a SASL mechanism that
107 does not support an initial response, the server MUST reject the
108 command with a tagged BAD response.
109
110
111
112
113
114Siemborski & Gulbrandsen Standards Track [Page 2]
115
116RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
117
118
119 Note: support and use of the initial client response is optional for
120 both clients and servers. Servers that implement this extension MUST
121 support clients that omit the initial client response, and clients
122 that implement this extension MUST NOT send an initial client
123 response to servers that do not advertise the SASL-IR capability. In
124 such a situation, clients MUST fall back to an IMAP [RFC3501]
125 compatible mode.
126
127 If either the client or the server do not support the SASL-IR
128 capability, a mechanism which uses an initial client response is
129 negotiated using the challenge/response exchange described in
130 [RFC3501], with an initial zero-length server challenge.
131
1324. Examples
133
134 The following is an example authentication using the PLAIN (see
135 [RFC4616]) SASL mechanism (under a TLS protection layer, see
136 [RFC4346]) and an initial client response:
137
138 ... client connects to server and negotiates a TLS
139 protection layer ...
140 C: C01 CAPABILITY
141 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
142 S: C01 OK Completed
143 C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
144 S: A01 OK Success (tls protection)
145
146 Note that even when a server supports this extension, the following
147 negotiation (which does not use the initial response) is still valid
148 and MUST be supported by the server:
149
150 ... client connects to server and negotiates a TLS
151 protection layer ...
152 C: C01 CAPABILITY
153 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
154 S: C01 OK Completed
155 C: A01 AUTHENTICATE PLAIN
156 (note that there is a space following the "+" in the
157 following line)
158 S: +
159 C: dGVzdAB0ZXN0AHRlc3Q=
160 S: A01 OK Success (tls protection)
161
162 The following is an example authentication using the SASL EXTERNAL
163 mechanism (defined in [RFC4422]) under a TLS protection layer (see
164 [RFC4346]) and an empty initial client response:
165
166
167
168
169
170Siemborski & Gulbrandsen Standards Track [Page 3]
171
172RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
173
174
175 ... client connects to server and negotiates a TLS
176 protection layer ...
177 C: C01 CAPABILITY
178 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
179 S: C01 OK Completed
180 C: A01 AUTHENTICATE EXTERNAL =
181 S: A01 OK Success (tls protection)
182
183 This is in contrast with the handling of such a situation when an
184 initial response is omitted:
185
186 ... client connects to server and negotiates a TLS protection
187 layer ...
188 C: C01 CAPABILITY
189 S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
190 S: C01 OK Completed
191 C: A01 AUTHENTICATE EXTERNAL
192 (note that there is a space following the "+" in the
193 following line)
194 S: +
195 C:
196 S: A01 OK Success (tls protection)
197
1985. IANA Considerations
199
200 The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
201
2026. Security Considerations
203
204 The extension defined in this document is subject to many of the
205 Security Considerations defined in [RFC3501] and [RFC4422].
206
207 Server implementations MUST treat the omission of an initial client
208 response from the AUTHENTICATE command as defined by [RFC3501] (as if
209 this extension did not exist).
210
211 Although [RFC3501] has no express line length limitations, some
212 implementations choose to enforce them anyway. Such implementations
213 MUST be aware that the addition of the initial response parameter to
214 AUTHENTICATE may increase the maximum line length that IMAP parsers
215 may expect to support. Server implementations MUST be able to
216 receive the largest possible initial client response that their
217 supported mechanisms might receive.
218
219
220
221
222
223
224
225
226Siemborski & Gulbrandsen Standards Track [Page 4]
227
228RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
229
230
2317. Formal Syntax
232
233 The following syntax specification uses the Augmented Backus-Naur
234 Form [RFC4234] notation. [RFC3501] defines the non-terminals
235 capability, auth-type, and base64.
236
237 capability =/ "SASL-IR"
238
239 authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
240 *(CRLF base64)
241 ;;redefine AUTHENTICATE from [RFC3501]
242
2438. Acknowledgments
244
245 The authors would like to acknowledge the contributions of Ken
246 Murchison and Mark Crispin, along with the rest of the IMAPEXT
247 Working Group for their assistance in reviewing this document.
248
249 Alexey Melnikov and Cyrus Daboo also had some early discussions about
250 this extension.
251
2529. References
253
2549.1. Normative References
255
256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
257 Requirement Levels", BCP 14, RFC 2119, March 1997.
258
259 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
260 4rev1", RFC 3501, March 2003.
261
262 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
263 Specifications: ABNF", RFC 4234, October 2005.
264
265 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
266 Security Layer (SASL)", RFC 4422, June 2006.
267
268 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
269 Encodings", RFC 4648, October 2006.
270
2719.2. Informative References
272
273 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
274 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
275
276 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
277 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
278
279
280
281
282Siemborski & Gulbrandsen Standards Track [Page 5]
283
284RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
285
286
287Authors' Addresses
288
289 Robert Siemborski
290 Google, Inc.
291 1600 Ampitheatre Parkway
292 Mountain View, CA 94043
293
294 Phone: +1 650 623 6925
295 EMail: robsiemb@google.com
296
297
298 Arnt Gulbrandsen
299 Oryx Mail Systems GmbH
300 Schweppermannstr. 8
301 D-81671 Muenchen
302 Germany
303
304 EMail: arnt@oryx.com
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
338Siemborski & Gulbrandsen Standards Track [Page 6]
339
340RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
341
342
343Full Copyright Statement
344
345 Copyright (C) The IETF Trust (2007).
346
347 This document is subject to the rights, licenses and restrictions
348 contained in BCP 78, and except as set forth therein, the authors
349 retain all their rights.
350
351 This document and the information contained herein are provided on an
352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
358
359Intellectual Property
360
361 The IETF takes no position regarding the validity or scope of any
362 Intellectual Property Rights or other rights that might be claimed to
363 pertain to the implementation or use of the technology described in
364 this document or the extent to which any license under such rights
365 might or might not be available; nor does it represent that it has
366 made any independent effort to identify any such rights. Information
367 on the procedures with respect to rights in RFC documents can be
368 found in BCP 78 and BCP 79.
369
370 Copies of IPR disclosures made to the IETF Secretariat and any
371 assurances of licenses to be made available, or the result of an
372 attempt made to obtain a general license or permission for the use of
373 such proprietary rights by implementers or users of this
374 specification can be obtained from the IETF on-line IPR repository at
375 http://www.ietf.org/ipr.
376
377 The IETF invites any interested party to bring to its attention any
378 copyrights, patents or patent applications, or other proprietary
379 rights that may cover technology that may be required to implement
380 this standard. Please address the information to the IETF at
381 ietf-ipr@ietf.org.
382
383
384
385
386
387
388
389
390
391
392
393
394Siemborski & Gulbrandsen Standards Track [Page 7]
395
396