imapext-2007

annotate docs/rfc/rfc4616.txt @ 0:ada5e610ab86

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

UW-IMAP'd extensions by yuuji