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

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