doc/specification/draft-zeilenga-sasl-plain-00.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                           Editor: Kurt D. Zeilenga
   8 Intended Category: Standards Track            OpenLDAP Foundation
   9 Expires in six months                                23 June 2002
  10 Updates: RFC 2595
  11
  12
  13
  14                            Plain SASL Mechanism
  15                     <draft-zeilenga-sasl-plain-00.txt>
  16
  17
  18 Status of Memo
  19
  20   This document is an Internet-Draft and is in full conformance with all
  21   provisions of Section 10 of RFC2026.
  22
  23   This document is intended to be, after appropriate review and
  24   revision, submitted to the RFC Editor as a Standards Track document.
  25   Distribution of this memo is unlimited.  Technical discussion of this
  26   document will take place on the IETF SASL mailing list
  27   <ietf-sasl@imc.org>.  Please send editorial comments directly to the
  28   document editor <Kurt@OpenLDAP.org>.
  29
  30   Internet-Drafts are working documents of the Internet Engineering Task
  31   Force (IETF), its areas, and its working groups.  Note that other
  32   groups may also distribute working documents as Internet-Drafts.
  33   Internet-Drafts are draft documents valid for a maximum of six months
  34   and may be updated, replaced, or obsoleted by other documents at any
  35   time.  It is inappropriate to use Internet-Drafts as reference
  36   material or to cite them other than as ``work in progress.''
  37
  38   The list of current Internet-Drafts can be accessed at
  39   <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
  40   Internet-Draft Shadow Directories can be accessed at
  41   <http://www.ietf.org/shadow.html>.
  42
  43   Copyright 2002, The Internet Society.  All Rights Reserved.
  44
  45   Please see the Copyright section near the end of this document for
  46   more information.
  47
  48
  49 Abstract
  50
  51   Clear-text passwords are simple, interoperate with almost all existing
  52   operating system authentication databases, and are useful for a smooth
  53   transition to a more secure password-based authentication mechanism.
  54   The drawback is that they are unacceptable for use over an unencrypted
  55
  56
  57
  58 Zeilenga                  Plain SASL Mechanism                  [Page 1]
  59 \f
  60 INTERNET-DRAFT      draft-zeilenga-sasl-plain-00.txt        23 June 2002
  61
  62
  63   network connection.  This document defines the the SASL PLAIN
  64   authentication mechanism, intended to be used with confidentiality
  65   protection provided another layer (e.g. TLS).
  66
  67
  68 Conventions
  69
  70   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  71   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  72   document are to be interpreted as described in [KEYWORDS].
  73
  74
  75 1. Background and Intended Usage
  76
  77   Clear-text passwords are simple, interoperate with almost all existing
  78   operating system authentication databases, and are useful for a smooth
  79   transition to a more secure password-based authentication mechanism.
  80   The drawback is that they are unacceptable for use over an unencrypted
  81   network connection.
  82
  83   This document defines the "PLAIN" Simple Authentication and Security
  84   Layer ([SASL]) mechanism for use in protocols with no clear-text login
  85   command (e.g., ACAP).
  86
  87   The PLAIN SASL mechanism MUST NOT be used without adequate security
  88   protection as the mechanism affords no integrity nor confidentiality
  89   protection itself.  The PLAIN SASL mechanism MUST NOT be advertised
  90   unless a strong encryption layer (such as provided by [TLS]) is
  91   active.
  92
  93   This document updates RFC 2595, replacing Section 6.  Changes since
  94   RFC 2595 are detailed in Appendix A.
  95
  96
  97 2. PLAIN SASL mechanism
  98
  99   The mechanism consists of a single message from the client to the
 100   server.  The client sends the authorization identity (identity to
 101   login as), followed by a NUL character, followed by the authentication
 102   identity (identity whose password will be used), followed by a NUL
 103   character, followed by the clear-text password.   The client may leave
 104   the authorization identity empty if wishes the server to derive the
 105   authorization identity from the provided the authentication identity.
 106
 107   The authorization identity, authentication identity, password, and the
 108   NUL character SHALL be transferred as [UTF-8] encoded string of
 109   printable [Unicode] characters in Unicode Normalisation Form KC
 110   [NFKC].
 111
 112
 113
 114 Zeilenga                  Plain SASL Mechanism                  [Page 2]
 115 \f
 116 INTERNET-DRAFT      draft-zeilenga-sasl-plain-00.txt        23 June 2002
 117
 118
 119   The following characters are considered non-printable:
 120       - control characters: U+0000..U+001F, U+007F..U+009F;
 121       - replacement character: U+FFFD; and
 122       - special characters and noncharacter: U+FEFF, U+FFFE, U+FFFF.
 123
 124   The server will verify the authentication identity and password with
 125   the system authentication database and verify that the authentication
 126   credentials permit the client to login as the authorization identity.
 127   If both steps succeed, the user is logged in.
 128
 129   The server MAY also use the password to initialize any new
 130   authentication database, such as one suitable for [CRAM-MD5] or
 131   [DIGEST-MD5].
 132
 133       message         = [authorize-id] NUL authenticate-id NUL password
 134       authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 135       authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 136       password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 137       NUL             = %x00
 138       UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
 139                         UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
 140       UTF8-1          = %x80-BF
 141       UTF8-2          = %xC0-DF UTF8-1
 142       UTF8-3          = %xE0-EF 2UTF8-1
 143       UTF8-4          = %xF0-F7 3UTF8-1
 144       UTF8-5          = %xF8-FB 4UTF8-1
 145       UTF8-6          = %xFC-FD 5UTF8-1
 146
 147
 148 4. Example
 149
 150   Here is an example of how this might be used to initialize a CRAM-MD5
 151   authentication database for ACAP:
 152
 153       S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
 154       C: a001 AUTHENTICATE "CRAM-MD5"
 155       S: + "<1896.697170952@postoffice.reston.mci.net>"
 156       C: "tim b913a602c7eda7a495b4e6e7334d3890"
 157       S: a001 NO (TRANSITION-NEEDED)
 158          "Please change your password, or use TLS to login"
 159       C: a002 STARTTLS
 160       S: a002 OK "Begin TLS negotiation now"
 161       <TLS negotiation, further commands are under TLS layer>
 162       S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
 163       C: a003 AUTHENTICATE "PLAIN" {21+}
 164       C: <NUL>tim<NUL>tanstaaftanstaaf
 165       S: a003 OK CRAM-MD5 password initialized
 166
 167
 168
 169
 170 Zeilenga                  Plain SASL Mechanism                  [Page 3]
 171 \f
 172 INTERNET-DRAFT      draft-zeilenga-sasl-plain-00.txt        23 June 2002
 173
 174
 175   Note: In this example, <NUL> represents a single NUL (U+0000) octet.
 176
 177
 178 5. Security Considerations
 179
 180   The PLAIN mechanism relies on the TLS encryption layer for security.
 181   When used without TLS, it is vulnerable to a common network
 182   eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
 183   unless a suitable TLS encryption layer is active or backwards
 184   compatibility dictates otherwise.
 185
 186   When the PLAIN mechanism is used, the server gains the ability to
 187   impersonate the user to all services with the same password regardless
 188   of any encryption provided by TLS or other network privacy mechanisms.
 189   While many other authentication mechanisms have similar weaknesses,
 190   stronger SASL mechanisms such as the Kerberos-based GSSAPI mechanism
 191   address this issue.  Clients are encouraged to have an operational
 192   mode where all mechanisms which are likely to reveal the user's
 193   password to the server are disabled.
 194
 195   Clients are encouraged to have an operational mode where all
 196   mechanisms which are likely to reveal the user's password to the
 197   server are disabled.  It is RECOMMENDED that this mode be the default.
 198
 199   The security considerations for SASL apply to the PLAIN mechanism.
 200
 201
 202 6. IANA Considerations
 203
 204   It is requested that the SASL Mechanism registry [IANA-SASL] entry for
 205   the PLAIN mechanism be updated to reflect that this document now
 206   provides its technical specification.
 207
 208       To: iana@iana.org
 209       Subject: Updated Registration of SASL mechanism PLAIN
 210
 211       SASL mechanism name: PLAIN
 212       Security considerations: See RFC XXXX.
 213       Published specification (optional, recommended): RFC XXXX
 214       Person & email address to contact for further information:
 215            Kurt Zeilenga <kurt@openldap.org>
 216            Chris Neuman <chris.newman@innosoft.com>
 217       Intended usage: COMMON
 218       Author/Change controller: IESG <iesg@ietf.org>
 219       Note: Updates existing entry for PLAIN
 220
 221
 222 7. Acknowledgement
 223
 224
 225
 226 Zeilenga                  Plain SASL Mechanism                  [Page 4]
 227 \f
 228 INTERNET-DRAFT      draft-zeilenga-sasl-plain-00.txt        23 June 2002
 229
 230
 231   This document is a revision of RFC 2595 by Chris Newman.
 232
 233
 234 8. Normative References
 235
 236   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
 237               Specifications: ABNF", RFC 2234, November 1997.
 238
 239   [KEYWORDS]  S. Bradner, "Key words for use in RFCs to Indicate
 240               Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 241
 242   [NFKC]      Davis, M., M. Durst, "Unicode Standard Annex #15: Unicode
 243               Normalisation Forms", An integral part of The Unicode
 244               Standard, Version 3.2.0
 245               (http://www.unicode.org/reports/tr15/tr15-22.html).
 246
 247   [SASL]      Myers, J., "Simple Authentication and Security Layer
 248               (SASL)", RFC 2222bis (a work in progress).
 249
 250   [TLS]       T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC
 251               2246, January 1999.
 252
 253   [UNICODE]   The Unicode Consortium, "The Unicode Standard, Version
 254               3.2.0", defined by: The Unicode Standard, Version 3.0
 255               (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-61633-5),
 256               as amended by the Unicode Standard Annex #28: Unicode 3.2
 257               (http://www.unicode.org/reports/tr28/tr28-3.html).
 258
 259   [UTF-8]     Yergeau, F., "UTF-8, a transformation format of ISO
 260               10646", RFC 2279, January 1998.
 261
 262
 263 9. Informative References
 264
 265   [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
 266               MECHANISMS", http://www.iana.org/assignments/sasl-
 267               mechanisms.
 268
 269   [DIGEST-MD5]   P. Leach, C. Newman, "Using Digest Authentication as a
 270               SASL Mechanism", RFC 2831, May 2000.
 271
 272   [CRAM-MD5]     J. Klensin, R. Catoe, and P. Krumviede, "IMAP/POP
 273               AUTHorize Extension for Simple Challenge/Response", RFC
 274               2195, September 1997.
 275
 276
 277 10. Editor's Address
 278
 279
 280
 281
 282 Zeilenga                  Plain SASL Mechanism                  [Page 5]
 283 \f
 284 INTERNET-DRAFT      draft-zeilenga-sasl-plain-00.txt        23 June 2002
 285
 286
 287   Kurt Zeilenga
 288   OpenLDAP Foundation
 289
 290   Email: kurt@OpenLDAP.org
 291
 292
 293 Appendix A.  Changes since RFC 2595
 294
 295   Coming in next revision...
 296
 297
 298
 299 Full Copyright Statement
 300
 301   Copyright 2002, The Internet Society.  All Rights Reserved.
 302
 303   This document and translations of it may be copied and furnished to
 304   others, and derivative works that comment on or otherwise explain it
 305   or assist in its implementation may be prepared, copied, published and
 306   distributed, in whole or in part, without restriction of any kind,
 307   provided that the above copyright notice and this paragraph are
 308   included on all such copies and derivative works.  However, this
 309   document itself may not be modified in any way, such as by removing
 310   the copyright notice or references to the Internet Society or other
 311   Internet organizations, except as needed for the  purpose of
 312   developing Internet standards in which case the procedures for
 313   copyrights defined in the Internet Standards process must be followed,
 314   or as required to translate it into languages other than English.
 315
 316   The limited permissions granted above are perpetual and will not be
 317   revoked by the Internet Society or its successors or assigns.
 318
 319   This document and the information contained herein is provided on an
 320   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
 321   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
 322   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 323   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 324   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zeilenga                  Plain SASL Mechanism                  [Page 6]
 339 \f