1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4959.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,395 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                      R. Siemborski
    1.11 +Request for Comments: 4959                                  Google, Inc.
    1.12 +Category: Standards Track                                 A. Gulbrandsen
    1.13 +                                                  Oryx Mail Systems GmbH
    1.14 +                                                          September 2007
    1.15 +
    1.16 +
    1.17 +   IMAP Extension for Simple Authentication and Security Layer (SASL)
    1.18 +                        Initial Client Response
    1.19 +
    1.20 +Status of This Memo
    1.21 +
    1.22 +   This document specifies an Internet standards track protocol for the
    1.23 +   Internet community, and requests discussion and suggestions for
    1.24 +   improvements.  Please refer to the current edition of the "Internet
    1.25 +   Official Protocol Standards" (STD 1) for the standardization state
    1.26 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.27 +
    1.28 +Abstract
    1.29 +
    1.30 +   To date, the Internet Message Access Protocol (IMAP) has used a
    1.31 +   Simple Authentication and Security Layer (SASL) profile which always
    1.32 +   required at least one complete round trip for an authentication, as
    1.33 +   it did not support an initial client response argument.  This
    1.34 +   additional round trip at the beginning of the session is undesirable,
    1.35 +   especially when round-trip costs are high.
    1.36 +
    1.37 +   This document defines an extension to IMAP which allows clients and
    1.38 +   servers to avoid this round trip by allowing an initial client
    1.39 +   response argument to the IMAP AUTHENTICATE command.
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Siemborski & Gulbrandsen  Standards Track                       [Page 1]
    1.62 +
    1.63 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
    1.64 +
    1.65 +
    1.66 +1.  Introduction
    1.67 +
    1.68 +   The SASL initial client response extension is present in any IMAP
    1.69 +   [RFC3501] server implementation which returns "SASL-IR" as one of the
    1.70 +   supported capabilities in its CAPABILITY response.
    1.71 +
    1.72 +   Servers which support this extension will accept an optional initial
    1.73 +   client response with the AUTHENTICATE command for any SASL [RFC4422]
    1.74 +   mechanisms which support it.
    1.75 +
    1.76 +2.  Conventions Used in This Document
    1.77 +
    1.78 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.79 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    1.80 +   document are to be interpreted as described in [RFC2119].
    1.81 +
    1.82 +   In examples, "C:" and "S:" indicate lines sent by the client and
    1.83 +   server, respectively.
    1.84 +
    1.85 +   Formal syntax is defined by [RFC4234] as extended by [RFC3501].
    1.86 +
    1.87 +3.  IMAP Changes to the IMAP AUTHENTICATE Command
    1.88 +
    1.89 +   This extension adds an optional second argument to the AUTHENTICATE
    1.90 +   command that is defined in Section 6.2.2 of [RFC3501].  If this
    1.91 +   second argument is present, it represents the contents of the
    1.92 +   "initial client response" defined in Section 5.1 of [RFC4422].
    1.93 +
    1.94 +   As with any other client response, this initial client response MUST
    1.95 +   be encoded as defined in Section 4 of [RFC4648].  It also MUST be
    1.96 +   transmitted outside of a quoted string or literal.  To send a zero-
    1.97 +   length initial response, the client MUST send a single pad character
    1.98 +   ("=").  This indicates that the response is present, but is a zero-
    1.99 +   length string.
   1.100 +
   1.101 +   When decoding the BASE64 [RFC4648] data in the initial client
   1.102 +   response, decoding errors MUST be treated as IMAP [RFC3501] would
   1.103 +   handle them in any normal SASL client response.  In particular, the
   1.104 +   server should check for any characters not explicitly allowed by the
   1.105 +   BASE64 alphabet, as well as any sequence of BASE64 characters that
   1.106 +   contains the pad character ('=') anywhere other than the end of the
   1.107 +   string (e.g., "=AAA" and "AAA=BBB" are not allowed).
   1.108 +
   1.109 +   If the client uses an initial response with a SASL mechanism that
   1.110 +   does not support an initial response, the server MUST reject the
   1.111 +   command with a tagged BAD response.
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Siemborski & Gulbrandsen  Standards Track                       [Page 2]
   1.118 +
   1.119 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
   1.120 +
   1.121 +
   1.122 +   Note: support and use of the initial client response is optional for
   1.123 +   both clients and servers.  Servers that implement this extension MUST
   1.124 +   support clients that omit the initial client response, and clients
   1.125 +   that implement this extension MUST NOT send an initial client
   1.126 +   response to servers that do not advertise the SASL-IR capability.  In
   1.127 +   such a situation, clients MUST fall back to an IMAP [RFC3501]
   1.128 +   compatible mode.
   1.129 +
   1.130 +   If either the client or the server do not support the SASL-IR
   1.131 +   capability, a mechanism which uses an initial client response is
   1.132 +   negotiated using the challenge/response exchange described in
   1.133 +   [RFC3501], with an initial zero-length server challenge.
   1.134 +
   1.135 +4.  Examples
   1.136 +
   1.137 +   The following is an example authentication using the PLAIN (see
   1.138 +   [RFC4616]) SASL mechanism (under a TLS protection layer, see
   1.139 +   [RFC4346]) and an initial client response:
   1.140 +
   1.141 +            ... client connects to server and negotiates a TLS
   1.142 +           protection layer ...
   1.143 +        C: C01 CAPABILITY
   1.144 +        S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
   1.145 +        S: C01 OK Completed
   1.146 +        C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
   1.147 +        S: A01 OK Success (tls protection)
   1.148 +
   1.149 +   Note that even when a server supports this extension, the following
   1.150 +   negotiation (which does not use the initial response) is still valid
   1.151 +   and MUST be supported by the server:
   1.152 +
   1.153 +            ... client connects to server and negotiates a TLS
   1.154 +           protection layer ...
   1.155 +        C: C01 CAPABILITY
   1.156 +        S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
   1.157 +        S: C01 OK Completed
   1.158 +        C: A01 AUTHENTICATE PLAIN
   1.159 +            (note that there is a space following the "+" in the
   1.160 +           following line)
   1.161 +        S: +
   1.162 +        C: dGVzdAB0ZXN0AHRlc3Q=
   1.163 +        S: A01 OK Success (tls protection)
   1.164 +
   1.165 +   The following is an example authentication using the SASL EXTERNAL
   1.166 +   mechanism (defined in [RFC4422]) under a TLS protection layer (see
   1.167 +   [RFC4346]) and an empty initial client response:
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Siemborski & Gulbrandsen  Standards Track                       [Page 3]
   1.174 +
   1.175 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
   1.176 +
   1.177 +
   1.178 +            ... client connects to server and negotiates a TLS
   1.179 +           protection layer ...
   1.180 +        C: C01 CAPABILITY
   1.181 +        S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
   1.182 +        S: C01 OK Completed
   1.183 +        C: A01 AUTHENTICATE EXTERNAL =
   1.184 +        S: A01 OK Success (tls protection)
   1.185 +
   1.186 +   This is in contrast with the handling of such a situation when an
   1.187 +   initial response is omitted:
   1.188 +
   1.189 +         ... client connects to server and negotiates a TLS protection
   1.190 +           layer ...
   1.191 +        C: C01 CAPABILITY
   1.192 +        S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
   1.193 +        S: C01 OK Completed
   1.194 +        C: A01 AUTHENTICATE EXTERNAL
   1.195 +            (note that there is a space following the "+" in the
   1.196 +           following line)
   1.197 +        S: +
   1.198 +        C:
   1.199 +        S: A01 OK Success (tls protection)
   1.200 +
   1.201 +5.  IANA Considerations
   1.202 +
   1.203 +   The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
   1.204 +
   1.205 +6.  Security Considerations
   1.206 +
   1.207 +   The extension defined in this document is subject to many of the
   1.208 +   Security Considerations defined in [RFC3501] and [RFC4422].
   1.209 +
   1.210 +   Server implementations MUST treat the omission of an initial client
   1.211 +   response from the AUTHENTICATE command as defined by [RFC3501] (as if
   1.212 +   this extension did not exist).
   1.213 +
   1.214 +   Although [RFC3501] has no express line length limitations, some
   1.215 +   implementations choose to enforce them anyway.  Such implementations
   1.216 +   MUST be aware that the addition of the initial response parameter to
   1.217 +   AUTHENTICATE may increase the maximum line length that IMAP parsers
   1.218 +   may expect to support.  Server implementations MUST be able to
   1.219 +   receive the largest possible initial client response that their
   1.220 +   supported mechanisms might receive.
   1.221 +
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Siemborski & Gulbrandsen  Standards Track                       [Page 4]
   1.230 +
   1.231 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
   1.232 +
   1.233 +
   1.234 +7.  Formal Syntax
   1.235 +
   1.236 +   The following syntax specification uses the Augmented Backus-Naur
   1.237 +   Form [RFC4234] notation.  [RFC3501] defines the non-terminals
   1.238 +   capability, auth-type, and base64.
   1.239 +
   1.240 +      capability    =/ "SASL-IR"
   1.241 +
   1.242 +      authenticate  = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
   1.243 +                      *(CRLF base64)
   1.244 +                      ;;redefine AUTHENTICATE from [RFC3501]
   1.245 +
   1.246 +8.  Acknowledgments
   1.247 +
   1.248 +   The authors would like to acknowledge the contributions of Ken
   1.249 +   Murchison and Mark Crispin, along with the rest of the IMAPEXT
   1.250 +   Working Group for their assistance in reviewing this document.
   1.251 +
   1.252 +   Alexey Melnikov and Cyrus Daboo also had some early discussions about
   1.253 +   this extension.
   1.254 +
   1.255 +9.  References
   1.256 +
   1.257 +9.1.  Normative References
   1.258 +
   1.259 +   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   1.260 +              Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.261 +
   1.262 +   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
   1.263 +              4rev1", RFC 3501, March 2003.
   1.264 +
   1.265 +   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
   1.266 +              Specifications: ABNF", RFC 4234, October 2005.
   1.267 +
   1.268 +   [RFC4422]  Melnikov, A. and  K. Zeilenga, "Simple Authentication and
   1.269 +              Security Layer (SASL)", RFC 4422, June 2006.
   1.270 +
   1.271 +   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
   1.272 +              Encodings", RFC 4648, October 2006.
   1.273 +
   1.274 +9.2.  Informative References
   1.275 +
   1.276 +   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
   1.277 +              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
   1.278 +
   1.279 +   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
   1.280 +              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Siemborski & Gulbrandsen  Standards Track                       [Page 5]
   1.286 +
   1.287 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
   1.288 +
   1.289 +
   1.290 +Authors' Addresses
   1.291 +
   1.292 +   Robert Siemborski
   1.293 +   Google, Inc.
   1.294 +   1600 Ampitheatre Parkway
   1.295 +   Mountain View, CA 94043
   1.296 +
   1.297 +   Phone: +1 650 623 6925
   1.298 +   EMail: robsiemb@google.com
   1.299 +
   1.300 +
   1.301 +   Arnt Gulbrandsen
   1.302 +   Oryx Mail Systems GmbH
   1.303 +   Schweppermannstr. 8
   1.304 +   D-81671 Muenchen
   1.305 +   Germany
   1.306 +
   1.307 +   EMail: arnt@oryx.com
   1.308 +
   1.309 +
   1.310 +
   1.311 +
   1.312 +
   1.313 +
   1.314 +
   1.315 +
   1.316 +
   1.317 +
   1.318 +
   1.319 +
   1.320 +
   1.321 +
   1.322 +
   1.323 +
   1.324 +
   1.325 +
   1.326 +
   1.327 +
   1.328 +
   1.329 +
   1.330 +
   1.331 +
   1.332 +
   1.333 +
   1.334 +
   1.335 +
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Siemborski & Gulbrandsen  Standards Track                       [Page 6]
   1.342 +
   1.343 +RFC 4959       IMAP Ext for SASL Initial Client Response  September 2007
   1.344 +
   1.345 +
   1.346 +Full Copyright Statement
   1.347 +
   1.348 +   Copyright (C) The IETF Trust (2007).
   1.349 +
   1.350 +   This document is subject to the rights, licenses and restrictions
   1.351 +   contained in BCP 78, and except as set forth therein, the authors
   1.352 +   retain all their rights.
   1.353 +
   1.354 +   This document and the information contained herein are provided on an
   1.355 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.356 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   1.357 +   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   1.358 +   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1.359 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.360 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.361 +
   1.362 +Intellectual Property
   1.363 +
   1.364 +   The IETF takes no position regarding the validity or scope of any
   1.365 +   Intellectual Property Rights or other rights that might be claimed to
   1.366 +   pertain to the implementation or use of the technology described in
   1.367 +   this document or the extent to which any license under such rights
   1.368 +   might or might not be available; nor does it represent that it has
   1.369 +   made any independent effort to identify any such rights.  Information
   1.370 +   on the procedures with respect to rights in RFC documents can be
   1.371 +   found in BCP 78 and BCP 79.
   1.372 +
   1.373 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.374 +   assurances of licenses to be made available, or the result of an
   1.375 +   attempt made to obtain a general license or permission for the use of
   1.376 +   such proprietary rights by implementers or users of this
   1.377 +   specification can be obtained from the IETF on-line IPR repository at
   1.378 +   http://www.ietf.org/ipr.
   1.379 +
   1.380 +   The IETF invites any interested party to bring to its attention any
   1.381 +   copyrights, patents or patent applications, or other proprietary
   1.382 +   rights that may cover technology that may be required to implement
   1.383 +   this standard.  Please address the information to the IETF at
   1.384 +   ietf-ipr@ietf.org.
   1.385 +
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Siemborski & Gulbrandsen  Standards Track                       [Page 7]
   1.398 +