6 INTERNET-DRAFT Editor: Kurt D. Zeilenga
7 Intended Category: Standards Track OpenLDAP Foundation
8 Expires September 2005 18 March 2005
13 The PLAIN SASL Mechanism
14 <draft-ietf-sasl-plain-08.txt>
20 This document is intended to be, after appropriate review and
21 revision, submitted to the RFC Editor as a Standards Track document.
22 Distribution of this memo is unlimited. Technical discussion of this
23 document will take place on the IETF SASL mailing list
24 <ietf-sasl@imc.org>. Please send editorial comments directly to the
25 document editor <Kurt@OpenLDAP.org>.
27 By submitting this Internet-Draft, I accept the provisions of Section
28 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
29 applicable patent or other IPR claims of which I am aware have been
30 disclosed, or will be disclosed, and any of which I become aware will
31 be disclosed, in accordance with RFC 3668.
33 Internet-Drafts are working documents of the Internet Engineering Task
34 Force (IETF), its areas, and its working groups. Note that other
35 groups may also distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference material
40 or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/1id-abstracts.html
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
49 Copyright (C) The Internet Society (2005). All Rights Reserved.
51 Please see the Full Copyright section near the end of this document
57 Zeilenga The SASL PLAIN Mechanism [Page 1]
59 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
64 This document defines a simple clear-text user/password Simple
65 Authentication and Security Layer (SASL) mechanism called the PLAIN
66 mechanism. The PLAIN mechanism is intended to be used, in combination
67 with data confidentiality services provided by a lower layer, in
68 protocols which lack a simple password authentication command.
71 1. Background and Intended Usage
73 Clear-text passwords are simple, interoperate with almost all existing
74 operating system authentication databases, and are useful for a smooth
75 transition to a more secure password-based authentication mechanism.
76 The drawback is that they are unacceptable for use over an unencrypted
79 This document defines the PLAIN Simple Authentication and Security
80 Layer ([SASL]) mechanism for use in protocols with no clear-text login
81 command (e.g., [ACAP] or [SMTP-AUTH]). This document updates RFC
82 2595, replacing Section 6. Changes since RFC 2595 are detailed in
85 The name associated with this mechanism is "PLAIN".
87 The PLAIN SASL mechanism does not provide a security layer.
89 The PLAIN mechanism should not be used without adequate data security
90 protection as this mechanism affords no integrity nor confidentiality
91 protections itself. The mechanism is intended to be used with data
92 security protections provided by application layer protocol, generally
93 through its use of Transport Layer Security ([TLS]) services.
95 By default, implementations SHOULD advertise and make use of the PLAIN
96 mechanism only when adequate data security services are in place.
97 Specifications for IETF protocols which indicate that this mechanism
98 is an applicable authentication mechanism MUST mandate that
99 implementations support an strong data security service, such as TLS.
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 document are to be interpreted as described in [Keywords].
113 Zeilenga The SASL PLAIN Mechanism [Page 2]
115 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
118 2. PLAIN SASL mechanism
120 The mechanism consists of a single message, a string of [UTF-8]
121 encoded [Unicode] characters, from the client to the server. The
122 client presents the authorization identity (identity to act as),
123 followed by a NULL (U+0000) character, followed by the authentication
124 identity (identity whose password will be used), followed by a NULL
125 (U+0000) character, followed by the clear-text password. As with
126 other SASL mechanisms, the client does not provide an authorization
127 identity when it wishes the server to derive an identity from the
128 credentials and use that as the authorization identity.
130 The formal grammar for the client message using Augmented BNF [ABNF]
133 message = [authzid] UTF8NULL authcid UTF8NULL passwd
134 authcid = 1*SAFE ; MUST accept up to 255 octets
135 authzid = 1*SAFE ; MUST accept up to 255 octets
136 passwd = 1*SAFE ; MUST accept up to 255 octets
137 UTF8NULL = %x00 ; UTF-8 encoded NULL character
139 SAFE = UTF1 / UTF2 / UTF3 / UTF4
140 ;; any UTF-8 encoded Unicode character except NULL
142 UTF1 = %x01-7F ;; except NULL
144 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
145 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
146 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
150 The authorization identity (authzid), authentication identity
151 (authcid), password (passwd), and NULL character deliminators SHALL be
152 transferred as [UTF-8] encoded strings of [Unicode] characters. As
153 the NULL (U+0000) character is used as a deliminator, the NULL
154 (U+0000) character MUST NOT appear in authzid, authcid, or passwd
157 The form of the authzid production is specific to the
158 application-level protocol's SASL profile [SASL]. The authcid and
159 passwd productions are form-free. Use of non-visible characters or
160 characters which a user may be unable to enter on some keyboards is
163 Servers MUST be capable of accepting authzid, authcid, and passwd
164 productions up to and including 255 octets. It is noted that the
165 UTF-8 encoding of a Unicode character may be as long as 4 octets.
169 Zeilenga The SASL PLAIN Mechanism [Page 3]
171 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
174 Upon receipt of the message, the server will verify the presented (in
175 the message) authentication identity (authcid) and password (passwd)
176 with the system authentication database, and verify the authentication
177 credentials permit the client to act as the (presented or derived)
178 authorization identity. If both steps succeed, the user is
181 The presented authentication identity and password strings, as well as
182 the database authentication identity and password strings, are to be
183 prepared before being used in the verification process. The
184 [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
185 preparation algorithm. The SASLprep preparation algorithm is
186 recommended to improve the likelihood that comparisons behave in an
187 expected manner. The SASLprep preparation algorithm is not mandatory
188 to allow, when appropriate, the server to employ other preparation
189 algorithms (including none). For instance, use of different
190 preparation algorithm may be necessary for the server to interoperate
191 with an external system.
193 When preparing the presented strings using [SASLPrep], the presented
194 strings are to be treated as "query" strings [Section 7, Stringprep]
195 and hence unassigned code points are allowed appear in their prepared
196 output. When preparing the database strings using [SASLprep], the
197 database strings are to be treated as "stored" strings [Section 7,
198 Stringprep] and hence unassigned code points are prohibited from
199 appearing in their prepared output.
201 Regardless of the preparation algorithm used, if the output of a non-
202 invertible function (e.g., hash) of the expected string is stored, the
203 string MUST be prepared before input to that function.
205 Regardless of the preparation algorithm used, if preparation fails or
206 results in an empty string, verification SHALL fail.
208 When no authorization identity is provided, the server derives an
209 authorization identity from the prepared representation of the
210 provided authentication identity string. This ensures that the
211 derivation of different representations of the authentication identity
212 produce the same authorization identity.
214 The server MAY use the credentials to initialize any new
215 authentication database, such as one suitable for [CRAM-MD5] or
225 Zeilenga The SASL PLAIN Mechanism [Page 4]
227 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
232 This section provides pseudo-code illustrating the verification
233 process (using hashed passwords and the SASLprep preparation function)
234 discussed above. This section is not definitive.
236 boolean Verify(string authzid, string authcid, string passwd) {
237 string pAuthcid = SASLprep(authcid, true); # prepare authcid
238 string pPasswd = SASLprep(passwd, true); # prepare passwd
239 if (pAuthcid == NULL || pPasswd == NULL) {
240 return false; # preparation failed
242 if (pAuthcid == "" || pPasswd == "") {
243 return false; # empty prepared string
246 storedHash = FetchPasswordHash(pAuthcid);
247 if (storedHash == NULL || storedHash == "") {
248 return false; # error or unknown authcid
251 if (!Compare(storedHash, Hash(pPasswd))) {
252 return false; # incorrect password
255 if (authzid == NULL ) {
256 authzid = DeriveAuthzid(pAuthcid);
257 if (authzid == NULL || authzid == "") {
258 return false; # could not derive authzid
262 if (!Authorize(pAuthcid, authzid)) {
263 return false; # not authorized
269 The second parameter of the SASLprep function, when true, indicates
270 that unassigned code points are allowed in the input. When the
271 SASLprep function is called to prepare the password prior to computing
272 the stored hash, the second parameter would be false.
274 The second parameter provided to the Authorize function is not
275 prepared by this code. The application-level SASL profile should be
276 consulted to determine what, if any, preparation is necessary.
281 Zeilenga The SASL PLAIN Mechanism [Page 5]
283 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
286 It is noted that the DerivateAuthzid and Authorize functions (whether
287 implemented as one function or two, whether designed in a manner in
288 which these functions or the mechanism implementation can be reused
289 elsewhere) require knowledge and understanding of mechanism and the
290 application-level protocol specification and/or implementation details
293 It is also noted that the Authorize function outcome is clearly
294 dependent on details of the local authorization model and policy.
295 Both functions may be dependent on other factors as well.
300 This section provides examples of PLAIN authentication exchanges. The
301 examples are intended to help the readers understand the above text.
302 The examples are not definitive.
304 "C:" and "S:" indicate lines sent by the client and server
305 respectively. "<NULL>" represents a single NULL (U+0000) character.
306 The Application Configuration Access Protocol ([ACAP]) is used in the
309 The first example shows how the PLAIN mechanism might be used for user
312 S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
314 S: a001 OK "Begin TLS negotiation now"
315 <TLS negotiation, further commands are under TLS layer>
316 S: * ACAP (SASL "CRAM-MD5" "PLAIN")
317 C: a002 AUTHENTICATE "PLAIN"
320 C: <NULL>tim<NULL>tanstaaftanstaaf
321 S: a002 OK "Authenticated"
323 The second example shows how the PLAIN mechanism might be used to
324 assume the identity of another user. In this example, the server
325 rejects the request. Also, this example makes use of the protocol
326 optional initial response capability to eliminate a round-trip.
328 S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
330 S: a001 OK "Begin TLS negotiation now"
331 <TLS negotiation, further commands are under TLS layer>
332 S: * ACAP (SASL "CRAM-MD5" "PLAIN")
333 C: a002 AUTHENTICATE "PLAIN" {20+}
337 Zeilenga The SASL PLAIN Mechanism [Page 6]
339 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
342 C: Ursel<NULL>Kurt<NULL>xipj3plmq
343 S: a002 NO "Not authorized to assume asserted identity"
346 6. Security Considerations
348 As the PLAIN mechanism itself provided no integrity nor
349 confidentiality protections, it should not be used without adequate
350 external data security protection, such as TLS services provided by
351 many application layer protocols. By default, implementations SHOULD
352 NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
353 adequate data security services are in place.
355 When the PLAIN mechanism is used, the server gains the ability to
356 impersonate the user to all services with the same password regardless
357 of any encryption provided by TLS or other network privacy mechanisms.
358 While many other authentication mechanisms have similar weaknesses,
359 stronger SASL mechanisms address this issue. Clients are encouraged
360 to have an operational mode where all mechanisms which are likely to
361 reveal the user's password to the server are disabled.
363 General SASL security considerations apply to this mechanism.
364 "stringprep" and Unicode [StringPrep] security considerations also
365 apply, as do [UTF-8] security considerations.
368 7. IANA Considerations
370 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
371 the PLAIN mechanism be updated to reflect that this document now
372 provides its technical specification.
375 Subject: Updated Registration of SASL mechanism PLAIN
377 SASL mechanism name: PLAIN
378 Security considerations: See RFC XXXX.
379 Published specification (optional, recommended): RFC XXXX
380 Person & email address to contact for further information:
381 Kurt Zeilenga <kurt@openldap.org>
382 IETF SASL WG <ietf-sasl@imc.org>
383 Intended usage: COMMON
384 Author/Change controller: IESG <iesg@ietf.org>
385 Note: Updates existing entry for PLAIN
393 Zeilenga The SASL PLAIN Mechanism [Page 7]
395 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
398 This document is a revision of RFC 2595 by Chris Newman. Portions of
399 the grammar defined in Section 2 were borrowed from [UTF-8] by
402 This document is a product of the IETF SASL WG.
405 9. Normative References
407 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
408 Specifications: ABNF", RFC 2234, November 1997.
410 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate
411 Requirement Levels", BCP 14, RFC 2119, March 1997
413 [SASL] Melnikov, A. (Editor), "Simple Authentication and
414 Security Layer (SASL)",
415 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
417 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User
418 Names and Passwords", RFC 4013, February 2005.
420 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
421 Internationalized Strings ('stringprep')", RFC 3454,
424 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
425 3.2.0" is defined by "The Unicode Standard, Version 3.0"
426 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
427 as amended by the "Unicode Standard Annex #27: Unicode
428 3.1" (http://www.unicode.org/reports/tr27/) and by the
429 "Unicode Standard Annex #28: Unicode 3.2"
430 (http://www.unicode.org/reports/tr28/).
432 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
433 10646", RFC 3629 (also STD 63), November 2003.
435 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
436 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
440 10. Informative References
442 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
443 Configuration Access Protocol", RFC 2244, November 1997.
444 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
445 draft-ietf-sasl-crammd5-xx.txt, a work in progress.
449 Zeilenga The SASL PLAIN Mechanism [Page 8]
451 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
454 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
455 Authentication as a SASL Mechanism",
456 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
458 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
460 <http://www.iana.org/assignments/sasl-mechanisms>.
462 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
463 RFC 2554, March 1999.
472 Email: Kurt@OpenLDAP.org
475 Appendix A. Changes since RFC 2595
477 This appendix is non-normative.
479 This document replaces Section 6 of RFC 2595.
481 The specification details how the server is to compare client-provided
482 character strings with stored character strings.
484 The ABNF grammar was updated. In particular, the grammar now allows
485 LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
486 authzid, authcid, passwd productions. However, whether these control
487 characters may be used depends on the string preparation rules
488 applicable to the production. For passwd and authcid productions,
489 control characters are prohibited. For authzid, one must consult the
490 application-level SASL profile.
492 Pseudo-code was added.
494 The example section was expanded to illustrate more features of the
499 Intellectual Property Rights
501 The IETF takes no position regarding the validity or scope of any
505 Zeilenga The SASL PLAIN Mechanism [Page 9]
507 INTERNET-DRAFT draft-ietf-sasl-plain-08.txt 18 March 2005
510 Intellectual Property Rights or other rights that might be claimed to
511 pertain to the implementation or use of the technology described in
512 this document or the extent to which any license under such rights
513 might or might not be available; nor does it represent that it has
514 made any independent effort to identify any such rights. Information
515 on the procedures with respect to rights in RFC documents can be found
516 in BCP 78 and BCP 79.
518 Copies of IPR disclosures made to the IETF Secretariat and any
519 assurances of licenses to be made available, or the result of an
520 attempt made to obtain a general license or permission for the use of
521 such proprietary rights by implementers or users of this specification
522 can be obtained from the IETF on-line IPR repository at
523 http://www.ietf.org/ipr.
525 The IETF invites any interested party to bring to its attention any
526 copyrights, patents or patent applications, or other proprietary
527 rights that may cover technology that may be required to implement
528 this standard. Please address the information to the IETF at
535 Copyright (C) The Internet Society (2005). This document is subject
536 to the rights, licenses and restrictions contained in BCP 78, and
537 except as set forth therein, the authors retain all their rights.
539 This document and the information contained herein are provided on an
540 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
541 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
542 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
543 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
544 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
545 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
561 Zeilenga The SASL PLAIN Mechanism [Page 10]