8 Internet Draft K. Murchison
9 Category: Informational M. Crispin
10 Expires: March 2, 2004 28 August 2003
13 The LOGIN SASL Mechanism
15 <draft-murchison-sasl-login-00.txt>
20 This document is an Internet-Draft and is subject to all provisions
21 of Section 10 of RFC2026.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/1id-abstracts.html
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html
42 Copyright (C) The Internet Society 2003. All Rights Reserved.
47 This document documents the obsolete clear-text user/password Simple
48 Authentication and Security Layer (SASL) mechanism called the LOGIN
49 mechanism. The LOGIN mechanism was intended to be used, in
50 combination with data confidentiality services provided by a lower
51 layer, in protocols which lack a simple password authentication
59 Expires: March 2, 2004 Murchison [Page 1]
61 Internet Draft LOGIN SASL Mechanism August 28, 2004
65 Conventions Used in the Document
67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
69 document are to be interpreted as described in [KEYWORDS].
72 1. Background and Intended Usage
74 This document documents the obsolete LOGIN Simple Authentication and
75 Security Layer ([SASL]) mechanism which was in use in protocols with
76 no clear-text login command (e.g., [SMTP-AUTH]).
78 Note: The LOGIN SASL mechanism is obsoleted in favor of the PLAIN
79 SASL mechanism ([PLAIN]). The LOGIN mechanism is documented here
80 only for the purpose of backwards compatibility with legacy software.
81 Clients SHOULD implement the PLAIN SASL mechanism and use it whenever
82 offered by a server. The LOGIN SASL mechanism SHOULD NOT be used by
83 a client when other plaintext mechanisms are offered by a server.
85 The name associated with this mechanism is "LOGIN".
87 The LOGIN SASL mechanism does not provide a security layer. This
88 mechanism MUST NOT be used without adequate security protection as
89 the mechanism affords no integrity nor confidentiality protection
90 itself. The LOGIN SASL mechanism MUST NOT be advertised or used in
91 any configuration that prohibits the PLAIN mechanism or plaintext
92 LOGIN (or USER/PASS) command that sends passwords in the clear.
95 2. LOGIN SASL Mechanism
97 The authorization identity is the same string as the "username" in
98 the traditional (non-SASL) LOGIN or USER commands; the authorization
99 authenticator is the same string as the traditional "password". The
100 authentication identity is the same as the authorization identity in
103 Only US-ASCII printable characters SHOULD be used in the username and
104 password to permit maximal interoperability. If non-US-ASCII
105 characters are used in a username, they MUST use UTF-8. Passwords
106 MAY contain arbitrary binary data excluding NUL, CR and LF
107 characters. However, if a password is supplied to the client as a
108 sequence of characters (e.g., a password dialog box), those
109 characters MUST be encoded as UTF-8.
111 The username MUST be less than 64 characters in length.
115 Expires: March 2, 2004 Murchison [Page 2]
117 Internet Draft LOGIN SASL Mechanism August 28, 2004
120 2.1. Client side of authentication protocol exchange
122 The client expects the server to issue a challenge. The client then
123 responds with the authorization identity. The client then expects
124 the server to issue a second challenge. The client then responds
125 with the authorization authenticator. The contents of both
126 challenges SHOULD be ignored.
129 2.2. Server side of authentication protocol exchange
131 The server issues the string "User Name" in challenge, and receives a
132 client response. This response is recorded as the authorization
133 identity. The server then issues the string "Password" in challenge,
134 and receives a client response. This response is recorded as the
135 authorization authenticator. The server must verify that the
136 authorization authenticator permits login as the authorization
139 Note: There is at least one widely deployed client which requires
140 that the challenge strings transmitted by the server be "Username:"
141 and "Password:" respectively. For this reason, server
142 implementations MAY send these challenge strings instead of those
148 This example shows the use of the LOGIN mechanism with the SMTP AUTH
149 command [SMTP-AUTH] under the protection of SMTP STARTTLS [SMTP-TLS].
150 The user name is "tim" and the password is "tanstaaftanstaaf". The
151 base64 encoding of the challenges and responses is part of the SMTP
152 AUTH command, not part of the LOGIN specification itself. "C:" and
153 "S:" indicate lines sent by the client and server respectively.
155 S: 220 smtp.example.com ESMTP server ready
156 C: EHLO test.example.com
157 S: 250-smtp.example.com
161 S: 220 Ready to start TLS
162 <TLS negotiation, further commands are under TLS layer>
163 C: EHLO test.example.com
164 S: 250-smtp.example.com
165 S: 250 AUTH LOGIN CRAM-MD5
167 S: 334 VXNlciBOYW1lAA==
171 Expires: March 2, 2004 Murchison [Page 3]
173 Internet Draft LOGIN SASL Mechanism August 28, 2004
178 C: dGFuc3RhYWZ0YW5zdGFhZg==
179 S: 235 Authentication successful.
183 Security Considerations
185 The LOGIN mechanism relies upon an underlying encryption layer or
186 other secure channel for security. When used without an encryption
187 layer or secure channel, it is vulnerable to a common network
188 eavesdropping attack. Therefore the LOGIN mechanism MUST NOT be
189 advertised or used in any configuration that prohibits the PLAIN
190 mechanism or a plaintext LOGIN (or USER/PASS) command that sends
191 passwords in the clear.
197 The registration for the LOGIN SASL mechanism follows:
199 SASL mechanism name: LOGIN
200 Security Considerations: See section 3 of this memo
201 Published specification: this memo
202 Person & email address to contact for futher information:
203 See section 7 of this memo
204 Intended usage: OBSOLETE
205 Owner/Change controller: See section 7 of this memo
216 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
217 Requirement Levels", Harvard University, RFC 2119, March 1997.
220 [SASL] Melnikov, A., Ed., "Simple Authentication and Security Layer
221 (SASL)", Isode, draft-ietf-sasl-rfc2222bis-xx.txt, Work In
227 Expires: March 2, 2004 Murchison [Page 4]
229 Internet Draft LOGIN SASL Mechanism August 28, 2004
232 5.2. Informative References
235 [PLAIN] Zeilenga, Kurt D., Ed., "The Plain SASL Mechanism",
236 OpenLDAP Foundation, draft-ietf-sasl-plain-xx.txt, Work In
240 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
241 Netscape Communications, RFC 2554, March 1999.
244 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
245 over Transport Layer Security", Internet Mail Consortium, RFC
252 Thanks to Rob Siemborski for his input and feedback on this document.
261 Orchard Park, NY 14127
263 Phone: (716) 662-8973
265 EMail: ken@oceana.com
271 Networks and Distributed Computing
272 University of Washington
274 Seattle, WA 98105-4527
276 Phone: (206) 543-5762
278 EMail: MRC@CAC.Washington.EDU
283 Expires: March 2, 2004 Murchison [Page 5]
285 Internet Draft LOGIN SASL Mechanism August 28, 2004
289 Intellectual Property Considerations
291 The IETF takes no position regarding the validity or scope of any
292 intellectual property or other rights that might be claimed to
293 pertain to the implementation or use of the technology described in
294 this document or the extent to which any license under such rights
295 might or might not be available; neither does it represent that it has
296 made any effort to identify any such rights. Information on the
297 IETF's procedures with respect to rights in standards-track and
298 standards-related documentation can be found in BCP-11. Copies of
299 claims of rights made available for publication and any assurances of
300 licenses to be made available, or the result of an attempt made to
301 obtain a general license or permission for the use of such proprietary
302 rights by implementors or users of this specification can be obtained
303 from the IETF Secretariat.
305 The IETF invites any interested party to bring to its attention any
306 copyrights, patents or patent applications, or other proprietary
307 rights which may cover technology that may be required to practice
308 this standard. Please address the information to the IETF Executive
339 Expires: March 2, 2004 Murchison [Page 6]
341 Internet Draft LOGIN SASL Mechanism August 28, 2004
345 Full Copyright Statement
347 Copyright (C) The Internet Society 2003. All Rights Reserved.
349 This document and translations of it may be copied and furnished to
350 others, and derivative works that comment on or otherwise explain it
351 or assist in its implmentation may be prepared, copied, published and
352 distributed, in whole or in part, without restriction of any kind,
353 provided that the above copyright notice and this paragraph are
354 included on all such copies and derivative works. However, this
355 document itself may not be modified in any way, such as by removing
356 the copyright notice or references to the Internet Society or other
357 Internet organizations, except as needed for the purpose of
358 developing Internet standards in which case the procedures for
359 copyrights defined in the Internet Standards process must be followed,
360 or as required to translate it into languages other than English.
362 The limited permissions granted above are perpetual and will not be
363 revoked by the Internet Society or its successors or assigns.
365 This document and the information contained herein is provided on an
366 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
367 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
368 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
395 Expires: March 2, 2004 Murchison [Page 7]