imapext-2007
view docs/rfc/rfc4959.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 R. Siemborski
8 Request for Comments: 4959 Google, Inc.
9 Category: Standards Track A. Gulbrandsen
10 Oryx Mail Systems GmbH
11 September 2007
14 IMAP Extension for Simple Authentication and Security Layer (SASL)
15 Initial Client Response
17 Status of This Memo
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.
25 Abstract
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.
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.
58 Siemborski & Gulbrandsen Standards Track [Page 1]
60 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
63 1. Introduction
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.
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.
73 2. Conventions Used in This Document
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].
79 In examples, "C:" and "S:" indicate lines sent by the client and
80 server, respectively.
82 Formal syntax is defined by [RFC4234] as extended by [RFC3501].
84 3. IMAP Changes to the IMAP AUTHENTICATE Command
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].
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.
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).
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.
114 Siemborski & Gulbrandsen Standards Track [Page 2]
116 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
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.
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.
132 4. Examples
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:
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)
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:
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)
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:
170 Siemborski & Gulbrandsen Standards Track [Page 3]
172 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
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)
183 This is in contrast with the handling of such a situation when an
184 initial response is omitted:
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)
198 5. IANA Considerations
200 The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
202 6. Security Considerations
204 The extension defined in this document is subject to many of the
205 Security Considerations defined in [RFC3501] and [RFC4422].
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).
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.
226 Siemborski & Gulbrandsen Standards Track [Page 4]
228 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
231 7. Formal Syntax
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.
237 capability =/ "SASL-IR"
239 authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
240 *(CRLF base64)
241 ;;redefine AUTHENTICATE from [RFC3501]
243 8. Acknowledgments
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.
249 Alexey Melnikov and Cyrus Daboo also had some early discussions about
250 this extension.
252 9. References
254 9.1. Normative References
256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
257 Requirement Levels", BCP 14, RFC 2119, March 1997.
259 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
260 4rev1", RFC 3501, March 2003.
262 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
263 Specifications: ABNF", RFC 4234, October 2005.
265 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
266 Security Layer (SASL)", RFC 4422, June 2006.
268 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
269 Encodings", RFC 4648, October 2006.
271 9.2. Informative References
273 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
274 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
276 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
277 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
282 Siemborski & Gulbrandsen Standards Track [Page 5]
284 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
287 Authors' Addresses
289 Robert Siemborski
290 Google, Inc.
291 1600 Ampitheatre Parkway
292 Mountain View, CA 94043
294 Phone: +1 650 623 6925
295 EMail: robsiemb@google.com
298 Arnt Gulbrandsen
299 Oryx Mail Systems GmbH
300 Schweppermannstr. 8
301 D-81671 Muenchen
302 Germany
304 EMail: arnt@oryx.com
338 Siemborski & Gulbrandsen Standards Track [Page 6]
340 RFC 4959 IMAP Ext for SASL Initial Client Response September 2007
343 Full Copyright Statement
345 Copyright (C) The IETF Trust (2007).
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.
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.
359 Intellectual Property
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.
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.
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.
394 Siemborski & Gulbrandsen Standards Track [Page 7]