idnits 2.17.1 draft-murchison-sasl-login-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 253 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 August 2003) is 7540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- No information found for draft-ietf-sasl-plain-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft K. Murchison 3 Category: Informational M. Crispin 4 Expires: March 2, 2004 28 August 2003 6 The LOGIN SASL Mechanism 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society 2003. All Rights Reserved. 35 Abstract 37 This document documents the obsolete clear-text user/password Simple 38 Authentication and Security Layer (SASL) mechanism called the LOGIN 39 mechanism. The LOGIN mechanism was intended to be used, in 40 combination with data confidentiality services provided by a lower 41 layer, in protocols which lack a simple password authentication 42 command. 44 Conventions Used in the Document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [KEYWORDS]. 50 1. Background and Intended Usage 52 This document documents the obsolete LOGIN Simple Authentication and 53 Security Layer ([SASL]) mechanism which was in use in protocols with 54 no clear-text login command (e.g., [SMTP-AUTH]). 56 Note: The LOGIN SASL mechanism is obsoleted in favor of the PLAIN 57 SASL mechanism ([PLAIN]). The LOGIN mechanism is documented here 58 only for the purpose of backwards compatibility with legacy software. 59 Clients SHOULD implement the PLAIN SASL mechanism and use it whenever 60 offered by a server. The LOGIN SASL mechanism SHOULD NOT be used by 61 a client when other plaintext mechanisms are offered by a server. 63 The name associated with this mechanism is "LOGIN". 65 The LOGIN SASL mechanism does not provide a security layer. This 66 mechanism MUST NOT be used without adequate security protection as 67 the mechanism affords no integrity nor confidentiality protection 68 itself. The LOGIN SASL mechanism MUST NOT be advertised or used in 69 any configuration that prohibits the PLAIN mechanism or plaintext 70 LOGIN (or USER/PASS) command that sends passwords in the clear. 72 2. LOGIN SASL Mechanism 74 The authorization identity is the same string as the "username" in 75 the traditional (non-SASL) LOGIN or USER commands; the authorization 76 authenticator is the same string as the traditional "password". The 77 authentication identity is the same as the authorization identity in 78 this mechanism. 80 Only US-ASCII printable characters SHOULD be used in the username and 81 password to permit maximal interoperability. If non-US-ASCII 82 characters are used in a username, they MUST use UTF-8. Passwords 83 MAY contain arbitrary binary data excluding NUL, CR and LF 84 characters. However, if a password is supplied to the client as a 85 sequence of characters (e.g., a password dialog box), those 86 characters MUST be encoded as UTF-8. 88 The username MUST be less than 64 characters in length. 90 2.1. Client side of authentication protocol exchange 92 The client expects the server to issue a challenge. The client then 93 responds with the authorization identity. The client then expects 94 the server to issue a second challenge. The client then responds 95 with the authorization authenticator. The contents of both 96 challenges SHOULD be ignored. 98 2.2. Server side of authentication protocol exchange 100 The server issues the string "User Name" in challenge, and receives a 101 client response. This response is recorded as the authorization 102 identity. The server then issues the string "Password" in challenge, 103 and receives a client response. This response is recorded as the 104 authorization authenticator. The server must verify that the 105 authorization authenticator permits login as the authorization 106 identity. 108 Note: There is at least one widely deployed client which requires 109 that the challenge strings transmitted by the server be "Username:" 110 and "Password:" respectively. For this reason, server 111 implementations MAY send these challenge strings instead of those 112 listed above. 114 2.3. Example 116 This example shows the use of the LOGIN mechanism with the SMTP AUTH 117 command [SMTP-AUTH] under the protection of SMTP STARTTLS [SMTP-TLS]. 118 The user name is "tim" and the password is "tanstaaftanstaaf". The 119 base64 encoding of the challenges and responses is part of the SMTP 120 AUTH command, not part of the LOGIN specification itself. "C:" and 121 "S:" indicate lines sent by the client and server respectively. 123 S: 220 smtp.example.com ESMTP server ready 124 C: EHLO test.example.com 125 S: 250-smtp.example.com 126 S: 250-STARTTLS 127 S: 250 AUTH CRAM-MD5 128 C: STARTTLS 129 S: 220 Ready to start TLS 130 131 C: EHLO test.example.com 132 S: 250-smtp.example.com 133 S: 250 AUTH LOGIN CRAM-MD5 134 C: AUTH LOGIN 135 S: 334 VXNlciBOYW1lAA== 136 C: dGlt 137 S: 334 UGFzc3dvcmQA 138 C: dGFuc3RhYWZ0YW5zdGFhZg== 139 S: 235 Authentication successful. 141 3. 142 Security Considerations 144 The LOGIN mechanism relies upon an underlying encryption layer or 145 other secure channel for security. When used without an encryption 146 layer or secure channel, it is vulnerable to a common network 147 eavesdropping attack. Therefore the LOGIN mechanism MUST NOT be 148 advertised or used in any configuration that prohibits the PLAIN 149 mechanism or a plaintext LOGIN (or USER/PASS) command that sends 150 passwords in the clear. 152 4. 153 IANA Considerations 155 The registration for the LOGIN SASL mechanism follows: 157 SASL mechanism name: LOGIN 158 Security Considerations: See section 3 of this memo 159 Published specification: this memo 160 Person & email address to contact for futher information: 161 See section 7 of this memo 162 Intended usage: OBSOLETE 163 Owner/Change controller: See section 7 of this memo 165 5. 166 References 168 5.1. 169 Normative References 171 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", Harvard University, RFC 2119, March 1997. 174 [SASL] Melnikov, A., Ed., "Simple Authentication and Security Layer 175 (SASL)", Isode, draft-ietf-sasl-rfc2222bis-xx.txt, Work In 176 Progress. 178 5.2. Informative References 180 [PLAIN] Zeilenga, Kurt D., Ed., "The Plain SASL Mechanism", 181 OpenLDAP Foundation, draft-ietf-sasl-plain-xx.txt, Work In 182 Progress. 184 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 185 Netscape Communications, RFC 2554, March 1999. 187 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP 188 over Transport Layer Security", Internet Mail Consortium, RFC 189 3207, February 2002. 191 6. Acknowledgments 193 Thanks to Rob Siemborski for his input and feedback on this document. 195 7. 196 Author's Address 198 Kenneth Murchison 199 Oceana Matrix Ltd. 200 21 Princeton Place 201 Orchard Park, NY 14127 203 Phone: (716) 662-8973 205 EMail: ken@oceana.com 207 Mark R. Crispin 208 Networks and Distributed Computing 209 University of Washington 210 4545 15th Avenue NE 211 Seattle, WA 98105-4527 213 Phone: (206) 543-5762 215 EMail: MRC@CAC.Washington.EDU 217 8. 218 Intellectual Property Considerations 220 The IETF takes no position regarding the validity or scope of any 221 intellectual property or other rights that might be claimed to 222 pertain to the implementation or use of the technology described in 223 this document or the extent to which any license under such rights 224 might or might not be available; neither does it represent that it has 225 made any effort to identify any such rights. Information on the 226 IETF's procedures with respect to rights in standards-track and 227 standards-related documentation can be found in BCP-11. Copies of 228 claims of rights made available for publication and any assurances of 229 licenses to be made available, or the result of an attempt made to 230 obtain a general license or permission for the use of such proprietary 231 rights by implementors or users of this specification can be obtained 232 from the IETF Secretariat. 234 The IETF invites any interested party to bring to its attention any 235 copyrights, patents or patent applications, or other proprietary 236 rights which may cover technology that may be required to practice 237 this standard. Please address the information to the IETF Executive 238 Director. 240 9. 241 Full Copyright Statement 243 Copyright (C) The Internet Society 2003. All Rights Reserved. 245 This document and translations of it may be copied and furnished to 246 others, and derivative works that comment on or otherwise explain it 247 or assist in its implmentation may be prepared, copied, published and 248 distributed, in whole or in part, without restriction of any kind, 249 provided that the above copyright notice and this paragraph are 250 included on all such copies and derivative works. However, this 251 document itself may not be modified in any way, such as by removing 252 the copyright notice or references to the Internet Society or other 253 Internet organizations, except as needed for the purpose of 254 developing Internet standards in which case the procedures for 255 copyrights defined in the Internet Standards process must be followed, 256 or as required to translate it into languages other than English. 258 The limited permissions granted above are perpetual and will not be 259 revoked by the Internet Society or its successors or assigns. 261 This document and the information contained herein is provided on an 262 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 263 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 264 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 265 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 266 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.