*** empty log message ***

1 files changed, 619 insertions, 0 deletions

diff --git a/docs/rfc4616.txt b/docs/rfc4616.txt
new file mode 100644
index 00000000..991189d5
--- /dev/null
+++ b/docs/rfc4616.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 4616                           OpenLDAP Foundation
+Updates: 2595                                                August 2006
+Category: Standards Track
+
+
+  The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a simple clear-text user/password Simple
+   Authentication and Security Layer (SASL) mechanism called the PLAIN
+   mechanism.  The PLAIN mechanism is intended to be used, in
+   combination with data confidentiality services provided by a lower
+   layer, in protocols that lack a simple password authentication
+   command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+1.  Introduction
+
+   Clear-text, multiple-use passwords are simple, interoperate with
+   almost all existing operating system authentication databases, and
+   are useful for a smooth transition to a more secure password-based
+   authentication mechanism.  The drawback is that they are unacceptable
+   for use over network connections where data confidentiality is not
+   ensured.
+
+   This document defines the PLAIN Simple Authentication and Security
+   Layer ([SASL]) mechanism for use in protocols with no clear-text
+   login command (e.g., [ACAP] or [SMTP-AUTH]).  This document updates
+   RFC 2595, replacing Section 6.  Changes since RFC 2595 are detailed
+   in Appendix A.
+
+   The name associated with this mechanism is "PLAIN".
+
+   The PLAIN SASL mechanism does not provide a security layer.
+
+   The PLAIN mechanism should not be used without adequate data security
+   protection as this mechanism affords no integrity or confidentiality
+   protections itself.  The mechanism is intended to be used with data
+   security protections provided by application-layer protocol,
+   generally through its use of Transport Layer Security ([TLS])
+   services.
+
+   By default, implementations SHOULD advertise and make use of the
+   PLAIN mechanism only when adequate data security services are in
+   place.  Specifications for IETF protocols that indicate that this
+   mechanism is an applicable authentication mechanism MUST mandate that
+   implementations support an strong data security service, such as TLS.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [Keywords].
+
+2.  PLAIN SASL Mechanism
+
+   The mechanism consists of a single message, a string of [UTF-8]
+   encoded [Unicode] characters, from the client to the server.  The
+   client presents the authorization identity (identity to act as),
+   followed by a NUL (U+0000) character, followed by the authentication
+   identity (identity whose password will be used), followed by a NUL
+   (U+0000) character, followed by the clear-text password.  As with
+   other SASL mechanisms, the client does not provide an authorization
+   identity when it wishes the server to derive an identity from the
+   credentials and use that as the authorization identity.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+   The formal grammar for the client message using Augmented BNF [ABNF]
+   follows.
+
+   message   = [authzid] UTF8NUL authcid UTF8NUL passwd
+   authcid   = 1*SAFE ; MUST accept up to 255 octets
+   authzid   = 1*SAFE ; MUST accept up to 255 octets
+   passwd    = 1*SAFE ; MUST accept up to 255 octets
+   UTF8NUL   = %x00 ; UTF-8 encoded NUL character
+
+   SAFE      = UTF1 / UTF2 / UTF3 / UTF4
+               ;; any UTF-8 encoded Unicode character except NUL
+
+   UTF1      = %x01-7F ;; except NUL
+   UTF2      = %xC2-DF UTF0
+   UTF3      = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+               %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+   UTF4      = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+               %xF4 %x80-8F 2(UTF0)
+   UTF0      = %x80-BF
+
+   The authorization identity (authzid), authentication identity
+   (authcid), password (passwd), and NUL character deliminators SHALL be
+   transferred as [UTF-8] encoded strings of [Unicode] characters.  As
+   the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
+   character MUST NOT appear in authzid, authcid, or passwd productions.
+
+   The form of the authzid production is specific to the application-
+   level protocol's SASL profile [SASL].  The authcid and passwd
+   productions are form-free.  Use of non-visible characters or
+   characters that a user may be unable to enter on some keyboards is
+   discouraged.
+
+   Servers MUST be capable of accepting authzid, authcid, and passwd
+   productions up to and including 255 octets.  It is noted that the
+   UTF-8 encoding of a Unicode character may be as long as 4 octets.
+
+   Upon receipt of the message, the server will verify the presented (in
+   the message) authentication identity (authcid) and password (passwd)
+   with the system authentication database, and it will verify that the
+   authentication credentials permit the client to act as the (presented
+   or derived) authorization identity (authzid).  If both steps succeed,
+   the user is authenticated.
+
+   The presented authentication identity and password strings, as well
+   as the database authentication identity and password strings, are to
+   be prepared before being used in the verification process.  The
+   [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
+   preparation algorithm.  The SASLprep preparation algorithm is
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+   recommended to improve the likelihood that comparisons behave in an
+   expected manner.  The SASLprep preparation algorithm is not mandatory
+   so as to allow the server to employ other preparation algorithms
+   (including none) when appropriate.  For instance, use of a different
+   preparation algorithm may be necessary for the server to interoperate
+   with an external system.
+
+   When preparing the presented strings using [SASLPrep], the presented
+   strings are to be treated as "query" strings (Section 7 of
+   [StringPrep]) and hence unassigned code points are allowed to appear
+   in their prepared output.  When preparing the database strings using
+   [SASLPrep], the database strings are to be treated as "stored"
+   strings (Section 7 of [StringPrep]) and hence unassigned code points
+   are prohibited from appearing in their prepared output.
+
+   Regardless of the preparation algorithm used, if the output of a
+   non-invertible function (e.g., hash) of the expected string is
+   stored, the string MUST be prepared before input to that function.
+
+   Regardless of the preparation algorithm used, if preparation fails or
+   results in an empty string, verification SHALL fail.
+
+   When no authorization identity is provided, the server derives an
+   authorization identity from the prepared representation of the
+   provided authentication identity string.  This ensures that the
+   derivation of different representations of the authentication
+   identity produces the same authorization identity.
+
+   The server MAY use the credentials to initialize any new
+   authentication database, such as one suitable for [CRAM-MD5] or
+   [DIGEST-MD5].
+
+3.  Pseudo-Code
+
+   This section provides pseudo-code illustrating the verification
+   process (using hashed passwords and the SASLprep preparation
+   function) discussed above.  This section is not definitive.
+
+   boolean Verify(string authzid, string authcid, string passwd) {
+     string pAuthcid = SASLprep(authcid, true); # prepare authcid
+     string pPasswd = SASLprep(passwd, true);   # prepare passwd
+     if (pAuthcid == NULL || pPasswd == NULL) {
+       return false;     # preparation failed
+     }
+     if (pAuthcid == "" || pPasswd == "") {
+       return false;     # empty prepared string
+     }
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+     storedHash = FetchPasswordHash(pAuthcid);
+     if (storedHash == NULL || storedHash == "") {
+       return false;     # error or unknown authcid
+     }
+
+     if (!Compare(storedHash, Hash(pPasswd))) {
+       return false;     # incorrect password
+     }
+
+     if (authzid == NULL ) {
+       authzid = DeriveAuthzid(pAuthcid);
+       if (authzid == NULL || authzid == "") {
+           return false; # could not derive authzid
+       }
+     }
+
+     if (!Authorize(pAuthcid, authzid)) {
+       return false;     # not authorized
+     }
+
+     return true;
+   }
+
+   The second parameter of the SASLprep function, when true, indicates
+   that unassigned code points are allowed in the input.  When the
+   SASLprep function is called to prepare the password prior to
+   computing the stored hash, the second parameter would be false.
+
+   The second parameter provided to the Authorize function is not
+   prepared by this code.  The application-level SASL profile should be
+   consulted to determine what, if any, preparation is necessary.
+
+   Note that the DeriveAuthzid and Authorize functions (whether
+   implemented as one function or two, whether designed in a manner in
+   which these functions or whether the mechanism implementation can be
+   reused elsewhere) require knowledge and understanding of mechanism
+   and the application-level protocol specification and/or
+   implementation details to implement.
+
+   Note that the Authorize function outcome is clearly dependent on
+   details of the local authorization model and policy.  Both functions
+   may be dependent on other factors as well.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+4.  Examples
+
+   This section provides examples of PLAIN authentication exchanges.
+   The examples are intended to help the readers understand the above
+   text.  The examples are not definitive.
+
+   "C:" and "S:" indicate lines sent by the client and server,
+   respectively.  "<NUL>" represents a single NUL (U+0000) character.
+   The Application Configuration Access Protocol ([ACAP]) is used in the
+   examples.
+
+   The first example shows how the PLAIN mechanism might be used for
+   user authentication.
+
+   S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+   C: a001 STARTTLS
+   S: a001 OK "Begin TLS negotiation now"
+   <TLS negotiation, further commands are under TLS layer>
+   S: * ACAP (SASL "CRAM-MD5" "PLAIN")
+   C: a002 AUTHENTICATE "PLAIN"
+   S: + ""
+   C: {21}
+   C: <NUL>tim<NUL>tanstaaftanstaaf
+   S: a002 OK "Authenticated"
+
+   The second example shows how the PLAIN mechanism might be used to
+   attempt to assume the identity of another user.  In this example, the
+   server rejects the request.  Also, this example makes use of the
+   protocol optional initial response capability to eliminate a round-
+   trip.
+
+   S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+   C: a001 STARTTLS
+   S: a001 OK "Begin TLS negotiation now"
+   <TLS negotiation, further commands are under TLS layer>
+   S: * ACAP (SASL "CRAM-MD5" "PLAIN")
+   C: a002 AUTHENTICATE "PLAIN" {20+}
+   C: Ursel<NUL>Kurt<NUL>xipj3plmq
+   S: a002 NO "Not authorized to requested authorization identity"
+
+5.  Security Considerations
+
+   As the PLAIN mechanism itself provided no integrity or
+   confidentiality protections, it should not be used without adequate
+   external data security protection, such as TLS services provided by
+   many application-layer protocols.  By default, implementations SHOULD
+   NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
+   adequate data security services are in place.
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+   When the PLAIN mechanism is used, the server gains the ability to
+   impersonate the user to all services with the same password
+   regardless of any encryption provided by TLS or other confidentiality
+   protection mechanisms.  Whereas many other authentication mechanisms
+   have similar weaknesses, stronger SASL mechanisms address this issue.
+   Clients are encouraged to have an operational mode where all
+   mechanisms that are likely to reveal the user's password to the
+   server are disabled.
+
+   General [SASL] security considerations apply to this mechanism.
+
+   Unicode, [UTF-8], and [StringPrep] security considerations also
+   apply.
+
+6.  IANA Considerations
+
+   The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism
+   has been updated by the IANA to reflect that this document now
+   provides its technical specification.
+
+   To: iana@iana.org
+   Subject: Updated Registration of SASL mechanism PLAIN
+
+   SASL mechanism name: PLAIN
+   Security considerations: See RFC 4616.
+   Published specification (optional, recommended): RFC 4616
+   Person & email address to contact for further information:
+        Kurt Zeilenga <kurt@openldap.org>
+        IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Author/Change controller: IESG <iesg@ietf.org>
+   Note: Updates existing entry for PLAIN
+
+7.  Acknowledgements
+
+   This document is a revision of RFC 2595 by Chris Newman.  Portions of
+   the grammar defined in Section 2 were borrowed from [UTF-8] by
+   Francois Yergeau.
+
+   This document is a product of the IETF Simple Authentication and
+   Security Layer (SASL) Working Group.
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+8.  Normative References
+
+   [ABNF]        Crocker, D., Ed. and P. Overell, "Augmented BNF for
+                 Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+   [Keywords]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]        Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+   [SASLPrep]    Zeilenga, K., "SASLprep: Stringprep Profile for User
+                 Names and Passwords", RFC 4013, February 2005.
+
+   [StringPrep]  Hoffman, P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ("stringprep")", RFC 3454,
+                 December 2002.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [UTF-8]       Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [TLS]         Dierks, T. and E. Rescorla, "The Transport Layer
+                 Security (TLS) Protocol Version 1.1", RFC 4346, April
+                 2006.
+
+9.  Informative References
+
+   [ACAP]        Newman, C. and J. Myers, "ACAP -- Application
+                 Configuration Access Protocol", RFC 2244, November
+                 1997.
+
+   [CRAM-MD5]    Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work
+                 in Progress, June 2006.
+
+   [DIGEST-MD5]  Melnikov, A., Ed., "Using Digest Authentication as a
+                 SASL Mechanism", Work in Progress, June 2006.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+   [IANA-SASL]   IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
+                 MECHANISMS",
+                 <http://www.iana.org/assignments/sasl-mechanisms>.
+
+   [SMTP-AUTH]   Myers, J., "SMTP Service Extension for Authentication",
+                 RFC 2554, March 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+Appendix A.  Changes since RFC 2595
+
+   This appendix is non-normative.
+
+   This document replaces Section 6 of RFC 2595.
+
+   The specification details how the server is to compare client-
+   provided character strings with stored character strings.
+
+   The ABNF grammar was updated.  In particular, the grammar now allows
+   LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
+   authzid, authcid, passwd productions.  However, whether these control
+   characters may be used depends on the string preparation rules
+   applicable to the production.  For passwd and authcid productions,
+   control characters are prohibited.  For authzid, one must consult the
+   application-level SASL profile.  This change allows PLAIN to carry
+   all possible authorization identity strings allowed in SASL.
+
+   Pseudo-code was added.
+
+   The example section was expanded to illustrate more features of the
+   PLAIN mechanism.
+
+Editor's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4616                The PLAIN SASL Mechanism             August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+