1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4616.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,619 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                   K. Zeilenga, Ed.
    1.11 +Request for Comments: 4616                           OpenLDAP Foundation
    1.12 +Updates: 2595                                                August 2006
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +  The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
    1.17 +
    1.18 +Status of This Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2006).
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   This document defines a simple clear-text user/password Simple
    1.33 +   Authentication and Security Layer (SASL) mechanism called the PLAIN
    1.34 +   mechanism.  The PLAIN mechanism is intended to be used, in
    1.35 +   combination with data confidentiality services provided by a lower
    1.36 +   layer, in protocols that lack a simple password authentication
    1.37 +   command.
    1.38 +
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Zeilenga                    Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4616                The PLAIN SASL Mechanism             August 2006
    1.64 +
    1.65 +
    1.66 +1.  Introduction
    1.67 +
    1.68 +   Clear-text, multiple-use passwords are simple, interoperate with
    1.69 +   almost all existing operating system authentication databases, and
    1.70 +   are useful for a smooth transition to a more secure password-based
    1.71 +   authentication mechanism.  The drawback is that they are unacceptable
    1.72 +   for use over network connections where data confidentiality is not
    1.73 +   ensured.
    1.74 +
    1.75 +   This document defines the PLAIN Simple Authentication and Security
    1.76 +   Layer ([SASL]) mechanism for use in protocols with no clear-text
    1.77 +   login command (e.g., [ACAP] or [SMTP-AUTH]).  This document updates
    1.78 +   RFC 2595, replacing Section 6.  Changes since RFC 2595 are detailed
    1.79 +   in Appendix A.
    1.80 +
    1.81 +   The name associated with this mechanism is "PLAIN".
    1.82 +
    1.83 +   The PLAIN SASL mechanism does not provide a security layer.
    1.84 +
    1.85 +   The PLAIN mechanism should not be used without adequate data security
    1.86 +   protection as this mechanism affords no integrity or confidentiality
    1.87 +   protections itself.  The mechanism is intended to be used with data
    1.88 +   security protections provided by application-layer protocol,
    1.89 +   generally through its use of Transport Layer Security ([TLS])
    1.90 +   services.
    1.91 +
    1.92 +   By default, implementations SHOULD advertise and make use of the
    1.93 +   PLAIN mechanism only when adequate data security services are in
    1.94 +   place.  Specifications for IETF protocols that indicate that this
    1.95 +   mechanism is an applicable authentication mechanism MUST mandate that
    1.96 +   implementations support an strong data security service, such as TLS.
    1.97 +
    1.98 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.99 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   1.100 +   document are to be interpreted as described in [Keywords].
   1.101 +
   1.102 +2.  PLAIN SASL Mechanism
   1.103 +
   1.104 +   The mechanism consists of a single message, a string of [UTF-8]
   1.105 +   encoded [Unicode] characters, from the client to the server.  The
   1.106 +   client presents the authorization identity (identity to act as),
   1.107 +   followed by a NUL (U+0000) character, followed by the authentication
   1.108 +   identity (identity whose password will be used), followed by a NUL
   1.109 +   (U+0000) character, followed by the clear-text password.  As with
   1.110 +   other SASL mechanisms, the client does not provide an authorization
   1.111 +   identity when it wishes the server to derive an identity from the
   1.112 +   credentials and use that as the authorization identity.
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Zeilenga                    Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.120 +
   1.121 +
   1.122 +   The formal grammar for the client message using Augmented BNF [ABNF]
   1.123 +   follows.
   1.124 +
   1.125 +   message   = [authzid] UTF8NUL authcid UTF8NUL passwd
   1.126 +   authcid   = 1*SAFE ; MUST accept up to 255 octets
   1.127 +   authzid   = 1*SAFE ; MUST accept up to 255 octets
   1.128 +   passwd    = 1*SAFE ; MUST accept up to 255 octets
   1.129 +   UTF8NUL   = %x00 ; UTF-8 encoded NUL character
   1.130 +
   1.131 +   SAFE      = UTF1 / UTF2 / UTF3 / UTF4
   1.132 +               ;; any UTF-8 encoded Unicode character except NUL
   1.133 +
   1.134 +   UTF1      = %x01-7F ;; except NUL
   1.135 +   UTF2      = %xC2-DF UTF0
   1.136 +   UTF3      = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
   1.137 +               %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
   1.138 +   UTF4      = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
   1.139 +               %xF4 %x80-8F 2(UTF0)
   1.140 +   UTF0      = %x80-BF
   1.141 +
   1.142 +   The authorization identity (authzid), authentication identity
   1.143 +   (authcid), password (passwd), and NUL character deliminators SHALL be
   1.144 +   transferred as [UTF-8] encoded strings of [Unicode] characters.  As
   1.145 +   the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
   1.146 +   character MUST NOT appear in authzid, authcid, or passwd productions.
   1.147 +
   1.148 +   The form of the authzid production is specific to the application-
   1.149 +   level protocol's SASL profile [SASL].  The authcid and passwd
   1.150 +   productions are form-free.  Use of non-visible characters or
   1.151 +   characters that a user may be unable to enter on some keyboards is
   1.152 +   discouraged.
   1.153 +
   1.154 +   Servers MUST be capable of accepting authzid, authcid, and passwd
   1.155 +   productions up to and including 255 octets.  It is noted that the
   1.156 +   UTF-8 encoding of a Unicode character may be as long as 4 octets.
   1.157 +
   1.158 +   Upon receipt of the message, the server will verify the presented (in
   1.159 +   the message) authentication identity (authcid) and password (passwd)
   1.160 +   with the system authentication database, and it will verify that the
   1.161 +   authentication credentials permit the client to act as the (presented
   1.162 +   or derived) authorization identity (authzid).  If both steps succeed,
   1.163 +   the user is authenticated.
   1.164 +
   1.165 +   The presented authentication identity and password strings, as well
   1.166 +   as the database authentication identity and password strings, are to
   1.167 +   be prepared before being used in the verification process.  The
   1.168 +   [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
   1.169 +   preparation algorithm.  The SASLprep preparation algorithm is
   1.170 +
   1.171 +
   1.172 +
   1.173 +Zeilenga                    Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.176 +
   1.177 +
   1.178 +   recommended to improve the likelihood that comparisons behave in an
   1.179 +   expected manner.  The SASLprep preparation algorithm is not mandatory
   1.180 +   so as to allow the server to employ other preparation algorithms
   1.181 +   (including none) when appropriate.  For instance, use of a different
   1.182 +   preparation algorithm may be necessary for the server to interoperate
   1.183 +   with an external system.
   1.184 +
   1.185 +   When preparing the presented strings using [SASLPrep], the presented
   1.186 +   strings are to be treated as "query" strings (Section 7 of
   1.187 +   [StringPrep]) and hence unassigned code points are allowed to appear
   1.188 +   in their prepared output.  When preparing the database strings using
   1.189 +   [SASLPrep], the database strings are to be treated as "stored"
   1.190 +   strings (Section 7 of [StringPrep]) and hence unassigned code points
   1.191 +   are prohibited from appearing in their prepared output.
   1.192 +
   1.193 +   Regardless of the preparation algorithm used, if the output of a
   1.194 +   non-invertible function (e.g., hash) of the expected string is
   1.195 +   stored, the string MUST be prepared before input to that function.
   1.196 +
   1.197 +   Regardless of the preparation algorithm used, if preparation fails or
   1.198 +   results in an empty string, verification SHALL fail.
   1.199 +
   1.200 +   When no authorization identity is provided, the server derives an
   1.201 +   authorization identity from the prepared representation of the
   1.202 +   provided authentication identity string.  This ensures that the
   1.203 +   derivation of different representations of the authentication
   1.204 +   identity produces the same authorization identity.
   1.205 +
   1.206 +   The server MAY use the credentials to initialize any new
   1.207 +   authentication database, such as one suitable for [CRAM-MD5] or
   1.208 +   [DIGEST-MD5].
   1.209 +
   1.210 +3.  Pseudo-Code
   1.211 +
   1.212 +   This section provides pseudo-code illustrating the verification
   1.213 +   process (using hashed passwords and the SASLprep preparation
   1.214 +   function) discussed above.  This section is not definitive.
   1.215 +
   1.216 +   boolean Verify(string authzid, string authcid, string passwd) {
   1.217 +     string pAuthcid = SASLprep(authcid, true); # prepare authcid
   1.218 +     string pPasswd = SASLprep(passwd, true);   # prepare passwd
   1.219 +     if (pAuthcid == NULL || pPasswd == NULL) {
   1.220 +       return false;     # preparation failed
   1.221 +     }
   1.222 +     if (pAuthcid == "" || pPasswd == "") {
   1.223 +       return false;     # empty prepared string
   1.224 +     }
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Zeilenga                    Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.232 +
   1.233 +
   1.234 +     storedHash = FetchPasswordHash(pAuthcid);
   1.235 +     if (storedHash == NULL || storedHash == "") {
   1.236 +       return false;     # error or unknown authcid
   1.237 +     }
   1.238 +
   1.239 +     if (!Compare(storedHash, Hash(pPasswd))) {
   1.240 +       return false;     # incorrect password
   1.241 +     }
   1.242 +
   1.243 +     if (authzid == NULL ) {
   1.244 +       authzid = DeriveAuthzid(pAuthcid);
   1.245 +       if (authzid == NULL || authzid == "") {
   1.246 +           return false; # could not derive authzid
   1.247 +       }
   1.248 +     }
   1.249 +
   1.250 +     if (!Authorize(pAuthcid, authzid)) {
   1.251 +       return false;     # not authorized
   1.252 +     }
   1.253 +
   1.254 +     return true;
   1.255 +   }
   1.256 +
   1.257 +   The second parameter of the SASLprep function, when true, indicates
   1.258 +   that unassigned code points are allowed in the input.  When the
   1.259 +   SASLprep function is called to prepare the password prior to
   1.260 +   computing the stored hash, the second parameter would be false.
   1.261 +
   1.262 +   The second parameter provided to the Authorize function is not
   1.263 +   prepared by this code.  The application-level SASL profile should be
   1.264 +   consulted to determine what, if any, preparation is necessary.
   1.265 +
   1.266 +   Note that the DeriveAuthzid and Authorize functions (whether
   1.267 +   implemented as one function or two, whether designed in a manner in
   1.268 +   which these functions or whether the mechanism implementation can be
   1.269 +   reused elsewhere) require knowledge and understanding of mechanism
   1.270 +   and the application-level protocol specification and/or
   1.271 +   implementation details to implement.
   1.272 +
   1.273 +   Note that the Authorize function outcome is clearly dependent on
   1.274 +   details of the local authorization model and policy.  Both functions
   1.275 +   may be dependent on other factors as well.
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Zeilenga                    Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.288 +
   1.289 +
   1.290 +4.  Examples
   1.291 +
   1.292 +   This section provides examples of PLAIN authentication exchanges.
   1.293 +   The examples are intended to help the readers understand the above
   1.294 +   text.  The examples are not definitive.
   1.295 +
   1.296 +   "C:" and "S:" indicate lines sent by the client and server,
   1.297 +   respectively.  "<NUL>" represents a single NUL (U+0000) character.
   1.298 +   The Application Configuration Access Protocol ([ACAP]) is used in the
   1.299 +   examples.
   1.300 +
   1.301 +   The first example shows how the PLAIN mechanism might be used for
   1.302 +   user authentication.
   1.303 +
   1.304 +   S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
   1.305 +   C: a001 STARTTLS
   1.306 +   S: a001 OK "Begin TLS negotiation now"
   1.307 +   <TLS negotiation, further commands are under TLS layer>
   1.308 +   S: * ACAP (SASL "CRAM-MD5" "PLAIN")
   1.309 +   C: a002 AUTHENTICATE "PLAIN"
   1.310 +   S: + ""
   1.311 +   C: {21}
   1.312 +   C: <NUL>tim<NUL>tanstaaftanstaaf
   1.313 +   S: a002 OK "Authenticated"
   1.314 +
   1.315 +   The second example shows how the PLAIN mechanism might be used to
   1.316 +   attempt to assume the identity of another user.  In this example, the
   1.317 +   server rejects the request.  Also, this example makes use of the
   1.318 +   protocol optional initial response capability to eliminate a round-
   1.319 +   trip.
   1.320 +
   1.321 +   S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
   1.322 +   C: a001 STARTTLS
   1.323 +   S: a001 OK "Begin TLS negotiation now"
   1.324 +   <TLS negotiation, further commands are under TLS layer>
   1.325 +   S: * ACAP (SASL "CRAM-MD5" "PLAIN")
   1.326 +   C: a002 AUTHENTICATE "PLAIN" {20+}
   1.327 +   C: Ursel<NUL>Kurt<NUL>xipj3plmq
   1.328 +   S: a002 NO "Not authorized to requested authorization identity"
   1.329 +
   1.330 +5.  Security Considerations
   1.331 +
   1.332 +   As the PLAIN mechanism itself provided no integrity or
   1.333 +   confidentiality protections, it should not be used without adequate
   1.334 +   external data security protection, such as TLS services provided by
   1.335 +   many application-layer protocols.  By default, implementations SHOULD
   1.336 +   NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
   1.337 +   adequate data security services are in place.
   1.338 +
   1.339 +
   1.340 +
   1.341 +Zeilenga                    Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.344 +
   1.345 +
   1.346 +   When the PLAIN mechanism is used, the server gains the ability to
   1.347 +   impersonate the user to all services with the same password
   1.348 +   regardless of any encryption provided by TLS or other confidentiality
   1.349 +   protection mechanisms.  Whereas many other authentication mechanisms
   1.350 +   have similar weaknesses, stronger SASL mechanisms address this issue.
   1.351 +   Clients are encouraged to have an operational mode where all
   1.352 +   mechanisms that are likely to reveal the user's password to the
   1.353 +   server are disabled.
   1.354 +
   1.355 +   General [SASL] security considerations apply to this mechanism.
   1.356 +
   1.357 +   Unicode, [UTF-8], and [StringPrep] security considerations also
   1.358 +   apply.
   1.359 +
   1.360 +6.  IANA Considerations
   1.361 +
   1.362 +   The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism
   1.363 +   has been updated by the IANA to reflect that this document now
   1.364 +   provides its technical specification.
   1.365 +
   1.366 +   To: iana@iana.org
   1.367 +   Subject: Updated Registration of SASL mechanism PLAIN
   1.368 +
   1.369 +   SASL mechanism name: PLAIN
   1.370 +   Security considerations: See RFC 4616.
   1.371 +   Published specification (optional, recommended): RFC 4616
   1.372 +   Person & email address to contact for further information:
   1.373 +        Kurt Zeilenga <kurt@openldap.org>
   1.374 +        IETF SASL WG <ietf-sasl@imc.org>
   1.375 +   Intended usage: COMMON
   1.376 +   Author/Change controller: IESG <iesg@ietf.org>
   1.377 +   Note: Updates existing entry for PLAIN
   1.378 +
   1.379 +7.  Acknowledgements
   1.380 +
   1.381 +   This document is a revision of RFC 2595 by Chris Newman.  Portions of
   1.382 +   the grammar defined in Section 2 were borrowed from [UTF-8] by
   1.383 +   Francois Yergeau.
   1.384 +
   1.385 +   This document is a product of the IETF Simple Authentication and
   1.386 +   Security Layer (SASL) Working Group.
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Zeilenga                    Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.400 +
   1.401 +
   1.402 +8.  Normative References
   1.403 +
   1.404 +   [ABNF]        Crocker, D., Ed. and P. Overell, "Augmented BNF for
   1.405 +                 Syntax Specifications: ABNF", RFC 4234, October 2005.
   1.406 +
   1.407 +   [Keywords]    Bradner, S., "Key words for use in RFCs to Indicate
   1.408 +                 Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.409 +
   1.410 +   [SASL]        Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
   1.411 +                 Authentication and Security Layer (SASL)", RFC 4422,
   1.412 +                 June 2006.
   1.413 +
   1.414 +   [SASLPrep]    Zeilenga, K., "SASLprep: Stringprep Profile for User
   1.415 +                 Names and Passwords", RFC 4013, February 2005.
   1.416 +
   1.417 +   [StringPrep]  Hoffman, P. and M. Blanchet, "Preparation of
   1.418 +                 Internationalized Strings ("stringprep")", RFC 3454,
   1.419 +                 December 2002.
   1.420 +
   1.421 +   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
   1.422 +                 3.2.0" is defined by "The Unicode Standard, Version
   1.423 +                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
   1.424 +                 61633-5), as amended by the "Unicode Standard Annex
   1.425 +                 #27: Unicode 3.1"
   1.426 +                 (http://www.unicode.org/reports/tr27/) and by the
   1.427 +                 "Unicode Standard Annex #28: Unicode 3.2"
   1.428 +                 (http://www.unicode.org/reports/tr28/).
   1.429 +
   1.430 +   [UTF-8]       Yergeau, F., "UTF-8, a transformation format of ISO
   1.431 +                 10646", STD 63, RFC 3629, November 2003.
   1.432 +
   1.433 +   [TLS]         Dierks, T. and E. Rescorla, "The Transport Layer
   1.434 +                 Security (TLS) Protocol Version 1.1", RFC 4346, April
   1.435 +                 2006.
   1.436 +
   1.437 +9.  Informative References
   1.438 +
   1.439 +   [ACAP]        Newman, C. and J. Myers, "ACAP -- Application
   1.440 +                 Configuration Access Protocol", RFC 2244, November
   1.441 +                 1997.
   1.442 +
   1.443 +   [CRAM-MD5]    Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work
   1.444 +                 in Progress, June 2006.
   1.445 +
   1.446 +   [DIGEST-MD5]  Melnikov, A., Ed., "Using Digest Authentication as a
   1.447 +                 SASL Mechanism", Work in Progress, June 2006.
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Zeilenga                    Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.456 +
   1.457 +
   1.458 +   [IANA-SASL]   IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
   1.459 +                 MECHANISMS",
   1.460 +                 <http://www.iana.org/assignments/sasl-mechanisms>.
   1.461 +
   1.462 +   [SMTP-AUTH]   Myers, J., "SMTP Service Extension for Authentication",
   1.463 +                 RFC 2554, March 1999.
   1.464 +
   1.465 +
   1.466 +
   1.467 +
   1.468 +
   1.469 +
   1.470 +
   1.471 +
   1.472 +
   1.473 +
   1.474 +
   1.475 +
   1.476 +
   1.477 +
   1.478 +
   1.479 +
   1.480 +
   1.481 +
   1.482 +
   1.483 +
   1.484 +
   1.485 +
   1.486 +
   1.487 +
   1.488 +
   1.489 +
   1.490 +
   1.491 +
   1.492 +
   1.493 +
   1.494 +
   1.495 +
   1.496 +
   1.497 +
   1.498 +
   1.499 +
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Zeilenga                    Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.512 +
   1.513 +
   1.514 +Appendix A.  Changes since RFC 2595
   1.515 +
   1.516 +   This appendix is non-normative.
   1.517 +
   1.518 +   This document replaces Section 6 of RFC 2595.
   1.519 +
   1.520 +   The specification details how the server is to compare client-
   1.521 +   provided character strings with stored character strings.
   1.522 +
   1.523 +   The ABNF grammar was updated.  In particular, the grammar now allows
   1.524 +   LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
   1.525 +   authzid, authcid, passwd productions.  However, whether these control
   1.526 +   characters may be used depends on the string preparation rules
   1.527 +   applicable to the production.  For passwd and authcid productions,
   1.528 +   control characters are prohibited.  For authzid, one must consult the
   1.529 +   application-level SASL profile.  This change allows PLAIN to carry
   1.530 +   all possible authorization identity strings allowed in SASL.
   1.531 +
   1.532 +   Pseudo-code was added.
   1.533 +
   1.534 +   The example section was expanded to illustrate more features of the
   1.535 +   PLAIN mechanism.
   1.536 +
   1.537 +Editor's Address
   1.538 +
   1.539 +   Kurt D. Zeilenga
   1.540 +   OpenLDAP Foundation
   1.541 +
   1.542 +   EMail: Kurt@OpenLDAP.org
   1.543 +
   1.544 +
   1.545 +
   1.546 +
   1.547 +
   1.548 +
   1.549 +
   1.550 +
   1.551 +
   1.552 +
   1.553 +
   1.554 +
   1.555 +
   1.556 +
   1.557 +
   1.558 +
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Zeilenga                    Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 4616                The PLAIN SASL Mechanism             August 2006
   1.568 +
   1.569 +
   1.570 +Full Copyright Statement
   1.571 +
   1.572 +   Copyright (C) The Internet Society (2006).
   1.573 +
   1.574 +   This document is subject to the rights, licenses and restrictions
   1.575 +   contained in BCP 78, and except as set forth therein, the authors
   1.576 +   retain all their rights.
   1.577 +
   1.578 +   This document and the information contained herein are provided on an
   1.579 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.580 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   1.581 +   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   1.582 +   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   1.583 +   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.584 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.585 +
   1.586 +Intellectual Property
   1.587 +
   1.588 +   The IETF takes no position regarding the validity or scope of any
   1.589 +   Intellectual Property Rights or other rights that might be claimed to
   1.590 +   pertain to the implementation or use of the technology described in
   1.591 +   this document or the extent to which any license under such rights
   1.592 +   might or might not be available; nor does it represent that it has
   1.593 +   made any independent effort to identify any such rights.  Information
   1.594 +   on the procedures with respect to rights in RFC documents can be
   1.595 +   found in BCP 78 and BCP 79.
   1.596 +
   1.597 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.598 +   assurances of licenses to be made available, or the result of an
   1.599 +   attempt made to obtain a general license or permission for the use of
   1.600 +   such proprietary rights by implementers or users of this
   1.601 +   specification can be obtained from the IETF on-line IPR repository at
   1.602 +   http://www.ietf.org/ipr.
   1.603 +
   1.604 +   The IETF invites any interested party to bring to its attention any
   1.605 +   copyrights, patents or patent applications, or other proprietary
   1.606 +   rights that may cover technology that may be required to implement
   1.607 +   this standard.  Please address the information to the IETF at
   1.608 +   ietf-ipr@ietf.org.
   1.609 +
   1.610 +Acknowledgement
   1.611 +
   1.612 +   Funding for the RFC Editor function is provided by the IETF
   1.613 +   Administrative Support Activity (IASA).
   1.614 +
   1.615 +
   1.616 +
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Zeilenga                    Standards Track                    [Page 11]
   1.622 +