doc/specification/draft-siemborski-imap-sasl-initial-response-01.txt

   1
   2
   3 Network Working Group                                  Robert Siemborski
   4 INTERNET-DRAFT                                Carnegie Mellon University
   5 Intended Category: Standards Track                        November, 2003
   6
   7
   8             IMAP Extension for SASL Initial Client Response
   9           <draft-siemborski-imap-sasl-initial-response-01.txt>
  10
  11
  12 Status of this Memo
  13     This document is an Internet-Draft and is in full conformance with
  14     all provisions of Section 10 of RFC2026.
  15
  16     Internet-Drafts are working documents of the Internet Task Force
  17     (IETF), its areas, and its working groups.  Note that other groups
  18     may also distribute working documents as Internet-Drafts.
  19
  20     Internet-Drafts are draft documents valid for a maximum of six
  21     months and may be updated, replaced, or obsoleted by other documents
  22     at any time.  It is inappropriate to use Internet Drafts as
  23     reference material or to cite them other than as "work in progress."
  24
  25     The list of current Internet-Drafts can be accessed at
  26     http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28     The list of Internet-Draft Shadow Directories can be accessed at
  29     http://www.ietf.org/shadow.html.
  30
  31     Distribution of this memo is unlimited.
  32
  33 Abstract
  34
  35     To date, the Internet Message Access Protocol (IMAP) has used a
  36     Simple Authentication and Security Layer (SASL) profile which always
  37     required at least one complete round trip for an authentication, as
  38     it did not support an initial client response argument.  This
  39     additional round trip at the beginning of the session is
  40     undesirable, especially when round trip costs are high.
  41
  42     This document defines an extension to IMAP which allows clients and
  43     servers to avoid this round trip by allowing an initial client
  44     response argument to the IMAP AUTHENTICATE command.
  45
  46 1.  How to Read This Document
  47
  48     The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
  49     NOT", "RECOMMENDED", and "MAY" in this document are to be
  50     interpreted as defined in "Key words for use in RFCs to Indicate
  51
  52
  53
  54 Siemborski                 Expires April, 2004                  [Page 1]
  55
  56
  57
  58
  59
  60 IMAP Extension for SASL Initial Client Response           November, 2003
  61
  62
  63 Table of Contents
  64
  65
  66 1. How to Read This Document . . . . . . . . . . . . . . . . . . . .   1
  67 2. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  68 3. Changes to the IMAP AUTHENTICATE Command  . . . . . . . . . . . .   3
  69 4. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  70 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . .   5
  72 7. Intellectual Property Rights  . . . . . . . . . . . . . . . . . .   5
  73 8. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  74 9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  75 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . .   7
  76 11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .   7
  77 12. Changes since -01  . . . . . . . . . . . . . . . . . . . . . . .   8
  78 13. Changes since -00  . . . . . . . . . . . . . . . . . . . . . . .   8
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Siemborski                 Expires April, 2004                  [Page 2]
 115
 116
 117
 118
 119
 120 IMAP Extension for SASL Initial Client Response           November, 2003
 121
 122
 123     Requirement Levels" [KEYWORDS]
 124
 125     In examples, "C:" and "S:" indicate lines sent by the client and
 126     server respectively.
 127
 128     Formal syntax is defined using [ABNF] as modified by [IMAP4].
 129
 130 2.  Introduction
 131
 132     The [SASL] initial client response extension is present in any
 133     [IMAP4] server implementation which returns "SASL-IR" as one of the
 134     supported capabilities in its CAPABILITY response.
 135
 136     Servers which support this extension will accept an optional initial
 137     client response with the AUTHENTICATE command for any [SASL]
 138     mechanisms which support it.  Clients which support this extension
 139     SHOULD make use of the initial response whenever they attempt to
 140     authenticate using a SASL mechanism which supports it.
 141
 142 3.  IMAP Changes to the IMAP AUTHENTICATE Command
 143
 144     This extension adds an optional second argument to the AUTHENTICATE
 145     command that is defined in Section 6.2.2 of [IMAP4].  If this second
 146     argument is present, it represents the contents of the "initial
 147     client response" defined in section 5.1 of [SASL].
 148
 149     As with any other client response, this initial client response MUST
 150     be [BASE64] encoded.  It also MUST be transmitted outside of a
 151     quoted string or literal.  To send a zero-length initial response,
 152     the client MUST send a single pad character ("=").  This indicates
 153     that the response is present, but is a zero-length string.
 154
 155     When decoding the [BASE64] data in the initial client response,
 156     decoding errors MUST be treated as [IMAP4] would handle them in any
 157     normal SASL client response.  In particular, the server should check
 158     for any characters not explicitly allowed by the BASE64 alphabet, as
 159     well as any sequence of BASE64 characters that contains the pad
 160     character ('=') anywhere other than the end of the string (e.g.
 161     "=AAA" and "AAA=BBB" are not allowed).
 162
 163     Note: support and use of the initial client response is optional for
 164     both clients and servers.  Servers which implement this extension
 165     MUST support clients which omit the initial client response, and
 166     clients which implement this extension MUST NOT send an initial
 167     client response to servers which do not advertise the SASL-IR
 168     capability.  In such a situation, clients MUST fall back to an
 169     [IMAP4] compatible mode.
 170
 171
 172
 173
 174 Siemborski                 Expires April, 2004                  [Page 3]
 175
 176
 177
 178
 179
 180 IMAP Extension for SASL Initial Client Response           November, 2003
 181
 182
 183     If either the client or the server do not support the SASL-IR
 184     capability, a mechanism which uses an initial client response is
 185     negotiated using the challenge/response exchange described in
 186     [IMAP4], with an initial zero-length server challenge.
 187
 188
 189 4.  Examples
 190
 191     The following is an example authentication using the [PLAIN] SASL
 192     mechanism (under a [TLS] protection layer) and an initial client
 193     response:
 194
 195       ... client connects to server and negotiates a TLS protection layer ...
 196      C: C01 CAPABILITY
 197      S: * CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN
 198      S: C01 OK Completed
 199      C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
 200      S: A01 OK Success (tls protection)
 201
 202     Note that even when a server supports this extension, the following
 203     negotiation (which does not use the initial response) is still valid
 204     and MUST be supported by the server:
 205
 206       ... client connects to server and negotiates a TLS protection layer ...
 207      C: C01 CAPABILITY
 208      S: * CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN
 209      S: C01 OK Completed
 210      C: A01 AUTHENTICATE PLAIN
 211       (note that there is a space following the "+" in the following line)
 212      S: +
 213      C: dGVzdAB0ZXN0AHRlc3Q=
 214      S: A01 OK Success (tls protection)
 215
 216     The following is an example authentication using the EXTERNAL [SASL]
 217     mechanism (under a [TLS] protection layer) and an empty initial
 218     client response:
 219
 220       ... client connects to server and negotiates a TLS protection layer ...
 221      C: C01 CAPABILITY
 222      S: * CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
 223      S: C01 OK Completed
 224      C: A01 AUTHENTICATE EXTERNAL =
 225      S: A01 OK Success (tls protection)
 226
 227
 228
 229
 230
 231
 232
 233
 234 Siemborski                 Expires April, 2004                  [Page 4]
 235
 236
 237
 238
 239
 240 IMAP Extension for SASL Initial Client Response           November, 2003
 241
 242
 243     This is in contrast with the handling of such a situation when an
 244     initial response is omitted:
 245
 246       ... client connects to server and negotiates a TLS protection layer ...
 247      C: C01 CAPABILITY
 248      S: * CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
 249      S: C01 OK Completed
 250      C: A01 AUTHENTICATE EXTERNAL
 251       (note that there is a space following the "+" in the following line)
 252      S: +
 253      C:
 254      S: A01 OK Success (tls protection)
 255
 256
 257 5.  Formal Syntax
 258
 259     The following syntax specification uses the Augmented Bakus-Naur
 260     Form [ABNF] notation.  Non-terminals referenced but not defined
 261     below are as defined by [IMAP4].
 262
 263      capability    =/ "SASL-IR"
 264
 265      authenticate  = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
 266                      *(CRLF base64)
 267                        ;;redefine AUTHENTICATE command defined in [IMAP4]
 268
 269
 270 6.  Security Considerations
 271
 272     The extension defined in this document is subject to many of the
 273     Security Considerations defined in [IMAP4] and [SASL].
 274
 275     Server implementations MUST treat the omission of an initial client
 276     response from the AUTHENTICATE command as defined by [IMAP4] (as if
 277     this extension did not exist).
 278
 279     Although [IMAP4] has no express line length limitations, some
 280     implementations choose to enforce them anyway.  Such implementations
 281     MUST be aware that the addition of the initial response parameter to
 282     AUTHENTICATE may increase the maximum line length that IMAP parsers
 283     may expect to support.  Server implementations MUST be able to
 284     receive the largest possible initial client response that their
 285     supported mechanisms might receive.
 286
 287 7.  Intellectual Property Rights
 288
 289     The IETF takes no position regarding the validity or scope of any
 290     intellectual property or other rights that might be claimed to
 291
 292
 293
 294 Siemborski                 Expires April, 2004                  [Page 5]
 295
 296
 297
 298
 299
 300 IMAP Extension for SASL Initial Client Response           November, 2003
 301
 302
 303     pertain to the implementation or use of the technology described in
 304     this document or the extent to which any license under such rights
 305     might or might not be available; neither does it represent that it
 306     has made any effort to identify any such rights.  Information on the
 307     IETF's procedures with respect to rights in standards-track and
 308     standards-related documentation can be found in BCP-11.  Copies of
 309     claims of rights made available for publication and any assurances
 310     of licenses to be made available, or the result of an attempt made
 311     to obtain a general license or permission for the use of such
 312     proprietary rights by implementors or users of this specification
 313     can be obtained from the IETF Secretariat.
 314
 315     The IETF invites any interested party to bring to its attention any
 316     copyrights, patents or patent applications, or other proprietary
 317     rights which may cover technology that may be required to practice
 318     this standard.  Please address the information to the IETF Executive
 319     Director.
 320
 321 8.  Copyright
 322
 323     Copyright (C) The Internet Society (2003). All Rights Reserved.
 324
 325     This document and translations of it may be copied and furnished to
 326     others, and derivative works that comment on or otherwise explain it
 327     or assist in its implementation may be prepared, copied, published
 328     and distributed, in whole or in part, without restriction of any
 329     kind, provided that the above copyright notice and this paragraph
 330     are included on all such copies and derivative works.  However, this
 331     document itself may not be modified in any way, such as by removing
 332     the copyright notice or references to the Internet Society or other
 333     Internet organizations, except as needed for the  purpose of
 334     developing Internet standards in which case the procedures for
 335     copyrights defined in the Internet Standards process must be
 336     followed, or as required to translate it into languages other than
 337     English.
 338
 339     This document and the information contained herein is provided on an
 340     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 341     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 342     BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 343     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 344     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354 Siemborski                 Expires April, 2004                  [Page 6]
 355
 356
 357
 358
 359
 360 IMAP Extension for SASL Initial Client Response           November, 2003
 361
 362
 363 9.  References
 364
 365      The following documents contain normative definitions or
 366 specifications that are necessary for correct understanding of this
 367 protocol:
 368
 369 [ABNF]      Crocker, D., "Augmented BNF for Syntax Specifications:
 370             ABNF", RFC 2234, November, 1997.
 371
 372 [BASE64]    Josefsson, S., "The Base16, Base32, and Base64 Data
 373             Encodings", RFC 3548, July 2003.
 374
 375 [IMAP4]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
 376             4rev1", RFC 3501, March 2003.
 377
 378 [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
 379             Requirement Levels", BCP 14, RFC 2119, March 1997.
 380
 381 [SASL]      Melnikov, A., "Simple Authentication and Security Layer
 382             (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, a work in
 383             progress.
 384
 385 The following references are for informational purposes only:
 386
 387 [PLAIN]     Newman, C. "Using TLS with IMAP, POP3, and ACAP", RFC 2595,
 388             June 1999.
 389
 390 [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 391             2246, January 1999.
 392
 393 10.  Author's    Address:
 394
 395     Robert Siemborski
 396     Carnegie Mellon, Andrew Systems Group
 397     Cyert Hall 207
 398     5000 Forbes Avenue
 399     Pittsburgh, PA  15213
 400     +1 412 268 7456
 401     rjs3+@andrew.cmu.edu
 402
 403 11.  Acknowledgments:
 404
 405     The author would like to acknowledge the contributions of Ken
 406     Murchison and Mark Crispin, along with the rest of the IMAPEXT
 407     Working Group for their assistance in reviewing this document.
 408
 409     Alexey Melnikov and Cyrus Daboo also had some early discussions
 410     about this extension
 411
 412
 413
 414 Siemborski                 Expires April, 2004                  [Page 7]
 415
 416
 417
 418
 419
 420 IMAP Extension for SASL Initial Client Response           November, 2003
 421
 422
 423 12.  Changes since -01
 424
 425     (RFC Editor: Remove this section before publication)
 426
 427     - Add missing CAPABILITY OK responses in examples
 428
 429 13.  Changes since -00
 430
 431     (RFC Editor: Remove this section before publication)
 432
 433     - Change capability string to "SASL-IR"
 434
 435     - Fix a nit regarding an "=" in the initial response ABNF
 436
 437     - Clean up wording of BASE64 decoding requirements to be more in
 438     line with [IMAP4]
 439
 440     - Add examples of an empty initial client response, and move
 441     examples into their own section
 442
 443     - Update SASL reference to rfc2222bis
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474 Siemborski                 Expires April, 2004                  [Page 8]
 475