idnits 2.17.1 draft-ietf-sasl-plain-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 434), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (16 June 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 7' is mentioned on line 156, but not defined == Missing Reference: 'Stringprep' is mentioned on line 156, but not defined == Missing Reference: 'SASLprep' is mentioned on line 158, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4013 (ref. 'SASLPrep') (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- No information found for draft-ietf-sasl-crammd5-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standards Track OpenLDAP Foundation 4 Expires December 2006 16 June 2006 5 Updates: RFC 2595 7 The PLAIN SASL Mechanism 8 10 Status of Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Standards Track document. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF SASL mailing list 16 . Please send editorial comments directly to the 17 document editor . 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware have 21 been or will be disclosed, and any of which he or she becomes aware 22 will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 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 material 31 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. 39 Copyright (C) The Internet Society (2006). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 This document defines a simple clear-text user/password Simple 47 Authentication and Security Layer (SASL) mechanism called the PLAIN 48 mechanism. The PLAIN mechanism is intended to be used, in combination 49 with data confidentiality services provided by a lower layer, in 50 protocols which lack a simple password authentication command. 52 1. Background and Intended Usage 54 Clear-text, multiple-use passwords are simple, interoperate with 55 almost all existing operating system authentication databases, and are 56 useful for a smooth transition to a more secure password-based 57 authentication mechanism. The drawback is that they are unacceptable 58 for use over network connection where data confidentiality is not 59 assured (by encryption or other means). 61 This document defines the PLAIN Simple Authentication and Security 62 Layer ([SASL]) mechanism for use in protocols with no clear-text login 63 command (e.g., [ACAP] or [SMTP-AUTH]). This document updates RFC 64 2595, replacing Section 6. Changes since RFC 2595 are detailed in 65 Appendix A. 67 The name associated with this mechanism is "PLAIN". 69 The PLAIN SASL mechanism does not provide a security layer. 71 The PLAIN mechanism should not be used without adequate data security 72 protection as this mechanism affords no integrity nor confidentiality 73 protections itself. The mechanism is intended to be used with data 74 security protections provided by application layer protocol, generally 75 through its use of Transport Layer Security ([TLS]) services. 77 By default, implementations SHOULD advertise and make use of the PLAIN 78 mechanism only when adequate data security services are in place. 79 Specifications for IETF protocols which indicate that this mechanism 80 is an applicable authentication mechanism MUST mandate that 81 implementations support an strong data security service, such as TLS. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [Keywords]. 87 2. PLAIN SASL mechanism 89 The mechanism consists of a single message, a string of [UTF-8] 90 encoded [Unicode] characters, from the client to the server. The 91 client presents the authorization identity (identity to act as), 92 followed by a NULL (U+0000) character, followed by the authentication 93 identity (identity whose password will be used), followed by a NULL 94 (U+0000) character, followed by the clear-text password. As with 95 other SASL mechanisms, the client does not provide an authorization 96 identity when it wishes the server to derive an identity from the 97 credentials and use that as the authorization identity. 99 The formal grammar for the client message using Augmented BNF [ABNF] 100 follows. 102 message = [authzid] UTF8NULL authcid UTF8NULL passwd 103 authcid = 1*SAFE ; MUST accept up to 255 octets 104 authzid = 1*SAFE ; MUST accept up to 255 octets 105 passwd = 1*SAFE ; MUST accept up to 255 octets 106 UTF8NULL = %x00 ; UTF-8 encoded NULL character 108 SAFE = UTF1 / UTF2 / UTF3 / UTF4 109 ;; any UTF-8 encoded Unicode character except NULL 111 UTF1 = %x01-7F ;; except NULL 112 UTF2 = %xC2-DF UTF0 113 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 114 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 115 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 116 %xF4 %x80-8F 2(UTF0) 117 UTF0 = %x80-BF 119 The authorization identity (authzid), authentication identity 120 (authcid), password (passwd), and NULL character deliminators SHALL be 121 transferred as [UTF-8] encoded strings of [Unicode] characters. As 122 the NULL (U+0000) character is used as a deliminator, the NULL 123 (U+0000) character MUST NOT appear in authzid, authcid, or passwd 124 productions. 126 The form of the authzid production is specific to the 127 application-level protocol's SASL profile [SASL]. The authcid and 128 passwd productions are form-free. Use of non-visible characters or 129 characters which a user may be unable to enter on some keyboards is 130 discouraged. 132 Servers MUST be capable of accepting authzid, authcid, and passwd 133 productions up to and including 255 octets. It is noted that the 134 UTF-8 encoding of a Unicode character may be as long as 4 octets. 136 Upon receipt of the message, the server will verify the presented (in 137 the message) authentication identity (authcid) and password (passwd) 138 with the system authentication database, and verify the authentication 139 credentials permit the client to act as the (presented or derived) 140 authorization identity. If both steps succeed, the user is 141 authenticated. 143 The presented authentication identity and password strings, as well as 144 the database authentication identity and password strings, are to be 145 prepared before being used in the verification process. The 146 [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED 147 preparation algorithm. The SASLprep preparation algorithm is 148 recommended to improve the likelihood that comparisons behave in an 149 expected manner. The SASLprep preparation algorithm is not so as to 150 allow the server to employ other preparation algorithms (including 151 none) when appropriate. For instance, use of different preparation 152 algorithm may be necessary for the server to interoperate with an 153 external system. 155 When preparing the presented strings using [SASLPrep], the presented 156 strings are to be treated as "query" strings [Section 7, Stringprep] 157 and hence unassigned code points are allowed appear in their prepared 158 output. When preparing the database strings using [SASLprep], the 159 database strings are to be treated as "stored" strings [Section 7, 160 Stringprep] and hence unassigned code points are prohibited from 161 appearing in their prepared output. 163 Regardless of the preparation algorithm used, if the output of a non- 164 invertible function (e.g., hash) of the expected string is stored, the 165 string MUST be prepared before input to that function. 167 Regardless of the preparation algorithm used, if preparation fails or 168 results in an empty string, verification SHALL fail. 170 When no authorization identity is provided, the server derives an 171 authorization identity from the prepared representation of the 172 provided authentication identity string. This ensures that the 173 derivation of different representations of the authentication identity 174 produce the same authorization identity. 176 The server MAY use the credentials to initialize any new 177 authentication database, such as one suitable for [CRAM-MD5] or 178 [DIGEST-MD5]. 180 4. Pseudo-Code 182 This section provides pseudo-code illustrating the verification 183 process (using hashed passwords and the SASLprep preparation function) 184 discussed above. This section is not definitive. 186 boolean Verify(string authzid, string authcid, string passwd) { 187 string pAuthcid = SASLprep(authcid, true); # prepare authcid 188 string pPasswd = SASLprep(passwd, true); # prepare passwd 189 if (pAuthcid == NULL || pPasswd == NULL) { 190 return false; # preparation failed 191 } 192 if (pAuthcid == "" || pPasswd == "") { 193 return false; # empty prepared string 194 } 196 storedHash = FetchPasswordHash(pAuthcid); 197 if (storedHash == NULL || storedHash == "") { 198 return false; # error or unknown authcid 199 } 201 if (!Compare(storedHash, Hash(pPasswd))) { 202 return false; # incorrect password 203 } 205 if (authzid == NULL ) { 206 authzid = DeriveAuthzid(pAuthcid); 207 if (authzid == NULL || authzid == "") { 208 return false; # could not derive authzid 209 } 210 } 212 if (!Authorize(pAuthcid, authzid)) { 213 return false; # not authorized 214 } 216 return true; 217 } 219 The second parameter of the SASLprep function, when true, indicates 220 that unassigned code points are allowed in the input. When the 221 SASLprep function is called to prepare the password prior to computing 222 the stored hash, the second parameter would be false. 224 The second parameter provided to the Authorize function is not 225 prepared by this code. The application-level SASL profile should be 226 consulted to determine what, if any, preparation is necessary. 228 Note that the DeriveAuthzid and Authorize functions (whether 229 implemented as one function or two, whether designed in a manner in 230 which these functions or whether the mechanism implementation can be 231 reused elsewhere) require knowledge and understanding of mechanism and 232 the application-level protocol specification and/or implementation 233 details to implement. 235 Note that the Authorize function outcome is clearly dependent on 236 details of the local authorization model and policy. Both functions 237 may be dependent on other factors as well. 239 5. Examples 241 This section provides examples of PLAIN authentication exchanges. The 242 examples are intended to help the readers understand the above text. 243 The examples are not definitive. 245 "C:" and "S:" indicate lines sent by the client and server 246 respectively. "" represents a single NUL (U+0000) character. 247 The Application Configuration Access Protocol ([ACAP]) is used in the 248 examples. 250 The first example shows how the PLAIN mechanism might be used for user 251 authentication. 253 S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 254 C: a001 STARTTLS 255 S: a001 OK "Begin TLS negotiation now" 256 257 S: * ACAP (SASL "CRAM-MD5" "PLAIN") 258 C: a002 AUTHENTICATE "PLAIN" 259 S: + "" 260 C: {21} 261 C: timtanstaaftanstaaf 262 S: a002 OK "Authenticated" 264 The second example shows how the PLAIN mechanism might be used to 265 attempt to assume the identity of another user. In this example, the 266 server rejects the request. Also, this example makes use of the 267 protocol optional initial response capability to eliminate a 268 round-trip. 270 S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 271 C: a001 STARTTLS 272 S: a001 OK "Begin TLS negotiation now" 273 274 S: * ACAP (SASL "CRAM-MD5" "PLAIN") 275 C: a002 AUTHENTICATE "PLAIN" {20+} 276 C: UrselKurtxipj3plmq 277 S: a002 NO "Not authorized to requested authorization identity" 279 6. Security Considerations 280 As the PLAIN mechanism itself provided no integrity nor 281 confidentiality protections, it should not be used without adequate 282 external data security protection, such as TLS services provided by 283 many application layer protocols. By default, implementations SHOULD 284 NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless 285 adequate data security services are in place. 287 When the PLAIN mechanism is used, the server gains the ability to 288 impersonate the user to all services with the same password regardless 289 of any encryption provided by TLS or other confidentiality protection 290 mechanisms. While many other authentication mechanisms have similar 291 weaknesses, stronger SASL mechanisms address this issue. Clients are 292 encouraged to have an operational mode where all mechanisms which are 293 likely to reveal the user's password to the server are disabled. 295 General [SASL] security considerations apply to this mechanism. 297 Unicode, [UTF-8], and [StringPrep] security considerations also apply. 299 7. IANA Considerations 301 It is requested that the SASL Mechanism registry [IANA-SASL] entry for 302 the PLAIN mechanism be updated to reflect that this document now 303 provides its technical specification. 305 To: iana@iana.org 306 Subject: Updated Registration of SASL mechanism PLAIN 308 SASL mechanism name: PLAIN 309 Security considerations: See RFC XXXX. 310 Published specification (optional, recommended): RFC XXXX 311 Person & email address to contact for further information: 312 Kurt Zeilenga 313 IETF SASL WG 314 Intended usage: COMMON 315 Author/Change controller: IESG 316 Note: Updates existing entry for PLAIN 318 8. Acknowledgment 320 This document is a revision of RFC 2595 by Chris Newman. Portions of 321 the grammar defined in Section 2 were borrowed from [UTF-8] by 322 Francois Yergeau. 324 This document is a product of the IETF Simple Authentication and 325 Security Layer (SASL) Working Group. 327 9. Normative References 329 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 330 Specifications: ABNF", RFC 4234, October 2005. 332 [Keywords] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997 335 [SASL] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple 336 Authentication and Security Layer (SASL)", RFC 4422, 337 June 2006. 339 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User 340 Names and Passwords", RFC 4013, February 2005. 342 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 343 Internationalized Strings ('stringprep')", RFC 3454, 344 December 2002. 346 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 347 3.2.0" is defined by "The Unicode Standard, Version 3.0" 348 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 349 as amended by the "Unicode Standard Annex #27: Unicode 350 3.1" (http://www.unicode.org/reports/tr27/) and by the 351 "Unicode Standard Annex #28: Unicode 3.2" 352 (http://www.unicode.org/reports/tr28/). 354 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 355 10646", RFC 3629 (also STD 63), November 2003. 357 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 358 1.1", RFC 4346, April 2006. 360 10. Informative References 362 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 363 Configuration Access Protocol", RFC 2244, November 1997. 364 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", 365 draft-ietf-sasl-crammd5-xx.txt, a work in progress. 367 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 368 Authentication as a SASL Mechanism", 369 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. 371 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 372 MECHANISMS", 373 . 375 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 376 RFC 2554, March 1999. 378 11. Editor's Address 380 Kurt D. Zeilenga 381 OpenLDAP Foundation 383 Email: Kurt@OpenLDAP.org 385 Appendix A. Changes since RFC 2595 387 This appendix is non-normative. 389 This document replaces Section 6 of RFC 2595. 391 The specification details how the server is to compare client-provided 392 character strings with stored character strings. 394 The ABNF grammar was updated. In particular, the grammar now allows 395 LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the 396 authzid, authcid, passwd productions. However, whether these control 397 characters may be used depends on the string preparation rules 398 applicable to the production. For passwd and authcid productions, 399 control characters are prohibited. For authzid, one must consult the 400 application-level SASL profile. This change allows PLAIN to carry all 401 possible authorization identity strings allowed in SASL. 403 Pseudo-code was added. 405 The example section was expanded to illustrate more features of the 406 PLAIN mechanism. 408 Intellectual Property 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be found 417 in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this specification 423 can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org. 432 Full Copyright 434 Copyright (C) The Internet Society (2006). 436 This document is subject to the rights, licenses and restrictions 437 contained in BCP 78, and except as set forth therein, the authors 438 retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.