5 INTERNET-DRAFT Editor: Kurt D. Zeilenga
6 Intended Category: Standards Track OpenLDAP Foundation
7 Expires August 2005 21 February 2005
12 The Plain SASL Mechanism
13 <draft-ietf-sasl-plain-07.txt>
19 This document is intended to be, after appropriate review and
20 revision, submitted to the RFC Editor as a Standards Track document.
21 Distribution of this memo is unlimited. Technical discussion of this
22 document will take place on the IETF SASL mailing list
23 <ietf-sasl@imc.org>. Please send editorial comments directly to the
24 document editor <Kurt@OpenLDAP.org>.
26 By submitting this Internet-Draft, I accept the provisions of Section
27 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
28 applicable patent or other IPR claims of which I am aware have been
29 disclosed, or will be disclosed, and any of which I become aware will
30 be disclosed, in accordance with RFC 3668.
32 Internet-Drafts are working documents of the Internet Engineering Task
33 Force (IETF), its areas, and its working groups. Note that other
34 groups may also distribute working documents as Internet-Drafts.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference material
39 or to cite them other than as "work in progress."
41 The list of current Internet-Drafts can be accessed at
42 http://www.ietf.org/1id-abstracts.html
44 The list of Internet-Draft Shadow Directories can be accessed at
45 http://www.ietf.org/shadow.html
48 Copyright (C) The Internet Society (2005). All Rights Reserved.
50 Please see the Full Copyright section near the end of this document
56 Zeilenga Plain SASL Mechanism [Page 1]
58 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
63 This document defines a simple clear-text user/password Simple
64 Authentication and Security Layer (SASL) mechanism called the PLAIN
65 mechanism. The PLAIN mechanism is intended to be used, in combination
66 with data confidentiality services provided by a lower layer, in
67 protocols which lack a simple password authentication command.
72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
74 document are to be interpreted as described in [Keywords].
77 1. Background and Intended Usage
79 Clear-text passwords are simple, interoperate with almost all existing
80 operating system authentication databases, and are useful for a smooth
81 transition to a more secure password-based authentication mechanism.
82 The drawback is that they are unacceptable for use over an unencrypted
85 This document defines the PLAIN Simple Authentication and Security
86 Layer ([SASL]) mechanism for use in protocols with no clear-text login
87 command (e.g., [ACAP] or [SMTP-AUTH]).
89 The name associated with this mechanism is "PLAIN".
91 The PLAIN SASL mechanism does not provide a security layer.
93 The PLAIN mechanism should not be used without adequate data security
94 protection as this mechanism affords no integrity nor confidentiality
95 protections itself. The mechanism is intended to be used with data
96 security protections provided by application layer protocol, generally
97 through its use of Transport Layer Security ([TLS]) services.
99 By default, implementations SHOULD advertise and make use of the PLAIN
100 mechanism only when adequate data security services are in place.
101 Specifications for IETF protocols which indicate that the this
102 mechanism is an applicable authentication mechanism MUST mandate that
103 implementations support an strong data security service, such as TLS.
105 This document updates RFC 2595, replacing Section 6. Changes since
106 RFC 2595 are detailed in Appendix A.
112 Zeilenga Plain SASL Mechanism [Page 2]
114 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
117 2. PLAIN SASL mechanism
119 The mechanism consists of a single message, a string of [UTF-8]
120 encoded [Unicode] characters, from the client to the server. The
121 client presents the authorization identity (identity to act as),
122 followed by a NULL (U+0000) character, followed by the authentication
123 identity (identity whose password will be used), followed by a NULL
124 (U+0000) character, followed by the clear-text password. As with
125 other SASL mechanisms, the client leaves the authorization identity
126 empty when it wishes the server to derive an identity from the
127 credentials and use that as the authorization identity.
129 The formal grammar for the client message using Augmented BNF [ABNF]
132 message = [authzid] UTF8NULL authcid UTF8NULL passwd
133 authcid = 1*SAFE ; MUST accept up to 255 octets
134 authzid = 1*SAFE ; MUST accept up to 255 octets
135 passwd = 1*SAFE ; MUST accept up to 255 octets
136 UTF8NULL = %x00 ; UTF-8 encoded NULL character
138 SAFE = UTF1 / UTF2 / UTF3 / UTF4
139 ;; any UTF-8 encoded Unicode character except NULL
141 UTF1 = %x01-7F ;; except NULL
143 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
144 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
145 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
149 The authorization identity (authzid), authentication identity
150 (authcid), password (passwd), and NULL character deliminators SHALL be
151 transferred as [UTF-8] encoded strings of [Unicode] characters. As
152 the NULL (U+0000) character is used as a deliminator, the NULL
153 (U+0000) character MUST NOT appear in authzid, authcid, or passwd
156 The form of the authzid production is specific to the
157 application-level protocol's SASL profile [SASL]. The authcid and
158 passwd productions are form-free. Use of non-visible characters or
159 characters which a user may be unable to enter on some keyboards is
162 Servers MUST be capable of accepting authzid, authcid, and passwd
163 productions up to and including 255 octets. It is noted that the
164 UTF-8 encoding of a Unicode character may be as long as 4 octets.
168 Zeilenga Plain SASL Mechanism [Page 3]
170 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
173 Upon receipt of the message, the server will verify the presented (in
174 the message) authentication identity (authcid) and password (passwd)
175 with the system authentication database, and verify the authentication
176 credentials permit the client to act as the (presented or derived)
177 authorization identity. If both steps succeed, the user is
180 In this verification process, the presented authentication identity
181 and password strings, as well as the database authentication identity
182 and password strings, are to be prepared before being used in any
183 comparison. The server SHOULD prepare each string using the
184 [SASLPrep] profile of the [StringPrep] algorithm. The SASLprep
185 preparation is recommended to improve the likelihood that comparisons
186 behave in an expected manner. It is not mandatory to allow the server
187 to employ other preparation algorithms (including none) as necessary
188 to interoperate with external systems.
190 When preparing the presented strings using [SASLPrep], the presented
191 strings are to be treated as "query" strings [Section 7, Stringprep]
192 and hence unassigned code points are allowed appear in their prepared
193 output. When preparing the database strings using [SASLprep], the
194 database strings are to be treated as "stored" strings [Section 7,
195 Stringprep] and hence unassigned code points are prohibited from
196 appearing in their prepared output.
198 Regardless of the preparation algorithm used, if the output of a non-
199 invertible function (e.g., hash) of the expected string is stored, the
200 string MUST be prepared before input to that function.
202 Regardless of the preparation algorithm used, if preparation fails or
203 results in an empty string, verification SHALL fail.
205 When an empty authorization identity is provided, the server SHALL
206 derive the authorization identity from the prepared representation of
207 the provided authentication identity string. This ensures that the
208 derivation of different representations of the authentication identity
209 produce the same authorization identity.
211 The server MAY use the credentials to initialize any new
212 authentication database, such as one suitable for [CRAM-MD5] or
218 The verification function (using hashed password) can be written (in
224 Zeilenga Plain SASL Mechanism [Page 4]
226 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
229 boolean Verify(string authzid, string authcid, string passwd) {
230 string pAuthcid = SASLprep(authcid, true); # prepare authcid
231 string pPasswd = SASLprep(passwd, true); # prepare passwd
232 if (pAuthcid == NULL || pPasswd == NULL) {
233 return false; # preparation failed
235 if (pAuthcid == "" || pPasswd == "") {
236 return false; # empty prepared string
239 storedHash = FetchPasswordHash(pAuthcid);
240 if (storedHash == NULL || storedHash == "") {
241 return false; # error or unknown authcid
244 if (!Compare(storedHash, Hash(pPasswd))) {
245 return false; # incorrect password
248 if (authzid == NULL) {
249 authzid = DeriveAuthzid(pAuthcid);
250 if (authzid == NULL || authzid == "") {
251 return false; # could not derive authzid
255 if (!Authorize(pAuthcid, authzid)) {
256 return false; # not authorized
262 The second parameter of the SASLprep function, when true, indicates
263 that unassigned code points are allowed in the input. When the
264 SASLprep function is called to prepared the password prior to
265 computing the stored hash, the second parameter would be false.
267 The second parameter provided to the Authorize function is not
268 prepared by this code. The application-level SASL profile should be
269 consulted to determine what, if any, preparation is necessary.
274 This section provides examples of PLAIN authentication exchanges. The
275 examples are intended to help the readers understand the above text.
276 The examples are not definitive.
280 Zeilenga Plain SASL Mechanism [Page 5]
282 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
285 "C:" and "S:" indicate lines sent by the client and server
286 respectively. "<NULL>" represents a single NULL (U+0000) character.
287 The Application Configuration Access Protocol ([ACAP]) is used in the
290 The first example shows how the PLAIN mechanism might be used for user
293 S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
295 S: a001 OK "Begin TLS negotiation now"
296 <TLS negotiation, further commands are under TLS layer>
297 S: * ACAP (SASL "CRAM-MD5" "PLAIN")
298 C: a002 AUTHENTICATE "PLAIN"
301 C: <NULL>tim<NULL>tanstaaftanstaaf
302 S: a002 OK "Authenticated"
304 The second example shows how the PLAIN mechanism might be used to
305 assume the identity of another user. In this example, the server
306 rejects the request. Also, this example makes use of the protocol
307 optional initial response capability to eliminate a round-trip.
309 S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
311 S: a001 OK "Begin TLS negotiation now"
312 <TLS negotiation, further commands are under TLS layer>
313 S: * ACAP (SASL "CRAM-MD5" "PLAIN")
314 C: a002 AUTHENTICATE "PLAIN" {20+}
315 C: Ursel<NULL>Kurt<NULL>xipj3plmq
316 S: a002 NO "Not authorized to assume asserted identity"
319 6. Security Considerations
321 As the PLAIN mechanism itself provided no integrity nor
322 confidentiality protections, it should not be used without adequate
323 external data security protection, such as TLS services provided by
324 many application layer protocols. By default, implementations SHOULD
325 NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
326 adequate data security services are in place.
328 When the PLAIN mechanism is used, the server gains the ability to
329 impersonate the user to all services with the same password regardless
330 of any encryption provided by TLS or other network privacy mechanisms.
331 While many other authentication mechanisms have similar weaknesses,
332 stronger SASL mechanisms address this issue. Clients are encouraged
336 Zeilenga Plain SASL Mechanism [Page 6]
338 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
341 to have an operational mode where all mechanisms which are likely to
342 reveal the user's password to the server are disabled.
344 General SASL security considerations apply to this mechanism.
345 "stringprep" and Unicode [StringPrep] security considerations also
346 apply, as do [UTF-8] security considerations.
349 7. IANA Considerations
351 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
352 the PLAIN mechanism be updated to reflect that this document now
353 provides its technical specification.
356 Subject: Updated Registration of SASL mechanism PLAIN
358 SASL mechanism name: PLAIN
359 Security considerations: See RFC XXXX.
360 Published specification (optional, recommended): RFC XXXX
361 Person & email address to contact for further information:
362 Kurt Zeilenga <kurt@openldap.org>
363 IETF SASL WG <ietf-sasl@imc.org>
364 Intended usage: COMMON
365 Author/Change controller: IESG <iesg@ietf.org>
366 Note: Updates existing entry for PLAIN
371 This document is a revision of RFC 2595 by Chris Newman. Portions of
372 the grammar defined in Section 2 were borrowed from [UTF-8] by
375 This document is a product of the IETF SASL WG.
378 9. Normative References
380 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
381 Specifications: ABNF", RFC 2234, November 1997.
383 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate
384 Requirement Levels", BCP 14, RFC 2119, March 1997
386 [SASL] Melnikov, A. (Editor), "Simple Authentication and
387 Security Layer (SASL)",
388 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
392 Zeilenga Plain SASL Mechanism [Page 7]
394 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
397 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user
398 names and passwords", draft-ietf-sasl-saslprep-xx.txt, a
401 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
402 Internationalized Strings ('stringprep')", RFC 3454,
405 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
406 3.2.0" is defined by "The Unicode Standard, Version 3.0"
407 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
408 as amended by the "Unicode Standard Annex #27: Unicode
409 3.1" (http://www.unicode.org/reports/tr27/) and by the
410 "Unicode Standard Annex #28: Unicode 3.2"
411 (http://www.unicode.org/reports/tr28/).
413 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
414 10646", RFC 3629 (also STD 63), November 2003.
416 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
417 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
421 10. Informative References
423 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
424 Configuration Access Protocol", RFC 2244, November 1997.
425 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
426 draft-ietf-sasl-crammd5-xx.txt, a work in progress.
428 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
429 Authentication as a SASL Mechanism",
430 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
432 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
434 <http://www.iana.org/assignments/sasl-mechanisms>.
436 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
437 RFC 2554, March 1999.
448 Zeilenga Plain SASL Mechanism [Page 8]
450 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
453 Email: Kurt@OpenLDAP.org
456 Appendix A. Changes since RFC 2595
458 This appendix is non-normative.
460 This document replaces Section 6 of RFC 2595.
462 The specification details how the server is to compare client-provided
463 character strings with stored character strings.
465 The ABNF grammar was updated. In particular, the grammar now allows
466 LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
467 authzid, authcid, passwd productions. However, whether these control
468 characters may be used depends on the string preparation rules
469 applicable to the production. For passwd and authcid productions,
470 control characters are prohibited. For authzid, one must consult the
471 application-level SASL profile.
473 Pseudo-code was added.
475 The example section was expanded to illustrate more features of the
480 Intellectual Property Rights
482 The IETF takes no position regarding the validity or scope of any
483 Intellectual Property Rights or other rights that might be claimed to
484 pertain to the implementation or use of the technology described in
485 this document or the extent to which any license under such rights
486 might or might not be available; nor does it represent that it has
487 made any independent effort to identify any such rights. Information
488 on the procedures with respect to rights in RFC documents can be found
489 in BCP 78 and BCP 79.
491 Copies of IPR disclosures made to the IETF Secretariat and any
492 assurances of licenses to be made available, or the result of an
493 attempt made to obtain a general license or permission for the use of
494 such proprietary rights by implementers or users of this specification
495 can be obtained from the IETF on-line IPR repository at
496 http://www.ietf.org/ipr.
498 The IETF invites any interested party to bring to its attention any
499 copyrights, patents or patent applications, or other proprietary
500 rights that may cover technology that may be required to implement
504 Zeilenga Plain SASL Mechanism [Page 9]
506 INTERNET-DRAFT draft-ietf-sasl-plain-07.txt 21 February 2005
509 this standard. Please address the information to the IETF at
516 Copyright (C) The Internet Society (2005). This document is subject
517 to the rights, licenses and restrictions contained in BCP 78, and
518 except as set forth therein, the authors retain all their rights.
520 This document and the information contained herein are provided on an
521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
523 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
524 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
525 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
560 Zeilenga Plain SASL Mechanism [Page 10]