1*ebfedea0SLionel Sambuc 2*ebfedea0SLionel Sambuc 3*ebfedea0SLionel Sambuc 4*ebfedea0SLionel Sambuc 5*ebfedea0SLionel Sambuc 6*ebfedea0SLionel Sambuc 7*ebfedea0SLionel SambucNetwork Working Group K. Zeilenga, Ed. 8*ebfedea0SLionel SambucRequest for Comments: 4616 OpenLDAP Foundation 9*ebfedea0SLionel SambucUpdates: 2595 August 2006 10*ebfedea0SLionel SambucCategory: Standards Track 11*ebfedea0SLionel Sambuc 12*ebfedea0SLionel Sambuc 13*ebfedea0SLionel Sambuc The PLAIN Simple Authentication and Security Layer (SASL) Mechanism 14*ebfedea0SLionel Sambuc 15*ebfedea0SLionel SambucStatus of This Memo 16*ebfedea0SLionel Sambuc 17*ebfedea0SLionel Sambuc This document specifies an Internet standards track protocol for the 18*ebfedea0SLionel Sambuc Internet community, and requests discussion and suggestions for 19*ebfedea0SLionel Sambuc improvements. Please refer to the current edition of the "Internet 20*ebfedea0SLionel Sambuc Official Protocol Standards" (STD 1) for the standardization state 21*ebfedea0SLionel Sambuc and status of this protocol. Distribution of this memo is unlimited. 22*ebfedea0SLionel Sambuc 23*ebfedea0SLionel SambucCopyright Notice 24*ebfedea0SLionel Sambuc 25*ebfedea0SLionel Sambuc Copyright (C) The Internet Society (2006). 26*ebfedea0SLionel Sambuc 27*ebfedea0SLionel SambucAbstract 28*ebfedea0SLionel Sambuc 29*ebfedea0SLionel Sambuc This document defines a simple clear-text user/password Simple 30*ebfedea0SLionel Sambuc Authentication and Security Layer (SASL) mechanism called the PLAIN 31*ebfedea0SLionel Sambuc mechanism. The PLAIN mechanism is intended to be used, in 32*ebfedea0SLionel Sambuc combination with data confidentiality services provided by a lower 33*ebfedea0SLionel Sambuc layer, in protocols that lack a simple password authentication 34*ebfedea0SLionel Sambuc command. 35*ebfedea0SLionel Sambuc 36*ebfedea0SLionel Sambuc 37*ebfedea0SLionel Sambuc 38*ebfedea0SLionel Sambuc 39*ebfedea0SLionel Sambuc 40*ebfedea0SLionel Sambuc 41*ebfedea0SLionel Sambuc 42*ebfedea0SLionel Sambuc 43*ebfedea0SLionel Sambuc 44*ebfedea0SLionel Sambuc 45*ebfedea0SLionel Sambuc 46*ebfedea0SLionel Sambuc 47*ebfedea0SLionel Sambuc 48*ebfedea0SLionel Sambuc 49*ebfedea0SLionel Sambuc 50*ebfedea0SLionel Sambuc 51*ebfedea0SLionel Sambuc 52*ebfedea0SLionel Sambuc 53*ebfedea0SLionel Sambuc 54*ebfedea0SLionel Sambuc 55*ebfedea0SLionel Sambuc 56*ebfedea0SLionel Sambuc 57*ebfedea0SLionel Sambuc 58*ebfedea0SLionel SambucZeilenga Standards Track [Page 1] 59*ebfedea0SLionel Sambuc 60*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 61*ebfedea0SLionel Sambuc 62*ebfedea0SLionel Sambuc 63*ebfedea0SLionel Sambuc1. Introduction 64*ebfedea0SLionel Sambuc 65*ebfedea0SLionel Sambuc Clear-text, multiple-use passwords are simple, interoperate with 66*ebfedea0SLionel Sambuc almost all existing operating system authentication databases, and 67*ebfedea0SLionel Sambuc are useful for a smooth transition to a more secure password-based 68*ebfedea0SLionel Sambuc authentication mechanism. The drawback is that they are unacceptable 69*ebfedea0SLionel Sambuc for use over network connections where data confidentiality is not 70*ebfedea0SLionel Sambuc ensured. 71*ebfedea0SLionel Sambuc 72*ebfedea0SLionel Sambuc This document defines the PLAIN Simple Authentication and Security 73*ebfedea0SLionel Sambuc Layer ([SASL]) mechanism for use in protocols with no clear-text 74*ebfedea0SLionel Sambuc login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates 75*ebfedea0SLionel Sambuc RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed 76*ebfedea0SLionel Sambuc in Appendix A. 77*ebfedea0SLionel Sambuc 78*ebfedea0SLionel Sambuc The name associated with this mechanism is "PLAIN". 79*ebfedea0SLionel Sambuc 80*ebfedea0SLionel Sambuc The PLAIN SASL mechanism does not provide a security layer. 81*ebfedea0SLionel Sambuc 82*ebfedea0SLionel Sambuc The PLAIN mechanism should not be used without adequate data security 83*ebfedea0SLionel Sambuc protection as this mechanism affords no integrity or confidentiality 84*ebfedea0SLionel Sambuc protections itself. The mechanism is intended to be used with data 85*ebfedea0SLionel Sambuc security protections provided by application-layer protocol, 86*ebfedea0SLionel Sambuc generally through its use of Transport Layer Security ([TLS]) 87*ebfedea0SLionel Sambuc services. 88*ebfedea0SLionel Sambuc 89*ebfedea0SLionel Sambuc By default, implementations SHOULD advertise and make use of the 90*ebfedea0SLionel Sambuc PLAIN mechanism only when adequate data security services are in 91*ebfedea0SLionel Sambuc place. Specifications for IETF protocols that indicate that this 92*ebfedea0SLionel Sambuc mechanism is an applicable authentication mechanism MUST mandate that 93*ebfedea0SLionel Sambuc implementations support an strong data security service, such as TLS. 94*ebfedea0SLionel Sambuc 95*ebfedea0SLionel Sambuc The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96*ebfedea0SLionel Sambuc "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97*ebfedea0SLionel Sambuc document are to be interpreted as described in [Keywords]. 98*ebfedea0SLionel Sambuc 99*ebfedea0SLionel Sambuc2. PLAIN SASL Mechanism 100*ebfedea0SLionel Sambuc 101*ebfedea0SLionel Sambuc The mechanism consists of a single message, a string of [UTF-8] 102*ebfedea0SLionel Sambuc encoded [Unicode] characters, from the client to the server. The 103*ebfedea0SLionel Sambuc client presents the authorization identity (identity to act as), 104*ebfedea0SLionel Sambuc followed by a NUL (U+0000) character, followed by the authentication 105*ebfedea0SLionel Sambuc identity (identity whose password will be used), followed by a NUL 106*ebfedea0SLionel Sambuc (U+0000) character, followed by the clear-text password. As with 107*ebfedea0SLionel Sambuc other SASL mechanisms, the client does not provide an authorization 108*ebfedea0SLionel Sambuc identity when it wishes the server to derive an identity from the 109*ebfedea0SLionel Sambuc credentials and use that as the authorization identity. 110*ebfedea0SLionel Sambuc 111*ebfedea0SLionel Sambuc 112*ebfedea0SLionel Sambuc 113*ebfedea0SLionel Sambuc 114*ebfedea0SLionel SambucZeilenga Standards Track [Page 2] 115*ebfedea0SLionel Sambuc 116*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 117*ebfedea0SLionel Sambuc 118*ebfedea0SLionel Sambuc 119*ebfedea0SLionel Sambuc The formal grammar for the client message using Augmented BNF [ABNF] 120*ebfedea0SLionel Sambuc follows. 121*ebfedea0SLionel Sambuc 122*ebfedea0SLionel Sambuc message = [authzid] UTF8NUL authcid UTF8NUL passwd 123*ebfedea0SLionel Sambuc authcid = 1*SAFE ; MUST accept up to 255 octets 124*ebfedea0SLionel Sambuc authzid = 1*SAFE ; MUST accept up to 255 octets 125*ebfedea0SLionel Sambuc passwd = 1*SAFE ; MUST accept up to 255 octets 126*ebfedea0SLionel Sambuc UTF8NUL = %x00 ; UTF-8 encoded NUL character 127*ebfedea0SLionel Sambuc 128*ebfedea0SLionel Sambuc SAFE = UTF1 / UTF2 / UTF3 / UTF4 129*ebfedea0SLionel Sambuc ;; any UTF-8 encoded Unicode character except NUL 130*ebfedea0SLionel Sambuc 131*ebfedea0SLionel Sambuc UTF1 = %x01-7F ;; except NUL 132*ebfedea0SLionel Sambuc UTF2 = %xC2-DF UTF0 133*ebfedea0SLionel Sambuc UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 134*ebfedea0SLionel Sambuc %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 135*ebfedea0SLionel Sambuc UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 136*ebfedea0SLionel Sambuc %xF4 %x80-8F 2(UTF0) 137*ebfedea0SLionel Sambuc UTF0 = %x80-BF 138*ebfedea0SLionel Sambuc 139*ebfedea0SLionel Sambuc The authorization identity (authzid), authentication identity 140*ebfedea0SLionel Sambuc (authcid), password (passwd), and NUL character deliminators SHALL be 141*ebfedea0SLionel Sambuc transferred as [UTF-8] encoded strings of [Unicode] characters. As 142*ebfedea0SLionel Sambuc the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) 143*ebfedea0SLionel Sambuc character MUST NOT appear in authzid, authcid, or passwd productions. 144*ebfedea0SLionel Sambuc 145*ebfedea0SLionel Sambuc The form of the authzid production is specific to the application- 146*ebfedea0SLionel Sambuc level protocol's SASL profile [SASL]. The authcid and passwd 147*ebfedea0SLionel Sambuc productions are form-free. Use of non-visible characters or 148*ebfedea0SLionel Sambuc characters that a user may be unable to enter on some keyboards is 149*ebfedea0SLionel Sambuc discouraged. 150*ebfedea0SLionel Sambuc 151*ebfedea0SLionel Sambuc Servers MUST be capable of accepting authzid, authcid, and passwd 152*ebfedea0SLionel Sambuc productions up to and including 255 octets. It is noted that the 153*ebfedea0SLionel Sambuc UTF-8 encoding of a Unicode character may be as long as 4 octets. 154*ebfedea0SLionel Sambuc 155*ebfedea0SLionel Sambuc Upon receipt of the message, the server will verify the presented (in 156*ebfedea0SLionel Sambuc the message) authentication identity (authcid) and password (passwd) 157*ebfedea0SLionel Sambuc with the system authentication database, and it will verify that the 158*ebfedea0SLionel Sambuc authentication credentials permit the client to act as the (presented 159*ebfedea0SLionel Sambuc or derived) authorization identity (authzid). If both steps succeed, 160*ebfedea0SLionel Sambuc the user is authenticated. 161*ebfedea0SLionel Sambuc 162*ebfedea0SLionel Sambuc The presented authentication identity and password strings, as well 163*ebfedea0SLionel Sambuc as the database authentication identity and password strings, are to 164*ebfedea0SLionel Sambuc be prepared before being used in the verification process. The 165*ebfedea0SLionel Sambuc [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED 166*ebfedea0SLionel Sambuc preparation algorithm. The SASLprep preparation algorithm is 167*ebfedea0SLionel Sambuc 168*ebfedea0SLionel Sambuc 169*ebfedea0SLionel Sambuc 170*ebfedea0SLionel SambucZeilenga Standards Track [Page 3] 171*ebfedea0SLionel Sambuc 172*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 173*ebfedea0SLionel Sambuc 174*ebfedea0SLionel Sambuc 175*ebfedea0SLionel Sambuc recommended to improve the likelihood that comparisons behave in an 176*ebfedea0SLionel Sambuc expected manner. The SASLprep preparation algorithm is not mandatory 177*ebfedea0SLionel Sambuc so as to allow the server to employ other preparation algorithms 178*ebfedea0SLionel Sambuc (including none) when appropriate. For instance, use of a different 179*ebfedea0SLionel Sambuc preparation algorithm may be necessary for the server to interoperate 180*ebfedea0SLionel Sambuc with an external system. 181*ebfedea0SLionel Sambuc 182*ebfedea0SLionel Sambuc When preparing the presented strings using [SASLPrep], the presented 183*ebfedea0SLionel Sambuc strings are to be treated as "query" strings (Section 7 of 184*ebfedea0SLionel Sambuc [StringPrep]) and hence unassigned code points are allowed to appear 185*ebfedea0SLionel Sambuc in their prepared output. When preparing the database strings using 186*ebfedea0SLionel Sambuc [SASLPrep], the database strings are to be treated as "stored" 187*ebfedea0SLionel Sambuc strings (Section 7 of [StringPrep]) and hence unassigned code points 188*ebfedea0SLionel Sambuc are prohibited from appearing in their prepared output. 189*ebfedea0SLionel Sambuc 190*ebfedea0SLionel Sambuc Regardless of the preparation algorithm used, if the output of a 191*ebfedea0SLionel Sambuc non-invertible function (e.g., hash) of the expected string is 192*ebfedea0SLionel Sambuc stored, the string MUST be prepared before input to that function. 193*ebfedea0SLionel Sambuc 194*ebfedea0SLionel Sambuc Regardless of the preparation algorithm used, if preparation fails or 195*ebfedea0SLionel Sambuc results in an empty string, verification SHALL fail. 196*ebfedea0SLionel Sambuc 197*ebfedea0SLionel Sambuc When no authorization identity is provided, the server derives an 198*ebfedea0SLionel Sambuc authorization identity from the prepared representation of the 199*ebfedea0SLionel Sambuc provided authentication identity string. This ensures that the 200*ebfedea0SLionel Sambuc derivation of different representations of the authentication 201*ebfedea0SLionel Sambuc identity produces the same authorization identity. 202*ebfedea0SLionel Sambuc 203*ebfedea0SLionel Sambuc The server MAY use the credentials to initialize any new 204*ebfedea0SLionel Sambuc authentication database, such as one suitable for [CRAM-MD5] or 205*ebfedea0SLionel Sambuc [DIGEST-MD5]. 206*ebfedea0SLionel Sambuc 207*ebfedea0SLionel Sambuc3. Pseudo-Code 208*ebfedea0SLionel Sambuc 209*ebfedea0SLionel Sambuc This section provides pseudo-code illustrating the verification 210*ebfedea0SLionel Sambuc process (using hashed passwords and the SASLprep preparation 211*ebfedea0SLionel Sambuc function) discussed above. This section is not definitive. 212*ebfedea0SLionel Sambuc 213*ebfedea0SLionel Sambuc boolean Verify(string authzid, string authcid, string passwd) { 214*ebfedea0SLionel Sambuc string pAuthcid = SASLprep(authcid, true); # prepare authcid 215*ebfedea0SLionel Sambuc string pPasswd = SASLprep(passwd, true); # prepare passwd 216*ebfedea0SLionel Sambuc if (pAuthcid == NULL || pPasswd == NULL) { 217*ebfedea0SLionel Sambuc return false; # preparation failed 218*ebfedea0SLionel Sambuc } 219*ebfedea0SLionel Sambuc if (pAuthcid == "" || pPasswd == "") { 220*ebfedea0SLionel Sambuc return false; # empty prepared string 221*ebfedea0SLionel Sambuc } 222*ebfedea0SLionel Sambuc 223*ebfedea0SLionel Sambuc 224*ebfedea0SLionel Sambuc 225*ebfedea0SLionel Sambuc 226*ebfedea0SLionel SambucZeilenga Standards Track [Page 4] 227*ebfedea0SLionel Sambuc 228*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 229*ebfedea0SLionel Sambuc 230*ebfedea0SLionel Sambuc 231*ebfedea0SLionel Sambuc storedHash = FetchPasswordHash(pAuthcid); 232*ebfedea0SLionel Sambuc if (storedHash == NULL || storedHash == "") { 233*ebfedea0SLionel Sambuc return false; # error or unknown authcid 234*ebfedea0SLionel Sambuc } 235*ebfedea0SLionel Sambuc 236*ebfedea0SLionel Sambuc if (!Compare(storedHash, Hash(pPasswd))) { 237*ebfedea0SLionel Sambuc return false; # incorrect password 238*ebfedea0SLionel Sambuc } 239*ebfedea0SLionel Sambuc 240*ebfedea0SLionel Sambuc if (authzid == NULL ) { 241*ebfedea0SLionel Sambuc authzid = DeriveAuthzid(pAuthcid); 242*ebfedea0SLionel Sambuc if (authzid == NULL || authzid == "") { 243*ebfedea0SLionel Sambuc return false; # could not derive authzid 244*ebfedea0SLionel Sambuc } 245*ebfedea0SLionel Sambuc } 246*ebfedea0SLionel Sambuc 247*ebfedea0SLionel Sambuc if (!Authorize(pAuthcid, authzid)) { 248*ebfedea0SLionel Sambuc return false; # not authorized 249*ebfedea0SLionel Sambuc } 250*ebfedea0SLionel Sambuc 251*ebfedea0SLionel Sambuc return true; 252*ebfedea0SLionel Sambuc } 253*ebfedea0SLionel Sambuc 254*ebfedea0SLionel Sambuc The second parameter of the SASLprep function, when true, indicates 255*ebfedea0SLionel Sambuc that unassigned code points are allowed in the input. When the 256*ebfedea0SLionel Sambuc SASLprep function is called to prepare the password prior to 257*ebfedea0SLionel Sambuc computing the stored hash, the second parameter would be false. 258*ebfedea0SLionel Sambuc 259*ebfedea0SLionel Sambuc The second parameter provided to the Authorize function is not 260*ebfedea0SLionel Sambuc prepared by this code. The application-level SASL profile should be 261*ebfedea0SLionel Sambuc consulted to determine what, if any, preparation is necessary. 262*ebfedea0SLionel Sambuc 263*ebfedea0SLionel Sambuc Note that the DeriveAuthzid and Authorize functions (whether 264*ebfedea0SLionel Sambuc implemented as one function or two, whether designed in a manner in 265*ebfedea0SLionel Sambuc which these functions or whether the mechanism implementation can be 266*ebfedea0SLionel Sambuc reused elsewhere) require knowledge and understanding of mechanism 267*ebfedea0SLionel Sambuc and the application-level protocol specification and/or 268*ebfedea0SLionel Sambuc implementation details to implement. 269*ebfedea0SLionel Sambuc 270*ebfedea0SLionel Sambuc Note that the Authorize function outcome is clearly dependent on 271*ebfedea0SLionel Sambuc details of the local authorization model and policy. Both functions 272*ebfedea0SLionel Sambuc may be dependent on other factors as well. 273*ebfedea0SLionel Sambuc 274*ebfedea0SLionel Sambuc 275*ebfedea0SLionel Sambuc 276*ebfedea0SLionel Sambuc 277*ebfedea0SLionel Sambuc 278*ebfedea0SLionel Sambuc 279*ebfedea0SLionel Sambuc 280*ebfedea0SLionel Sambuc 281*ebfedea0SLionel Sambuc 282*ebfedea0SLionel SambucZeilenga Standards Track [Page 5] 283*ebfedea0SLionel Sambuc 284*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 285*ebfedea0SLionel Sambuc 286*ebfedea0SLionel Sambuc 287*ebfedea0SLionel Sambuc4. Examples 288*ebfedea0SLionel Sambuc 289*ebfedea0SLionel Sambuc This section provides examples of PLAIN authentication exchanges. 290*ebfedea0SLionel Sambuc The examples are intended to help the readers understand the above 291*ebfedea0SLionel Sambuc text. The examples are not definitive. 292*ebfedea0SLionel Sambuc 293*ebfedea0SLionel Sambuc "C:" and "S:" indicate lines sent by the client and server, 294*ebfedea0SLionel Sambuc respectively. "<NUL>" represents a single NUL (U+0000) character. 295*ebfedea0SLionel Sambuc The Application Configuration Access Protocol ([ACAP]) is used in the 296*ebfedea0SLionel Sambuc examples. 297*ebfedea0SLionel Sambuc 298*ebfedea0SLionel Sambuc The first example shows how the PLAIN mechanism might be used for 299*ebfedea0SLionel Sambuc user authentication. 300*ebfedea0SLionel Sambuc 301*ebfedea0SLionel Sambuc S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 302*ebfedea0SLionel Sambuc C: a001 STARTTLS 303*ebfedea0SLionel Sambuc S: a001 OK "Begin TLS negotiation now" 304*ebfedea0SLionel Sambuc <TLS negotiation, further commands are under TLS layer> 305*ebfedea0SLionel Sambuc S: * ACAP (SASL "CRAM-MD5" "PLAIN") 306*ebfedea0SLionel Sambuc C: a002 AUTHENTICATE "PLAIN" 307*ebfedea0SLionel Sambuc S: + "" 308*ebfedea0SLionel Sambuc C: {21} 309*ebfedea0SLionel Sambuc C: <NUL>tim<NUL>tanstaaftanstaaf 310*ebfedea0SLionel Sambuc S: a002 OK "Authenticated" 311*ebfedea0SLionel Sambuc 312*ebfedea0SLionel Sambuc The second example shows how the PLAIN mechanism might be used to 313*ebfedea0SLionel Sambuc attempt to assume the identity of another user. In this example, the 314*ebfedea0SLionel Sambuc server rejects the request. Also, this example makes use of the 315*ebfedea0SLionel Sambuc protocol optional initial response capability to eliminate a round- 316*ebfedea0SLionel Sambuc trip. 317*ebfedea0SLionel Sambuc 318*ebfedea0SLionel Sambuc S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 319*ebfedea0SLionel Sambuc C: a001 STARTTLS 320*ebfedea0SLionel Sambuc S: a001 OK "Begin TLS negotiation now" 321*ebfedea0SLionel Sambuc <TLS negotiation, further commands are under TLS layer> 322*ebfedea0SLionel Sambuc S: * ACAP (SASL "CRAM-MD5" "PLAIN") 323*ebfedea0SLionel Sambuc C: a002 AUTHENTICATE "PLAIN" {20+} 324*ebfedea0SLionel Sambuc C: Ursel<NUL>Kurt<NUL>xipj3plmq 325*ebfedea0SLionel Sambuc S: a002 NO "Not authorized to requested authorization identity" 326*ebfedea0SLionel Sambuc 327*ebfedea0SLionel Sambuc5. Security Considerations 328*ebfedea0SLionel Sambuc 329*ebfedea0SLionel Sambuc As the PLAIN mechanism itself provided no integrity or 330*ebfedea0SLionel Sambuc confidentiality protections, it should not be used without adequate 331*ebfedea0SLionel Sambuc external data security protection, such as TLS services provided by 332*ebfedea0SLionel Sambuc many application-layer protocols. By default, implementations SHOULD 333*ebfedea0SLionel Sambuc NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless 334*ebfedea0SLionel Sambuc adequate data security services are in place. 335*ebfedea0SLionel Sambuc 336*ebfedea0SLionel Sambuc 337*ebfedea0SLionel Sambuc 338*ebfedea0SLionel SambucZeilenga Standards Track [Page 6] 339*ebfedea0SLionel Sambuc 340*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 341*ebfedea0SLionel Sambuc 342*ebfedea0SLionel Sambuc 343*ebfedea0SLionel Sambuc When the PLAIN mechanism is used, the server gains the ability to 344*ebfedea0SLionel Sambuc impersonate the user to all services with the same password 345*ebfedea0SLionel Sambuc regardless of any encryption provided by TLS or other confidentiality 346*ebfedea0SLionel Sambuc protection mechanisms. Whereas many other authentication mechanisms 347*ebfedea0SLionel Sambuc have similar weaknesses, stronger SASL mechanisms address this issue. 348*ebfedea0SLionel Sambuc Clients are encouraged to have an operational mode where all 349*ebfedea0SLionel Sambuc mechanisms that are likely to reveal the user's password to the 350*ebfedea0SLionel Sambuc server are disabled. 351*ebfedea0SLionel Sambuc 352*ebfedea0SLionel Sambuc General [SASL] security considerations apply to this mechanism. 353*ebfedea0SLionel Sambuc 354*ebfedea0SLionel Sambuc Unicode, [UTF-8], and [StringPrep] security considerations also 355*ebfedea0SLionel Sambuc apply. 356*ebfedea0SLionel Sambuc 357*ebfedea0SLionel Sambuc6. IANA Considerations 358*ebfedea0SLionel Sambuc 359*ebfedea0SLionel Sambuc The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism 360*ebfedea0SLionel Sambuc has been updated by the IANA to reflect that this document now 361*ebfedea0SLionel Sambuc provides its technical specification. 362*ebfedea0SLionel Sambuc 363*ebfedea0SLionel Sambuc To: iana@iana.org 364*ebfedea0SLionel Sambuc Subject: Updated Registration of SASL mechanism PLAIN 365*ebfedea0SLionel Sambuc 366*ebfedea0SLionel Sambuc SASL mechanism name: PLAIN 367*ebfedea0SLionel Sambuc Security considerations: See RFC 4616. 368*ebfedea0SLionel Sambuc Published specification (optional, recommended): RFC 4616 369*ebfedea0SLionel Sambuc Person & email address to contact for further information: 370*ebfedea0SLionel Sambuc Kurt Zeilenga <kurt@openldap.org> 371*ebfedea0SLionel Sambuc IETF SASL WG <ietf-sasl@imc.org> 372*ebfedea0SLionel Sambuc Intended usage: COMMON 373*ebfedea0SLionel Sambuc Author/Change controller: IESG <iesg@ietf.org> 374*ebfedea0SLionel Sambuc Note: Updates existing entry for PLAIN 375*ebfedea0SLionel Sambuc 376*ebfedea0SLionel Sambuc7. Acknowledgements 377*ebfedea0SLionel Sambuc 378*ebfedea0SLionel Sambuc This document is a revision of RFC 2595 by Chris Newman. Portions of 379*ebfedea0SLionel Sambuc the grammar defined in Section 2 were borrowed from [UTF-8] by 380*ebfedea0SLionel Sambuc Francois Yergeau. 381*ebfedea0SLionel Sambuc 382*ebfedea0SLionel Sambuc This document is a product of the IETF Simple Authentication and 383*ebfedea0SLionel Sambuc Security Layer (SASL) Working Group. 384*ebfedea0SLionel Sambuc 385*ebfedea0SLionel Sambuc 386*ebfedea0SLionel Sambuc 387*ebfedea0SLionel Sambuc 388*ebfedea0SLionel Sambuc 389*ebfedea0SLionel Sambuc 390*ebfedea0SLionel Sambuc 391*ebfedea0SLionel Sambuc 392*ebfedea0SLionel Sambuc 393*ebfedea0SLionel Sambuc 394*ebfedea0SLionel SambucZeilenga Standards Track [Page 7] 395*ebfedea0SLionel Sambuc 396*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 397*ebfedea0SLionel Sambuc 398*ebfedea0SLionel Sambuc 399*ebfedea0SLionel Sambuc8. Normative References 400*ebfedea0SLionel Sambuc 401*ebfedea0SLionel Sambuc [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for 402*ebfedea0SLionel Sambuc Syntax Specifications: ABNF", RFC 4234, October 2005. 403*ebfedea0SLionel Sambuc 404*ebfedea0SLionel Sambuc [Keywords] Bradner, S., "Key words for use in RFCs to Indicate 405*ebfedea0SLionel Sambuc Requirement Levels", BCP 14, RFC 2119, March 1997. 406*ebfedea0SLionel Sambuc 407*ebfedea0SLionel Sambuc [SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple 408*ebfedea0SLionel Sambuc Authentication and Security Layer (SASL)", RFC 4422, 409*ebfedea0SLionel Sambuc June 2006. 410*ebfedea0SLionel Sambuc 411*ebfedea0SLionel Sambuc [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User 412*ebfedea0SLionel Sambuc Names and Passwords", RFC 4013, February 2005. 413*ebfedea0SLionel Sambuc 414*ebfedea0SLionel Sambuc [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 415*ebfedea0SLionel Sambuc Internationalized Strings ("stringprep")", RFC 3454, 416*ebfedea0SLionel Sambuc December 2002. 417*ebfedea0SLionel Sambuc 418*ebfedea0SLionel Sambuc [Unicode] The Unicode Consortium, "The Unicode Standard, Version 419*ebfedea0SLionel Sambuc 3.2.0" is defined by "The Unicode Standard, Version 420*ebfedea0SLionel Sambuc 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 421*ebfedea0SLionel Sambuc 61633-5), as amended by the "Unicode Standard Annex 422*ebfedea0SLionel Sambuc #27: Unicode 3.1" 423*ebfedea0SLionel Sambuc (http://www.unicode.org/reports/tr27/) and by the 424*ebfedea0SLionel Sambuc "Unicode Standard Annex #28: Unicode 3.2" 425*ebfedea0SLionel Sambuc (http://www.unicode.org/reports/tr28/). 426*ebfedea0SLionel Sambuc 427*ebfedea0SLionel Sambuc [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 428*ebfedea0SLionel Sambuc 10646", STD 63, RFC 3629, November 2003. 429*ebfedea0SLionel Sambuc 430*ebfedea0SLionel Sambuc [TLS] Dierks, T. and E. Rescorla, "The Transport Layer 431*ebfedea0SLionel Sambuc Security (TLS) Protocol Version 1.1", RFC 4346, April 432*ebfedea0SLionel Sambuc 2006. 433*ebfedea0SLionel Sambuc 434*ebfedea0SLionel Sambuc9. Informative References 435*ebfedea0SLionel Sambuc 436*ebfedea0SLionel Sambuc [ACAP] Newman, C. and J. Myers, "ACAP -- Application 437*ebfedea0SLionel Sambuc Configuration Access Protocol", RFC 2244, November 438*ebfedea0SLionel Sambuc 1997. 439*ebfedea0SLionel Sambuc 440*ebfedea0SLionel Sambuc [CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work 441*ebfedea0SLionel Sambuc in Progress, June 2006. 442*ebfedea0SLionel Sambuc 443*ebfedea0SLionel Sambuc [DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a 444*ebfedea0SLionel Sambuc SASL Mechanism", Work in Progress, June 2006. 445*ebfedea0SLionel Sambuc 446*ebfedea0SLionel Sambuc 447*ebfedea0SLionel Sambuc 448*ebfedea0SLionel Sambuc 449*ebfedea0SLionel Sambuc 450*ebfedea0SLionel SambucZeilenga Standards Track [Page 8] 451*ebfedea0SLionel Sambuc 452*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 453*ebfedea0SLionel Sambuc 454*ebfedea0SLionel Sambuc 455*ebfedea0SLionel Sambuc [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 456*ebfedea0SLionel Sambuc MECHANISMS", 457*ebfedea0SLionel Sambuc <http://www.iana.org/assignments/sasl-mechanisms>. 458*ebfedea0SLionel Sambuc 459*ebfedea0SLionel Sambuc [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 460*ebfedea0SLionel Sambuc RFC 2554, March 1999. 461*ebfedea0SLionel Sambuc 462*ebfedea0SLionel Sambuc 463*ebfedea0SLionel Sambuc 464*ebfedea0SLionel Sambuc 465*ebfedea0SLionel Sambuc 466*ebfedea0SLionel Sambuc 467*ebfedea0SLionel Sambuc 468*ebfedea0SLionel Sambuc 469*ebfedea0SLionel Sambuc 470*ebfedea0SLionel Sambuc 471*ebfedea0SLionel Sambuc 472*ebfedea0SLionel Sambuc 473*ebfedea0SLionel Sambuc 474*ebfedea0SLionel Sambuc 475*ebfedea0SLionel Sambuc 476*ebfedea0SLionel Sambuc 477*ebfedea0SLionel Sambuc 478*ebfedea0SLionel Sambuc 479*ebfedea0SLionel Sambuc 480*ebfedea0SLionel Sambuc 481*ebfedea0SLionel Sambuc 482*ebfedea0SLionel Sambuc 483*ebfedea0SLionel Sambuc 484*ebfedea0SLionel Sambuc 485*ebfedea0SLionel Sambuc 486*ebfedea0SLionel Sambuc 487*ebfedea0SLionel Sambuc 488*ebfedea0SLionel Sambuc 489*ebfedea0SLionel Sambuc 490*ebfedea0SLionel Sambuc 491*ebfedea0SLionel Sambuc 492*ebfedea0SLionel Sambuc 493*ebfedea0SLionel Sambuc 494*ebfedea0SLionel Sambuc 495*ebfedea0SLionel Sambuc 496*ebfedea0SLionel Sambuc 497*ebfedea0SLionel Sambuc 498*ebfedea0SLionel Sambuc 499*ebfedea0SLionel Sambuc 500*ebfedea0SLionel Sambuc 501*ebfedea0SLionel Sambuc 502*ebfedea0SLionel Sambuc 503*ebfedea0SLionel Sambuc 504*ebfedea0SLionel Sambuc 505*ebfedea0SLionel Sambuc 506*ebfedea0SLionel SambucZeilenga Standards Track [Page 9] 507*ebfedea0SLionel Sambuc 508*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 509*ebfedea0SLionel Sambuc 510*ebfedea0SLionel Sambuc 511*ebfedea0SLionel SambucAppendix A. Changes since RFC 2595 512*ebfedea0SLionel Sambuc 513*ebfedea0SLionel Sambuc This appendix is non-normative. 514*ebfedea0SLionel Sambuc 515*ebfedea0SLionel Sambuc This document replaces Section 6 of RFC 2595. 516*ebfedea0SLionel Sambuc 517*ebfedea0SLionel Sambuc The specification details how the server is to compare client- 518*ebfedea0SLionel Sambuc provided character strings with stored character strings. 519*ebfedea0SLionel Sambuc 520*ebfedea0SLionel Sambuc The ABNF grammar was updated. In particular, the grammar now allows 521*ebfedea0SLionel Sambuc LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the 522*ebfedea0SLionel Sambuc authzid, authcid, passwd productions. However, whether these control 523*ebfedea0SLionel Sambuc characters may be used depends on the string preparation rules 524*ebfedea0SLionel Sambuc applicable to the production. For passwd and authcid productions, 525*ebfedea0SLionel Sambuc control characters are prohibited. For authzid, one must consult the 526*ebfedea0SLionel Sambuc application-level SASL profile. This change allows PLAIN to carry 527*ebfedea0SLionel Sambuc all possible authorization identity strings allowed in SASL. 528*ebfedea0SLionel Sambuc 529*ebfedea0SLionel Sambuc Pseudo-code was added. 530*ebfedea0SLionel Sambuc 531*ebfedea0SLionel Sambuc The example section was expanded to illustrate more features of the 532*ebfedea0SLionel Sambuc PLAIN mechanism. 533*ebfedea0SLionel Sambuc 534*ebfedea0SLionel SambucEditor's Address 535*ebfedea0SLionel Sambuc 536*ebfedea0SLionel Sambuc Kurt D. Zeilenga 537*ebfedea0SLionel Sambuc OpenLDAP Foundation 538*ebfedea0SLionel Sambuc 539*ebfedea0SLionel Sambuc EMail: Kurt@OpenLDAP.org 540*ebfedea0SLionel Sambuc 541*ebfedea0SLionel Sambuc 542*ebfedea0SLionel Sambuc 543*ebfedea0SLionel Sambuc 544*ebfedea0SLionel Sambuc 545*ebfedea0SLionel Sambuc 546*ebfedea0SLionel Sambuc 547*ebfedea0SLionel Sambuc 548*ebfedea0SLionel Sambuc 549*ebfedea0SLionel Sambuc 550*ebfedea0SLionel Sambuc 551*ebfedea0SLionel Sambuc 552*ebfedea0SLionel Sambuc 553*ebfedea0SLionel Sambuc 554*ebfedea0SLionel Sambuc 555*ebfedea0SLionel Sambuc 556*ebfedea0SLionel Sambuc 557*ebfedea0SLionel Sambuc 558*ebfedea0SLionel Sambuc 559*ebfedea0SLionel Sambuc 560*ebfedea0SLionel Sambuc 561*ebfedea0SLionel Sambuc 562*ebfedea0SLionel SambucZeilenga Standards Track [Page 10] 563*ebfedea0SLionel Sambuc 564*ebfedea0SLionel SambucRFC 4616 The PLAIN SASL Mechanism August 2006 565*ebfedea0SLionel Sambuc 566*ebfedea0SLionel Sambuc 567*ebfedea0SLionel SambucFull Copyright Statement 568*ebfedea0SLionel Sambuc 569*ebfedea0SLionel Sambuc Copyright (C) The Internet Society (2006). 570*ebfedea0SLionel Sambuc 571*ebfedea0SLionel Sambuc This document is subject to the rights, licenses and restrictions 572*ebfedea0SLionel Sambuc contained in BCP 78, and except as set forth therein, the authors 573*ebfedea0SLionel Sambuc retain all their rights. 574*ebfedea0SLionel Sambuc 575*ebfedea0SLionel Sambuc This document and the information contained herein are provided on an 576*ebfedea0SLionel Sambuc "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577*ebfedea0SLionel Sambuc OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 578*ebfedea0SLionel Sambuc ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 579*ebfedea0SLionel Sambuc INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 580*ebfedea0SLionel Sambuc INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581*ebfedea0SLionel Sambuc WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 582*ebfedea0SLionel Sambuc 583*ebfedea0SLionel SambucIntellectual Property 584*ebfedea0SLionel Sambuc 585*ebfedea0SLionel Sambuc The IETF takes no position regarding the validity or scope of any 586*ebfedea0SLionel Sambuc Intellectual Property Rights or other rights that might be claimed to 587*ebfedea0SLionel Sambuc pertain to the implementation or use of the technology described in 588*ebfedea0SLionel Sambuc this document or the extent to which any license under such rights 589*ebfedea0SLionel Sambuc might or might not be available; nor does it represent that it has 590*ebfedea0SLionel Sambuc made any independent effort to identify any such rights. Information 591*ebfedea0SLionel Sambuc on the procedures with respect to rights in RFC documents can be 592*ebfedea0SLionel Sambuc found in BCP 78 and BCP 79. 593*ebfedea0SLionel Sambuc 594*ebfedea0SLionel Sambuc Copies of IPR disclosures made to the IETF Secretariat and any 595*ebfedea0SLionel Sambuc assurances of licenses to be made available, or the result of an 596*ebfedea0SLionel Sambuc attempt made to obtain a general license or permission for the use of 597*ebfedea0SLionel Sambuc such proprietary rights by implementers or users of this 598*ebfedea0SLionel Sambuc specification can be obtained from the IETF on-line IPR repository at 599*ebfedea0SLionel Sambuc http://www.ietf.org/ipr. 600*ebfedea0SLionel Sambuc 601*ebfedea0SLionel Sambuc The IETF invites any interested party to bring to its attention any 602*ebfedea0SLionel Sambuc copyrights, patents or patent applications, or other proprietary 603*ebfedea0SLionel Sambuc rights that may cover technology that may be required to implement 604*ebfedea0SLionel Sambuc this standard. Please address the information to the IETF at 605*ebfedea0SLionel Sambuc ietf-ipr@ietf.org. 606*ebfedea0SLionel Sambuc 607*ebfedea0SLionel SambucAcknowledgement 608*ebfedea0SLionel Sambuc 609*ebfedea0SLionel Sambuc Funding for the RFC Editor function is provided by the IETF 610*ebfedea0SLionel Sambuc Administrative Support Activity (IASA). 611*ebfedea0SLionel Sambuc 612*ebfedea0SLionel Sambuc 613*ebfedea0SLionel Sambuc 614*ebfedea0SLionel Sambuc 615*ebfedea0SLionel Sambuc 616*ebfedea0SLionel Sambuc 617*ebfedea0SLionel Sambuc 618*ebfedea0SLionel SambucZeilenga Standards Track [Page 11] 619*ebfedea0SLionel Sambuc 620