mv doc/rfc/ doc/rfcs; Add newer related rfcs

13 files changed, 7808 insertions, 0 deletions

diff --git a/doc/rfc/rfc1459.txt b/doc/rfcs/rfc1459.txt
index 09fbf34..09fbf34 100644
--- a/doc/rfc/rfc1459.txt
+++ b/doc/rfcs/rfc1459.txt
diff --git a/doc/rfcs/rfc2222.txt b/doc/rfcs/rfc2222.txt
new file mode 100644
index 0000000..2b0a2ab
--- /dev/null
+++ b/doc/rfcs/rfc2222.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2222                       Netscape Communications
+Category: Standards Track                                   October 1997
+
+
+            Simple Authentication and Security Layer (SASL)
+
+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 (1997).  All Rights Reserved.
+
+Table of Contents
+
+   1.    Abstract ..............................................    2
+   2.    Organization of this Document .........................    2
+   2.1.  How to Read This Document .............................    2
+   2.2.  Conventions Used in this Document .....................    2
+   2.3.  Examples ..............................................    3
+   3.    Introduction and Overview .............................    3
+   4.    Profiling requirements ................................    4
+   5.    Specific issues .......................................    5
+   5.1.  Client sends data first ...............................    5
+   5.2.  Server returns success with additional data ...........    5
+   5.3.  Multiple authentications ..............................    5
+   6.    Registration procedures ...............................    6
+   6.1.  Comments on SASL mechanism registrations ..............    6
+   6.2.  Location of Registered SASL Mechanism List ............    6
+   6.3.  Change Control ........................................    7
+   6.4.  Registration Template .................................    7
+   7.    Mechanism definitions .................................    8
+   7.1.  Kerberos version 4 mechanism ..........................    8
+   7.2.  GSSAPI mechanism ......................................    9
+   7.2.1 Client side of authentication protocol exchange .......    9
+   7.2.2 Server side of authentication protocol exchange .......   10
+   7.2.3 Security layer ........................................   11
+   7.3.  S/Key mechanism .......................................   11
+   7.4.  External mechanism ....................................   12
+   8.    References ............................................   13
+   9.    Security Considerations ...............................   13
+   10.   Author's Address ......................................   14
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2222                          SASL                      October 1997
+
+
+   Appendix A. Relation of SASL to Transport Security ..........   15
+   Full Copyright Statement ....................................   16
+
+1.    Abstract
+
+   This document describes a method for adding authentication support to
+   connection-based protocols.  To use this specification, a protocol
+   includes a command for identifying and authenticating a user to a
+   server and for optionally negotiating protection of subsequent
+   protocol interactions.  If its use is negotiated, a security layer is
+   inserted between the protocol and the connection.  This document
+   describes how a protocol specifies such a command, defines several
+   mechanisms for use by the command, and defines the protocol used for
+   carrying a negotiated security layer over the connection.
+
+2.    Organization of this Document
+
+2.1.  How to Read This Document
+
+   This document is written to serve two different audiences, protocol
+   designers using this specification to support authentication in their
+   protocol, and implementors of clients or servers for those protocols
+   using this specification.
+
+   The sections "Introduction and Overview", "Profiling requirements",
+   and "Security Considerations" cover issues that protocol designers
+   need to understand and address in profiling this specification for
+   use in a specific protocol.
+
+   Implementors of a protocol using this specification need the
+   protocol-specific profiling information in addition to the
+   information in this document.
+
+2.2.  Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2222                          SASL                      October 1997
+
+
+2.3.  Examples
+
+   Examples in this document are for the IMAP profile [RFC 2060] of this
+   specification.  The base64 encoding of challenges and responses, as
+   well as the "+ " preceding the responses are part of the IMAP4
+   profile, not part of the SASL specification itself.
+
+3.    Introduction and Overview
+
+   The Simple Authentication and Security Layer (SASL) is a method for
+   adding authentication support to connection-based protocols.  To use
+   this specification, a protocol includes a command for identifying and
+   authenticating a user to a server and for optionally negotiating a
+   security layer for subsequent protocol interactions.
+
+   The command has a required argument identifying a SASL mechanism.
+   SASL mechanisms are named by strings, from 1 to 20 characters in
+   length, consisting of upper-case letters, digits, hyphens, and/or
+   underscores.  SASL mechanism names must be registered with the IANA.
+   Procedures for registering new SASL mechanisms are given in the
+   section "Registration procedures"
+
+   If a server supports the requested mechanism, it initiates an
+   authentication protocol exchange.  This consists of a series of
+   server challenges and client responses that are specific to the
+   requested mechanism.  The challenges and responses are defined by the
+   mechanisms as binary tokens of arbitrary length.  The protocol's
+   profile then specifies how these binary tokens are then encoded for
+   transfer over the connection.
+
+   After receiving the authentication command or any client response, a
+   server may issue a challenge, indicate failure, or indicate
+   completion.  The protocol's profile specifies how the server
+   indicates which of the above it is doing.
+
+   After receiving a challenge, a client may issue a response or abort
+   the exchange.  The protocol's profile specifies how the client
+   indicates which of the above it is doing.
+
+   During the authentication protocol exchange, the mechanism performs
+   authentication, transmits an authorization identity (frequently known
+   as a userid) from the client to server, and negotiates the use of a
+   mechanism-specific security layer.  If the use of a security layer is
+   agreed upon, then the mechanism must also define or negotiate the
+   maximum cipher-text buffer size that each side is able to receive.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The transmitted authorization identity may be different than the
+   identity in the client's authentication credentials.  This permits
+   agents such as proxy servers to authenticate using their own
+   credentials, yet request the access privileges of the identity for
+   which they are proxying.  With any mechanism, transmitting an
+   authorization identity of the empty string directs the server to
+   derive an authorization identity from the client's authentication
+   credentials.
+
+   If use of a security layer is negotiated, it is applied to all
+   subsequent data sent over the connection.  The security layer takes
+   effect immediately following the last response of the authentication
+   exchange for data sent by the client and the completion indication
+   for data sent by the server.  Once the security layer is in effect,
+   the protocol stream is processed by the security layer into buffers
+   of cipher-text.  Each buffer is transferred over the connection as a
+   stream of octets prepended with a four octet field in network byte
+   order that represents the length of the following buffer.  The length
+   of the cipher-text buffer must be no larger than the maximum size
+   that was defined or negotiated by the other side.
+
+4.    Profiling requirements
+
+   In order to use this specification, a protocol definition must supply
+   the following information:
+
+   1. A service name, to be selected from the IANA registry of "service"
+      elements for the GSSAPI host-based service name form [RFC 2078].
+
+   2. A definition of the command to initiate the authentication
+      protocol exchange.  This command must have as a parameter the
+      mechanism name being selected by the client.
+
+      The command SHOULD have an optional parameter giving an initial
+      response.  This optional parameter allows the client to avoid a
+      round trip when using a mechanism which is defined to have the
+      client send data first.  When this initial response is sent by the
+      client and the selected mechanism is defined to have the server
+      start with an initial challenge, the command fails.  See section
+      5.1 of this document for further information.
+
+   3. A definition of the method by which the authentication protocol
+      exchange is carried out, including how the challenges and
+      responses are encoded, how the server indicates completion or
+      failure of the exchange, how the client aborts an exchange, and
+      how the exchange method interacts with any line length limits in
+      the protocol.
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2222                          SASL                      October 1997
+
+
+   4. Identification of the octet where any negotiated security layer
+      starts to take effect, in both directions.
+
+   5. A specification of how the authorization identity passed from the
+      client to the server is to be interpreted.
+
+5.    Specific issues
+
+5.1.  Client sends data first
+
+   Some mechanisms specify that the first data sent in the
+   authentication protocol exchange is from the client to the server.
+
+   If a protocol's profile permits the command which initiates an
+   authentication protocol exchange to contain an initial client
+   response, this parameter SHOULD be used with such mechanisms.
+
+   If the initial client response parameter is not given, or if a
+   protocol's profile does not permit the command which initiates an
+   authentication protocol exchange to contain an initial client
+   response, then the server issues a challenge with no data.  The
+   client's response to this challenge is then used as the initial
+   client response.  (The server then proceeds to send the next
+   challenge, indicates completion, or indicates failure.)
+
+5.2.  Server returns success with additional data
+
+   Some mechanisms may specify that server challenge data be sent to the
+   client along with an indication of successful completion of the
+   exchange.  This data would, for example, authenticate the server to
+   the client.
+
+   If a protocol's profile does not permit this server challenge to be
+   returned with a success indication, then the server issues the server
+   challenge without an indication of successful completion.  The client
+   then responds with no data.  After receiving this empty response, the
+   server then indicates successful completion.
+
+5.3.  Multiple authentications
+
+   Unless otherwise stated by the protocol's profile, only one
+   successful SASL negotiation may occur in a protocol session.  In this
+   case, once an authentication protocol exchange has successfully
+   completed, further attempts to initiate an authentication protocol
+   exchange fail.
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2222                          SASL                      October 1997
+
+
+   In the case that a profile explicitly permits multiple successful
+   SASL negotiations to occur, then in no case may multiple security
+   layers be simultaneously in effect.  If a security layer is in effect
+   and a subsequent SASL negotiation selects no security layer, the
+   original security layer remains in effect.  If a security layer is in
+   effect and a subsequent SASL negotiation selects a second security
+   layer, then the second security layer replaces the first.
+
+6.    Registration procedures
+
+   Registration of a SASL mechanism is done by filling in the template
+   in section 6.4 and sending it in to iana@isi.edu.  IANA has the right
+   to reject obviously bogus registrations, but will perform no review
+   of clams made in the registration form.
+
+   There is no naming convention for SASL mechanisms; any name that
+   conforms to the syntax of a SASL mechanism name can be registered.
+
+   While the registration procedures do not require it, authors of SASL
+   mechanisms are encouraged to seek community review and comment
+   whenever that is feasible.  Authors may seek community review by
+   posting a specification of their proposed mechanism as an internet-
+   draft.  SASL mechanisms intended for widespread use should be
+   standardized through the normal IETF process, when appropriate.
+
+6.1.  Comments on SASL mechanism registrations
+
+   Comments on registered SASL mechanisms should first be sent to the
+   "owner" of the mechanism.  Submitters of comments may, after a
+   reasonable attempt to contact the owner, request IANA to attach their
+   comment to the SASL mechanism registration itself.  If IANA approves
+   of this the comment will be made accessible in conjunction with the
+   SASL mechanism registration itself.
+
+6.2.  Location of Registered SASL Mechanism List
+
+   SASL mechanism registrations will be posted in the anonymous FTP
+   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
+   mechanisms/" and all registered SASL mechanisms will be listed in the
+   periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
+   1700].  The SASL mechanism description and other supporting material
+   may also be published as an Informational RFC by sending it to "rfc-
+   editor@isi.edu" (please follow the instructions to RFC authors [RFC
+   2223]).
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2222                          SASL                      October 1997
+
+
+6.3.  Change Control
+
+   Once a SASL mechanism registration has been published by IANA, the
+   author may request a change to its definition.  The change request
+   follows the same procedure as the registration request.
+
+   The owner of a SASL mechanism may pass responsibility for the SASL
+   mechanism to another person or agency by informing IANA; this can be
+   done without discussion or review.
+
+   The IESG may reassign responsibility for a SASL mechanism. The most
+   common case of this will be to enable changes to be made to
+   mechanisms where the author of the registration has died, moved out
+   of contact or is otherwise unable to make changes that are important
+   to the community.
+
+   SASL mechanism registrations may not be deleted; mechanisms which are
+   no longer believed appropriate for use can be declared OBSOLETE by a
+   change to their "intended use" field; such SASL mechanisms will be
+   clearly marked in the lists published by IANA.
+
+   The IESG is considered to be the owner of all SASL mechanisms which
+   are on the IETF standards track.
+
+6.4.  Registration Template
+
+   To: iana@iana.org
+   Subject: Registration of SASL mechanism X
+
+   SASL mechanism name:
+
+   Security considerations:
+
+   Published specification (optional, recommended):
+
+   Person & email address to contact for further information:
+
+   Intended usage:
+
+   (One of COMMON, LIMITED USE or OBSOLETE)
+
+   Author/Change controller:
+
+   (Any other information that the author deems interesting may be
+   added below this line.)
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2222                          SASL                      October 1997
+
+
+7.    Mechanism definitions
+
+   The following mechanisms are hereby defined.
+
+7.1.  Kerberos version 4 mechanism
+
+   The mechanism name associated with Kerberos version 4 is
+   "KERBEROS_V4".
+
+   The first challenge consists of a random 32-bit number in network
+   byte order.  The client responds with a Kerberos ticket and an
+   authenticator for the principal "service.hostname@realm", where
+   "service" is the service name specified in the protocol's profile,
+   "hostname" is the first component of the host name of the server with
+   all letters in lower case, and where "realm" is the Kerberos realm of
+   the server.  The encrypted checksum field included within the
+   Kerberos authenticator contains the server provided challenge in
+   network byte order.
+
+   Upon decrypting and verifying the ticket and authenticator, the
+   server verifies that the contained checksum field equals the original
+   server provided random 32-bit number.  Should the verification be
+   successful, the server must add one to the checksum and construct 8
+   octets of data, with the first four octets containing the incremented
+   checksum in network byte order, the fifth octet containing a bit-mask
+   specifying the security layers supported by the server, and the sixth
+   through eighth octets containing, in network byte order, the maximum
+   cipher-text buffer size the server is able to receive.  The server
+   must encrypt using DES ECB mode the 8 octets of data in the session
+   key and issue that encrypted data in a second challenge.  The client
+   considers the server authenticated if the first four octets of the
+   un-encrypted data is equal to one plus the checksum it previously
+   sent.
+
+   The client must construct data with the first four octets containing
+   the original server-issued checksum in network byte order, the fifth
+   octet containing the bit-mask specifying the selected security layer,
+   the sixth through eighth octets containing in network byte order the
+   maximum cipher-text buffer size the client is able to receive, and
+   the following octets containing the authorization identity.  The
+   client must then append from one to eight zero-valued octets so that
+   the length of the data is a multiple of eight octets. The client must
+   then encrypt using DES PCBC mode the data with the session key and
+   respond with the encrypted data.  The server decrypts the data and
+   verifies the contained checksum.  The server must verify that the
+   principal identified in the Kerberos ticket is authorized to connect
+   as that authorization identity.  After this verification, the
+   authentication process is complete.
+
+
+
+Myers                       Standards Track                     [Page 8]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The security layers and their corresponding bit-masks are as follows:
+
+      1 No security layer
+      2 Integrity (krb_mk_safe) protection
+      4 Privacy (krb_mk_priv) protection
+
+   Other bit-masks may be defined in the future; bits which are not
+   understood must be negotiated off.
+
+   EXAMPLE: The following are two Kerberos version 4 login scenarios to
+   the IMAP4 protocol (note that the line breaks in the sample
+   authenticators are for editorial clarity and are not in real
+   authenticators)
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE KERBEROS_V4
+     S: + AmFYig==
+     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+     S: + or//EoAADZI=
+     C: DiAF5A4gA+oOIALuBkAAmw==
+     S: A001 OK Kerberos V4 authentication successful
+
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE KERBEROS_V4
+     S: + gcfgCA==
+     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+     S: A001 NO Kerberos V4 authentication failed
+
+7.2.  GSSAPI mechanism
+
+   The mechanism name associated with all mechanisms employing the
+   GSSAPI [RFC 2078] is "GSSAPI".
+
+7.2.1 Client side of authentication protocol exchange
+
+   The client calls GSS_Init_sec_context, passing in 0 for
+   input_context_handle (initially) and a targ_name equal to output_name
+   from GSS_Import_Name called with input_name_type of
+   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
+   "service@hostname" where "service" is the service name specified in
+   the protocol's profile, and "hostname" is the fully qualified host
+   name of the server.  The client then responds with the resulting
+   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
+
+
+
+Myers                       Standards Track                     [Page 9]
+
+RFC 2222                          SASL                      October 1997
+
+
+   then the client should expect the server to issue a token in a
+   subsequent challenge.  The client must pass the token to another call
+   to GSS_Init_sec_context, repeating the actions in this paragraph.
+
+   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
+   the following actions: If the last call to GSS_Init_sec_context
+   returned an output_token, then the client responds with the
+   output_token, otherwise the client responds with no data.  The client
+   should then expect the server to issue a token in a subsequent
+   challenge.  The client passes this token to GSS_Unwrap and interprets
+   the first octet of resulting cleartext as a bit-mask specifying the
+   security layers supported by the server and the second through fourth
+   octets as the maximum size output_message to send to the server.  The
+   client then constructs data, with the first octet containing the
+   bit-mask specifying the selected security layer, the second through
+   fourth octets containing in network byte order the maximum size
+   output_message the client is able to receive, and the remaining
+   octets containing the authorization identity.  The client passes the
+   data to GSS_Wrap with conf_flag set to FALSE, and responds with the
+   generated output_message.  The client can then consider the server
+   authenticated.
+
+7.2.2 Server side of authentication protocol exchange
+
+   The server passes the initial client response to
+   GSS_Accept_sec_context as input_token, setting input_context_handle
+   to 0 (initially).  If GSS_Accept_sec_context returns
+   GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
+   to the client in challenge and passes the resulting response to
+   another call to GSS_Accept_sec_context, repeating the actions in this
+   paragraph.
+
+   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
+   the following actions: If the last call to GSS_Accept_sec_context
+   returned an output_token, the server returns it to the client in a
+   challenge and expects a reply from the client with no data.  Whether
+   or not an output_token was returned (and after receipt of any
+   response from the client to such an output_token), the server then
+   constructs 4 octets of data, with the first octet containing a bit-
+   mask specifying the security layers supported by the server and the
+   second through fourth octets containing in network byte order the
+   maximum size output_token the server is able to receive.  The server
+   must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
+   and issue the generated output_message to the client in a challenge.
+   The server must then pass the resulting response to GSS_Unwrap and
+   interpret the first octet of resulting cleartext as the bit-mask for
+   the selected security layer, the second through fourth octets as the
+   maximum size output_message to send to the client, and the remaining
+
+
+
+Myers                       Standards Track                    [Page 10]
+
+RFC 2222                          SASL                      October 1997
+
+
+   octets as the authorization identity.  The server must verify that
+   the src_name is authorized to authenticate as the authorization
+   identity.  After these verifications, the authentication process is
+   complete.
+
+7.2.3 Security layer
+
+   The security layers and their corresponding bit-masks are as follows:
+
+     1 No security layer
+     2 Integrity protection.
+       Sender calls GSS_Wrap with conf_flag set to FALSE
+     4 Privacy protection.
+       Sender calls GSS_Wrap with conf_flag set to TRUE
+
+   Other bit-masks may be defined in the future; bits which are not
+   understood must be negotiated off.
+
+7.3.  S/Key mechanism
+
+   The mechanism name associated with S/Key [RFC 1760] using the MD4
+   digest algorithm is "SKEY".
+
+   The client sends an initial response with the authorization identity.
+
+   The server then issues a challenge which contains the decimal
+   sequence number followed by a single space and the seed string for
+   the indicated authorization identity.  The client responds with the
+   one-time-password, as either a 64-bit value in network byte order or
+   encoded in the "six English words" format.
+
+   The server must verify the one-time-password.  After this
+   verification, the authentication process is complete.
+
+   S/Key authentication does not provide for any security layers.
+
+   EXAMPLE: The following are two S/Key login scenarios in the IMAP4
+   protocol.
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE SKEY
+     S: +
+     C: bW9yZ2Fu
+     S: + OTUgUWE1ODMwOA==
+     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+     S: A001 OK S/Key authentication successful
+
+
+
+
+
+Myers                       Standards Track                    [Page 11]
+
+RFC 2222                          SASL                      October 1997
+
+
+     S: * OK IMAP4 Server
+     C: A001 AUTHENTICATE SKEY
+     S: +
+     C: c21pdGg=
+     S: + OTUgUWE1ODMwOA==
+     C: BsAY3g4gBNo=
+     S: A001 NO S/Key authentication failed
+
+   The following is an S/Key login scenario in an IMAP4-like protocol
+   which has an optional "initial response" argument to the AUTHENTICATE
+   command.
+
+     S: * OK IMAP4-Like Server
+     C: A001 AUTHENTICATE SKEY bW9yZ2Fu
+     S: + OTUgUWE1ODMwOA==
+     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+     S: A001 OK S/Key authentication successful
+
+7.4.  External mechanism
+
+   The mechanism name associated with external authentication is
+   "EXTERNAL".
+
+   The client sends an initial response with the authorization identity.
+
+   The server uses information, external to SASL, to determine whether
+   the client is authorized to authenticate as the authorization
+   identity.  If the client is so authorized, the server indicates
+   successful completion of the authentication exchange; otherwise the
+   server indicates failure.
+
+   The system providing this external information may be, for example,
+   IPsec or TLS.
+
+   If the client sends the empty string as the authorization identity
+   (thus requesting the authorization identity be derived from the
+   client's authentication credentials), the authorization identity is
+   to be derived from authentication credentials which exist in the
+   system which is providing the external authentication.
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 12]
+
+RFC 2222                          SASL                      October 1997
+
+
+8.    References
+
+   [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [RFC 2078] Linn, J., "Generic Security Service Application Program
+              Interface, Version 2", RFC 2078, January 1997.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
+              Authors", RFC 2223, October 1997.
+
+   [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
+              1760, February 1995.
+
+   [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+              RFC 1700, October 1994.
+
+9.    Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   The mechanisms that support integrity protection are designed such
+   that the negotiation of the security layer and authorization identity
+   is integrity protected.  When the client selects a security layer
+   with at least integrity protection, this protects against an active
+   attacker hijacking the connection and modifying the authentication
+   exchange to negotiate a plaintext connection.
+
+   When a server or client supports multiple authentication mechanisms,
+   each of which has a different security strength, it is possible for
+   an active attacker to cause a party to use the least secure mechanism
+   supported.  To protect against this sort of attack, a client or
+   server which supports mechanisms of different strengths should have a
+   configurable minimum strength that it will use.  It is not sufficient
+   for this minimum strength check to only be on the server, since an
+   active attacker can change which mechanisms the client sees as being
+   supported, causing the client to send authentication credentials for
+   its weakest supported mechanism.
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 13]
+
+RFC 2222                          SASL                      October 1997
+
+
+   The client's selection of a SASL mechanism is done in the clear and
+   may be modified by an active attacker.  It is important for any new
+   SASL mechanisms to be designed such that an active attacker cannot
+   obtain an authentication with weaker security properties by modifying
+   the SASL mechanism name and/or the challenges and responses.
+
+   Any protocol interactions prior to authentication are performed in
+   the clear and may be modified by an active attacker.  In the case
+   where a client selects integrity protection, it is important that any
+   security-sensitive protocol negotiations be performed after
+   authentication is complete.  Protocols should be designed such that
+   negotiations performed prior to authentication should be either
+   ignored or revalidated once authentication is complete.
+
+10.   Author's Address
+
+   John G. Myers
+   Netscape Communications
+   501 E. Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043-4042
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 14]
+
+RFC 2222                          SASL                      October 1997
+
+
+Appendix A. Relation of SASL to Transport Security
+
+   Questions have been raised about the relationship between SASL and
+   various services (such as IPsec and TLS) which provide a secured
+   connection.
+
+   Two of the key features of SASL are:
+
+   1. The separation of the authorization identity from the identity in
+      the client's credentials.  This permits agents such as proxy
+      servers to authenticate using their own credentials, yet request
+      the access privileges of the identity for which they are proxying.
+
+   2. Upon successful completion of an authentication exchange, the
+      server knows the authorization identity the client wishes to use.
+      This allows servers to move to a "user is authenticated" state in
+      the protocol.
+
+   These features are extremely important to some application protocols,
+   yet Transport Security services do not always provide them.  To
+   define SASL mechanisms based on these services would be a very messy
+   task, as the framing of these services would be redundant with the
+   framing of SASL and some method of providing these important SASL
+   features would have to be devised.
+
+   Sometimes it is desired to enable within an existing connection the
+   use of a security service which does not fit the SASL model.  (TLS is
+   an example of such a service.)  This can be done by adding a command,
+   for example "STARTTLS", to the protocol.  Such a command is outside
+   the scope of SASL, and should be different from the command which
+   starts a SASL authentication protocol exchange.
+
+   In certain situations, it is reasonable to use SASL underneath one of
+   these Transport Security services.  The transport service would
+   secure the connection, either service would authenticate the client,
+   and SASL would negotiate the authorization identity.  The SASL
+   negotiation would be what moves the protocol from "unauthenticated"
+   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
+   explicitly intended to handle the case where the transport service
+   secures the connection and authenticates the client and SASL
+   negotiates the authorization identity.
+
+   When using SASL underneath a sufficiently strong Transport Security
+   service, a SASL security layer would most likely be redundant.  The
+   client and server would thus probably want to negotiate off the use
+   of a SASL security layer.
+
+
+
+
+
+Myers                       Standards Track                    [Page 15]
+
+RFC 2222                          SASL                      October 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published
+   andand distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 16]
+
diff --git a/doc/rfcs/rfc2444.txt b/doc/rfcs/rfc2444.txt
new file mode 100644
index 0000000..80a65a2
--- /dev/null
+++ b/doc/rfcs/rfc2444.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2444                                      Innosoft
+Updates: 2222                                               October 1998
+Category: Standards Track
+
+
+                  The One-Time-Password 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 (1998).  All Rights Reserved.
+
+Abstract
+
+   OTP [OTP] provides a useful authentication mechanism for situations
+   where there is limited client or server trust.  Currently, OTP is
+   added to protocols in an ad-hoc fashion with heuristic parsing.  This
+   specification defines an OTP SASL [SASL] mechanism so it can be
+   easily and formally integrated into many application protocols.
+
+1. How to Read This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED" and "MAY" in this document are to be interpreted as
+   defined in "Key words for use in RFCs to Indicate Requirement Levels"
+   [KEYWORDS].
+
+   This memo assumes the reader is familiar with OTP [OTP], OTP extended
+   responses [OTP-EXT] and SASL [SASL].
+
+2. Intended Use
+
+   The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL].  OTP
+   is a good choice for usage scenarios where the client is untrusted
+   (e.g., a kiosk client), as a one-time password will only give the
+   client a single opportunity to act on behalf of the user.  OTP is
+   also a good choice for situations where interactive logins are
+   permitted to the server, as a compromised OTP authentication database
+   is only subject to dictionary attacks, unlike authentication
+   databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+   It is important to note that each use of the OTP mechanism causes the
+   authentication database entry for a user to be updated.
+
+   This SASL mechanism provides a formal way to integrate OTP into
+   SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3
+   [POP-AUTH] and LDAPv3 [LDAPv3].
+
+3. Profiling OTP for SASL
+
+   OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of
+   options.  However, for authentication to succeed, the client and
+   server need compatible option sets.  This specification defines a
+   single SASL mechanism: OTP.  The following rules apply to this
+   mechanism:
+
+   o   The extended response syntax MUST be used.
+
+   o   Servers MUST support the following four OTP extended responses:
+       "hex", "word", "init-hex" and "init-word".  Servers MUST support
+       the "word" and "init-word" responses for the standard dictionary
+       and SHOULD support alternate dictionaries.  Servers MUST NOT
+       require use of any additional OTP extensions or options.
+
+   o   Clients SHOULD support display of the OTP challenge to the user
+       and entry of an OTP in multi-word format.  Clients MAY also
+       support direct entry of the pass phrase and compute the "hex" or
+       "word" response.
+
+   o   Clients MUST indicate when authentication fails due to the
+       sequence number getting too low and SHOULD offer the user the
+       option to reset the sequence using the "init-hex" or "init-word"
+       response.
+
+   Support for the MD5 algorithm is REQUIRED, and support for the SHA1
+   algorithm is RECOMMENDED.
+
+4. OTP Authentication Mechanism
+
+   The mechanism does not provide any security layer.
+
+   The client begins by sending a message to the server containing the
+   following two pieces of information.
+
+   (1) An authorization identity.  When the empty string is used, this
+   defaults to the authentication identity.  This is used by system
+   administrators or proxy servers to login with a different user
+   identity.  This field may be up to 255 octets and is terminated by a
+   NUL (0) octet.  US-ASCII printable characters are preferred, although
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+   UTF-8 [UTF-8] printable characters are permitted to support
+   international names.  Use of character sets other than US-ASCII and
+   UTF-8 is forbidden.
+
+   (2) An authentication identity.  The identity whose pass phrase will
+   be used.  This field may be up to 255 octets.  US-ASCII printable
+   characters are preferred, although UTF-8 [UTF-8] printable characters
+   are permitted to support international names.  Use of character sets
+   other than US-ASCII and UTF-8 is forbidden.
+
+   The server responds by sending a message containing the OTP challenge
+   as described in OTP [OTP] and OTP extended responses [OTP-EXT].
+
+   If a client sees an unknown hash algorithm name it will not be able
+   to process a pass phrase input by the user.  In this situation the
+   client MAY prompt for the six-word format, issue the cancel sequence
+   as specified by the SASL profile for the protocol in use and try a
+   different SASL mechanism, or close the connection and refuse to
+   authenticate.  As a result of this behavior, a server is restricted
+   to one OTP hash algorithm per user.
+
+   On success, the client generates an extended response in the "hex",
+   "word", "init-hex" or "init-word" format.  The client is not required
+   to terminate the response with a space or a newline and SHOULD NOT
+   include unnecessary whitespace.
+
+   Servers MUST tolerate input of arbitrary length, but MAY fail the
+   authentication if the length of client input exceeds reasonable size.
+
+5. Examples
+
+   In these example, "C:" represents lines sent from the client to the
+   server and "S:" represents lines sent from the server to the client.
+   The user name is "tim" and no authorization identity is provided.
+   The "<NUL>" below represents an ASCII NUL octet.
+
+   The following is an example of the OTP mechanism using the ACAP
+   [ACAP] profile of SASL.  The pass phrase used in this example is:
+             This is a test.
+
+          C: a001 AUTHENTICATE "OTP" {4}
+          C: <NUL>tim
+          S: + "otp-md5 499 ke1234 ext"
+          C: "hex:5bf075d9959d036f"
+          S: a001 OK "AUTHENTICATE completed"
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+        Here is the same example using the six-words response:
+
+          C: a001 AUTHENTICATE "OTP" {4}
+          C: <NUL>tim
+          S: + "otp-md5 499 ke1234 ext"
+          C: "word:BOND FOGY DRAB NE RISE MART"
+          S: a001 OK "AUTHENTICATE completed"
+
+        Here is the same example using the OTP-SHA1 mechanism:
+
+          C: a001 AUTHENTICATE "OTP" {4}
+          C: <NUL>tim
+          S: + "otp-sha1 499 ke1234 ext"
+          C: "hex:c90fc02cc488df5e"
+          S: a001 OK "AUTHENTICATE completed"
+
+        Here is the same example with the init-hex extended response
+
+          C: a001 AUTHENTICATE "OTP" {4}
+          C: <NUL>tim
+          S: + "otp-md5 499 ke1234 ext"
+          C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
+          S: a001 OK "OTP sequence reset, authentication complete"
+
+     The following is an example of the OTP mechanism using the IMAP
+     [IMAP4] profile of SASL.  The pass phrase used in this example is:
+          this is a test
+
+       C: a001 AUTHENTICATE OTP
+       S: +
+       C: AHRpbQ==
+       S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
+       C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
+       S: a001 OK AUTHENTICATE completed
+
+   Note that the lack of an initial client response and the base64
+   encoding are characteristics of the IMAP profile of SASL.  The server
+   challenge is "otp-md5 123 ke1234 ext" and the client response is
+   "hex:11d4c147e227c1f1".
+
+6. Security Considerations
+
+   This specification introduces no security considerations beyond those
+   those described in SASL [SASL], OTP [OTP] and OTP extended responses
+   [OTP-EXT].  A brief summary of these considerations follows:
+
+   This mechanism does not provide session privacy, server
+   authentication or protection from active attacks.
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+   This mechanism is subject to passive dictionary attacks.  The
+   severity of this attack can be reduced by choosing pass phrases well.
+
+   The server authentication database necessary for use with OTP need
+   not be plaintext-equivalent.
+
+   Server implementations MUST protect against the race attack [OTP].
+
+7. Multinational Considerations
+
+   As remote access is a crucial service, users are encouraged to
+   restrict user names and pass phrases to the US-ASCII character set.
+   However, if characters outside the US-ASCII chracter set are used in
+   user names and pass phrases, then they are interpreted according to
+   UTF-8 [UTF-8].
+
+   Server support for alternate dictionaries is strongly RECOMMENDED to
+   permit use of the six-word format with non-English words.
+
+8. IANA Considerations
+
+   Here is the registration template for the OTP SASL mechanism:
+
+   SASL mechanism name: OTP
+   Security Considerations: See section 6 of this memo
+   Published specification: this memo
+   Person & email address to contact for futher information:
+     see author's address section below
+   Intended usage: COMMON
+   Author/Change controller: see author's address section below
+
+   This memo also amends the SKEY SASL mechanism registration [SASL] by
+   changing its intended usage to OBSOLETE.
+
+9. References
+
+   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
+              Configuration Access Protocol", RFC 2244, November 1997.
+
+   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response", RFC
+              2195, September 1997.
+
+   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Newman                      Standards Track                     [Page 5]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+   [LDAPv3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+              Access Protocol (v3)", RFC 2251, December 1997.
+
+   [MD5]      Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [OTP]      Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
+              Password System", RFC 2289, February 1998.
+
+   [OTP-EXT]  Metz, C., "OTP Extended Responses", RFC 2243, November
+              1997.
+
+   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+              December 1994.
+
+   [SASL]     Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+10. Author's Address
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   EMail: chris.newman@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2444                   OTP SASL Mechanism               October 1998
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 7]
+
diff --git a/doc/rfcs/rfc2595.txt b/doc/rfcs/rfc2595.txt
new file mode 100644
index 0000000..66897cd
--- /dev/null
+++ b/doc/rfcs/rfc2595.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 2595                                      Innosoft
+Category: Standards Track                                      June 1999
+
+
+                   Using TLS with IMAP, POP3 and ACAP
+
+
+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 (1999).  All Rights Reserved.
+
+1. Motivation
+
+   The TLS protocol (formerly known as SSL) provides a way to secure an
+   application protocol from tampering and eavesdropping.  The option of
+   using such security is desirable for IMAP, POP and ACAP due to common
+   connection eavesdropping and hijacking attacks [AUTH].  Although
+   advanced SASL authentication mechanisms can provide a lightweight
+   version of this service, TLS is complimentary to simple
+   authentication-only SASL mechanisms or deployed clear-text password
+   login commands.
+
+   Many sites have a high investment in authentication infrastructure
+   (e.g., a large database of a one-way-function applied to user
+   passwords), so a privacy layer which is not tightly bound to user
+   authentication can protect against network eavesdropping attacks
+   without requiring a new authentication infrastructure and/or forcing
+   all users to change their password.  Recognizing that such sites will
+   desire simple password authentication in combination with TLS
+   encryption, this specification defines the PLAIN SASL mechanism for
+   use with protocols which lack a simple password authentication
+   command such as ACAP and SMTP.  (Note there is a separate RFC for the
+   STARTTLS command in SMTP [SMTPTLS].)
+
+   There is a strong desire in the IETF to eliminate the transmission of
+   clear-text passwords over unencrypted channels.  While SASL can be
+   used for this purpose, TLS provides an additional tool with different
+   deployability characteristics.  A server supporting both TLS with
+
+
+
+
+Newman                      Standards Track                     [Page 1]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   simple passwords and a challenge/response SASL mechanism is likely to
+   interoperate with a wide variety of clients without resorting to
+   unencrypted clear-text passwords.
+
+   The STARTTLS command rectifies a number of the problems with using a
+   separate port for a "secure" protocol variant.  Some of these are
+   mentioned in section 7.
+
+1.1. Conventions Used in this Document
+
+   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+   "MAY", and "OPTIONAL" in this document are to be interpreted as
+   described in "Key words for use in RFCs to Indicate Requirement
+   Levels" [KEYWORDS].
+
+   Terms related to authentication are defined in "On Internet
+   Authentication" [AUTH].
+
+   Formal syntax is defined using ABNF [ABNF].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+2. Basic Interoperability and Security Requirements
+
+   The following requirements apply to all implementations of the
+   STARTTLS extension for IMAP, POP3 and ACAP.
+
+2.1. Cipher Suite Requirements
+
+   Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
+   suite is REQUIRED.  This is important as it assures that any two
+   compliant implementations can be configured to interoperate.
+
+   All other cipher suites are OPTIONAL.
+
+2.2. Privacy Operational Mode Security Requirements
+
+   Both clients and servers SHOULD have a privacy operational mode which
+   refuses authentication unless successful activation of an encryption
+   layer (such as that provided by TLS) occurs prior to or at the time
+   of authentication and which will terminate the connection if that
+   encryption layer is deactivated.  Implementations are encouraged to
+   have flexability with respect to the minimal encryption strength or
+   cipher suites permitted.  A minimalist approach to this
+   recommendation would be an operational mode where the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
+   permitting authentication.
+
+
+
+Newman                      Standards Track                     [Page 2]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   Clients MAY have an operational mode which uses encryption only when
+   it is advertised by the server, but authentication continues
+   regardless.  For backwards compatibility, servers SHOULD have an
+   operational mode where only the authentication mechanisms required by
+   the relevant base protocol specification are needed to successfully
+   authenticate.
+
+2.3. Clear-Text Password Requirements
+
+   Clients and servers which implement STARTTLS MUST be configurable to
+   refuse all clear-text login commands or mechanisms (including both
+   standards-track and nonstandard mechanisms) unless an encryption
+   layer of adequate strength is active.  Servers which allow
+   unencrypted clear-text logins SHOULD be configurable to refuse
+   clear-text logins both for the entire server, and on a per-user
+   basis.
+
+2.4. Server Identity Check
+
+   During the TLS negotiation, the client MUST check its understanding
+   of the server hostname against the server's identity as presented in
+   the server Certificate message, in order to prevent man-in-the-middle
+   attacks.  Matching is performed according to these rules:
+
+   - The client MUST use the server hostname it used to open the
+     connection as the value to compare against the server name as
+     expressed in the server certificate.  The client MUST NOT use any
+     form of the server hostname derived from an insecure remote source
+     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
+
+   - If a subjectAltName extension of type dNSName is present in the
+     certificate, it SHOULD be used as the source of the server's
+     identity.
+
+   - Matching is case-insensitive.
+
+   - A "*" wildcard character MAY be used as the left-most name
+     component in the certificate.  For example, *.example.com would
+     match a.example.com, foo.example.com, etc. but would not match
+     example.com.
+
+   - If the certificate contains multiple names (e.g. more than one
+     dNSName field), then a match with any one of the fields is
+     considered acceptable.
+
+   If the match fails, the client SHOULD either ask for explicit user
+   confirmation, or terminate the connection and indicate the server's
+   identity is suspect.
+
+
+
+Newman                      Standards Track                     [Page 3]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+2.5. TLS Security Policy Check
+
+   Both the client and server MUST check the result of the STARTTLS
+   command and subsequent TLS negotiation to see whether acceptable
+   authentication or privacy was achieved.  Ignoring this step
+   completely invalidates using TLS for security.  The decision about
+   whether acceptable authentication or privacy was achieved is made
+   locally, is implementation-dependent, and is beyond the scope of this
+   document.
+
+3. IMAP STARTTLS extension
+
+   When the TLS extension is present in IMAP, "STARTTLS" is listed as a
+   capability in response to the CAPABILITY command.  This extension
+   adds a single command, "STARTTLS" to the IMAP protocol which is used
+   to begin a TLS negotiation.
+
+3.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      Once TLS has been started, the client MUST discard cached
+      information about server capabilities and SHOULD re-issue the
+      CAPABILITY command.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The server MAY advertise different capabilities
+      after STARTTLS.
+
+      The formal syntax for IMAP is amended as follows:
+
+
+
+
+Newman                      Standards Track                     [Page 4]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+        command_any   =/  "STARTTLS"
+
+   Example:    C: a001 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
+               S: a001 OK CAPABILITY completed
+               C: a002 STARTTLS
+               S: a002 OK Begin TLS negotiation now
+               <TLS negotiation, further commands are under TLS layer>
+               C: a003 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
+               S: a003 OK CAPABILITY completed
+               C: a004 LOGIN joe password
+               S: a004 OK LOGIN completed
+
+3.2. IMAP LOGINDISABLED capability
+
+   The current IMAP protocol specification (RFC 2060) requires the
+   implementation of the LOGIN command which uses clear-text passwords.
+   Many sites may choose to disable this command unless encryption is
+   active for security reasons.  An IMAP server MAY advertise that the
+   LOGIN command is disabled by including the LOGINDISABLED capability
+   in the capability response.  Such a server will respond with a tagged
+   "NO" response to any attempt to use the LOGIN command.
+
+   An IMAP server which implements STARTTLS MUST implement support for
+   the LOGINDISABLED capability on unencrypted connections.
+
+   An IMAP client which complies with this specification MUST NOT issue
+   the LOGIN command if this capability is present.
+
+   This capability is useful to prevent clients compliant with this
+   specification from sending an unencrypted password in an environment
+   subject to passive attacks.  It has no impact on an environment
+   subject to active attacks as a man-in-the-middle attacker can remove
+   this capability.  Therefore this does not relieve clients of the need
+   to follow the privacy mode recommendation in section 2.2.
+
+   Servers advertising this capability will fail to interoperate with
+   many existing compliant IMAP clients and will be unable to prevent
+   those clients from disclosing the user's password.
+
+4. POP3 STARTTLS extension
+
+   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
+   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
+   also be implemented to avoid the need for client probing of multiple
+   commands.  The capability name "STLS" indicates this command is
+   present and permitted in the current state.
+
+
+
+Newman                      Standards Track                     [Page 5]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+      STLS
+
+         Arguments: none
+
+         Restrictions:
+             Only permitted in AUTHORIZATION state.
+
+         Discussion:
+             A TLS negotiation begins immediately after the CRLF at the
+             end of the +OK response from the server.  A -ERR response
+             MAY result if a security layer is already active.  Once a
+             client issues a STLS command, it MUST NOT issue further
+             commands until a server response is seen and the TLS
+             negotiation is complete.
+
+             The STLS command is only permitted in AUTHORIZATION state
+             and the server remains in AUTHORIZATION state, even if
+             client credentials are supplied during the TLS negotiation.
+             The AUTH command [POP-AUTH] with the EXTERNAL mechanism
+             [SASL] MAY be used to authenticate once TLS client
+             credentials are successfully exchanged, but servers
+             supporting the STLS command are not required to support the
+             EXTERNAL mechanism.
+
+             Once TLS has been started, the client MUST discard cached
+             information about server capabilities and SHOULD re-issue
+             the CAPA command.  This is necessary to protect against
+             man-in-the-middle attacks which alter the capabilities list
+             prior to STLS.  The server MAY advertise different
+             capabilities after STLS.
+
+         Possible Responses:
+             +OK -ERR
+
+         Examples:
+             C: STLS
+             S: +OK Begin TLS negotiation
+             <TLS negotiation, further commands are under TLS layer>
+               ...
+             C: STLS
+             S: -ERR Command not permitted when TLS active
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                     [Page 6]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+5. ACAP STARTTLS extension
+
+   When the TLS extension is present in ACAP, "STARTTLS" is listed as a
+   capability in the ACAP greeting.  No arguments to this capability are
+   defined at this time.  This extension adds a single command,
+   "STARTTLS" to the ACAP protocol which is used to begin a TLS
+   negotiation.
+
+5.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      After the TLS layer is established, the server MUST re-issue an
+      untagged ACAP greeting.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The client MUST discard cached capability
+      information and replace it with the information from the new ACAP
+      greeting.  The server MAY advertise different capabilities after
+      STARTTLS.
+
+      The formal syntax for ACAP is amended as follows:
+
+        command_any   =/  "STARTTLS"
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+
+
+
+
+Newman                      Standards Track                     [Page 7]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+6. PLAIN SASL mechanism
+
+   Clear-text 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 an unencrypted network connection.
+
+   This defines the "PLAIN" SASL mechanism for use with ACAP and other
+   protocols with no clear-text login command.  The PLAIN SASL mechanism
+   MUST NOT be advertised or used unless a strong encryption layer (such
+   as the provided by TLS) is active or backwards compatibility dictates
+   otherwise.
+
+   The mechanism consists of a single message from the client to the
+   server.  The client sends the authorization identity (identity to
+   login as), followed by a US-ASCII NUL character, followed by the
+   authentication identity (identity whose password will be used),
+   followed by a US-ASCII NUL character, followed by the clear-text
+   password.  The client may leave the authorization identity empty to
+   indicate that it is the same as the authentication identity.
+
+   The server will verify the authentication identity and password with
+   the system authentication database and verify that the authentication
+   credentials permit the client to login as the authorization identity.
+   If both steps succeed, the user is logged in.
+
+   The server MAY also use the password to initialize any new
+   authentication database, such as one suitable for CRAM-MD5
+   [CRAM-MD5].
+
+   Non-US-ASCII characters are permitted as long as they are represented
+   in UTF-8 [UTF-8].  Use of non-visible characters or characters which
+   a user may be unable to enter on some keyboards is discouraged.
+
+   The formal grammar for the client message using Augmented BNF [ABNF]
+   follows.
+
+   message         = [authorize-id] NUL authenticate-id NUL password
+   authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+   NUL             = %x00
+   UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
+                     UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
+   UTF8-1          = %x80-BF
+   UTF8-2          = %xC0-DF UTF8-1
+   UTF8-3          = %xE0-EF 2UTF8-1
+
+
+
+Newman                      Standards Track                     [Page 8]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   UTF8-4          = %xF0-F7 3UTF8-1
+   UTF8-5          = %xF8-FB 4UTF8-1
+   UTF8-6          = %xFC-FD 5UTF8-1
+
+   Here is an example of how this might be used to initialize a CRAM-MD5
+   authentication database for ACAP:
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a001 AUTHENTICATE "CRAM-MD5"
+               S: + "<1896.697170952@postoffice.reston.mci.net>"
+               C: "tim b913a602c7eda7a495b4e6e7334d3890"
+               S: a001 NO (TRANSITION-NEEDED)
+                  "Please change your password, or use TLS to login"
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+               C: a003 AUTHENTICATE "PLAIN" {21+}
+               C: <NUL>tim<NUL>tanstaaftanstaaf
+               S: a003 OK CRAM-MD5 password initialized
+
+   Note: In this example, <NUL> represents a single ASCII NUL octet.
+
+7. imaps and pop3s ports
+
+   Separate "imaps" and "pop3s" ports were registered for use with SSL.
+   Use of these ports is discouraged in favor of the STARTTLS or STLS
+   commands.
+
+   A number of problems have been observed with separate ports for
+   "secure" variants of protocols.  This is an attempt to enumerate some
+   of those problems.
+
+   - Separate ports lead to a separate URL scheme which intrudes into
+     the user interface in inappropriate ways.  For example, many web
+     pages use language like "click here if your browser supports SSL."
+     This is a decision the browser is often more capable of making than
+     the user.
+
+   - Separate ports imply a model of either "secure" or "not secure."
+     This can be misleading in a number of ways.  First, the "secure"
+     port may not in fact be acceptably secure as an export-crippled
+     cipher suite might be in use.  This can mislead users into a false
+     sense of security.  Second, the normal port might in fact be
+     secured by using a SASL mechanism which includes a security layer.
+     Thus the separate port distinction makes the complex topic of
+     security policy even more confusing.  One common result of this
+     confusion is that firewall administrators are often misled into
+
+
+
+Newman                      Standards Track                     [Page 9]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+     permitting the "secure" port and blocking the standard port.  This
+     could be a poor choice given the common use of SSL with a 40-bit
+     key encryption layer and plain-text password authentication is less
+     secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
+
+   - Use of separate ports for SSL has caused clients to implement only
+     two security policies: use SSL or don't use SSL.  The desirable
+     security policy "use TLS when available" would be cumbersome with
+     the separate port model, but is simple with STARTTLS.
+
+   - Port numbers are a limited resource.  While they are not yet in
+     short supply, it is unwise to set a precedent that could double (or
+     worse) the speed of their consumption.
+
+
+8. IANA Considerations
+
+   This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
+   IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
+
+   The registration for the POP3 "STLS" capability follows:
+
+   CAPA tag:                   STLS
+   Arguments:                  none
+   Added commands:             STLS
+   Standard commands affected: May enable USER/PASS as a side-effect.
+     CAPA command SHOULD be re-issued after successful completion.
+   Announced states/Valid states: AUTHORIZATION state only.
+   Specification reference:    this memo
+
+   The registration for the ACAP "STARTTLS" capability follows:
+
+   Capability name:            STARTTLS
+   Capability keyword:         STARTTLS
+   Capability arguments:       none
+   Published Specification(s): this memo
+   Person and email address for further information:
+       see author's address section below
+
+   The registration for the PLAIN SASL mechanism follows:
+
+   SASL mechanism name:        PLAIN
+   Security Considerations:    See section 9 of this memo
+   Published specification:    this memo
+   Person & email address to contact for further information:
+       see author's address section below
+   Intended usage:             COMMON
+   Author/Change controller:   see author's address section below
+
+
+
+Newman                      Standards Track                    [Page 10]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+9. Security Considerations
+
+   TLS only provides protection for data sent over a network connection.
+   Messages transferred over IMAP or POP3 are still available to server
+   administrators and usually subject to eavesdropping, tampering and
+   forgery when transmitted through SMTP or NNTP.  TLS is no substitute
+   for an end-to-end message security mechanism using MIME security
+   multiparts [MIME-SEC].
+
+   A man-in-the-middle attacker can remove STARTTLS from the capability
+   list or generate a failure response to the STARTTLS command.  In
+   order to detect such an attack, clients SHOULD warn the user when
+   session privacy is not active and/or be configurable to refuse to
+   proceed without an acceptable level of security.
+
+   A man-in-the-middle attacker can always cause a down-negotiation to
+   the weakest authentication mechanism or cipher suite available.  For
+   this reason, implementations SHOULD be configurable to refuse weak
+   mechanisms or cipher suites.
+
+   Any protocol interactions prior to the TLS handshake are performed in
+   the clear and can be modified by a man-in-the-middle attacker.  For
+   this reason, clients MUST discard cached information about server
+   capabilities advertised prior to the start of the TLS handshake.
+
+   Clients are encouraged to clearly indicate when the level of
+   encryption active is known to be vulnerable to attack using modern
+   hardware (such as encryption keys with 56 bits of entropy or less).
+
+   The LOGINDISABLED IMAP capability (discussed in section 3.2) only
+   reduces the potential for passive attacks, it provides no protection
+   against active attacks.  The responsibility remains with the client
+   to avoid sending a password over a vulnerable channel.
+
+   The PLAIN mechanism relies on the TLS encryption layer for security.
+   When used without TLS, it is vulnerable to a common network
+   eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
+   unless a suitable TLS encryption layer is active or backwards
+   compatibility dictates otherwise.
+
+   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 network privacy
+   mechanisms.  While many other authentication mechanisms have similar
+   weaknesses, stronger SASL mechanisms such as Kerberos address this
+   issue.  Clients are encouraged to have an operational mode where all
+   mechanisms which are likely to reveal the user's password to the
+   server are disabled.
+
+
+
+Newman                      Standards Track                    [Page 11]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   The security considerations for TLS apply to STARTTLS and the
+   security considerations for SASL apply to the PLAIN mechanism.
+   Additional security requirements are discussed in section 2.
+
+10. References
+
+   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
+              Configuration Access Protocol", RFC 2244, November 1997.
+
+   [AUTH]     Haller, N. and R. Atkinson, "On Internet Authentication",
+              RFC 1704, October 1994.
+
+   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response", RFC
+              2195, September 1997.
+
+   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
+              4rev1", RFC 2060, December 1996.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
+              "Security Multiparts for MIME: Multipart/Signed and
+              Multipart/Encrypted", RFC 1847, October 1995.
+
+   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+              STD 53, RFC 1939, May 1996.
+
+   [POP3EXT]  Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
+              Mechanism", RFC 2449, November 1998.
+
+   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+              December 1994.
+
+   [SASL]     Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              TLS", RFC 2487, January 1999.
+
+   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+
+
+
+
+Newman                      Standards Track                    [Page 12]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+
+11. Author's Address
+
+   Chris Newman
+   Innosoft International, Inc.
+   1050 Lakes Drive
+   West Covina, CA 91790 USA
+
+   EMail: chris.newman@innosoft.com
+
+
+A. Appendix -- Compliance Checklist
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST requirements for the protocols it implements.  An
+   implementation that satisfies all the MUST and all the SHOULD
+   requirements for its protocols is said to be "unconditionally
+   compliant"; one that satisfies all the MUST requirements but not all
+   the SHOULD requirements for its protocols is said to be
+   "conditionally compliant".
+
+   Rules                                                 Section
+   -----                                                 -------
+   Mandatory-to-implement Cipher Suite                      2.1
+   SHOULD have mode where encryption required               2.2
+   server SHOULD have mode where TLS not required           2.2
+   MUST be configurable to refuse all clear-text login
+     commands or mechanisms                                 2.3
+   server SHOULD be configurable to refuse clear-text
+     login commands on entire server and on per-user basis  2.3
+   client MUST check server identity                        2.4
+   client MUST use hostname used to open connection         2.4
+   client MUST NOT use hostname from insecure remote lookup 2.4
+   client SHOULD support subjectAltName of dNSName type     2.4
+   client SHOULD ask for confirmation or terminate on fail  2.4
+   MUST check result of STARTTLS for acceptable privacy     2.5
+   client MUST NOT issue commands after STARTTLS
+      until server response and negotiation done        3.1,4,5.1
+   client MUST discard cached information             3.1,4,5.1,9
+   client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
+   IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
+   IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
+   POP server MUST implement POP3 extensions                4
+   ACAP server MUST re-issue ACAP greeting                  5.1
+
+
+
+
+Newman                      Standards Track                    [Page 13]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+   client SHOULD warn when session privacy not active and/or
+     refuse to proceed without acceptable security level    9
+   SHOULD be configurable to refuse weak mechanisms or
+     cipher suites                                          9
+
+   The PLAIN mechanism is an optional part of this specification.
+   However if it is implemented the following rules apply:
+
+   Rules                                                 Section
+   -----                                                 -------
+   MUST NOT use PLAIN unless strong encryption active
+     or backwards compatibility dictates otherwise         6,9
+   MUST use UTF-8 encoding for characters in PLAIN          6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 14]
+
+RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman                      Standards Track                    [Page 15]
+
diff --git a/doc/rfc/rfc2810.txt b/doc/rfcs/rfc2810.txt
index e628a83..e628a83 100644
--- a/doc/rfc/rfc2810.txt
+++ b/doc/rfcs/rfc2810.txt
diff --git a/doc/rfc/rfc2811.txt b/doc/rfcs/rfc2811.txt
index 7c2c4ea..7c2c4ea 100644
--- a/doc/rfc/rfc2811.txt
+++ b/doc/rfcs/rfc2811.txt
diff --git a/doc/rfc/rfc2812.txt b/doc/rfcs/rfc2812.txt
index 7f1b162..7f1b162 100644
--- a/doc/rfc/rfc2812.txt
+++ b/doc/rfcs/rfc2812.txt
diff --git a/doc/rfc/rfc2813.txt b/doc/rfcs/rfc2813.txt
index 2da3de0..2da3de0 100644
--- a/doc/rfc/rfc2813.txt
+++ b/doc/rfcs/rfc2813.txt
diff --git a/doc/rfcs/rfc4422.txt b/doc/rfcs/rfc4422.txt
new file mode 100644
index 0000000..049fa8c
--- /dev/null
+++ b/doc/rfcs/rfc4422.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                   A. Melnikov, Ed.
+Request for Comments: 4422                                 Isode Limited
+Obsoletes: 2222                                         K. Zeilenga, Ed.
+Category: Standards Track                            OpenLDAP Foundation
+                                                               June 2006
+
+
+            Simple Authentication and Security Layer (SASL)
+
+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
+
+   The Simple Authentication and Security Layer (SASL) is a framework
+   for providing authentication and data security services in
+   connection-oriented protocols via replaceable mechanisms.  It
+   provides a structured interface between protocols and mechanisms.
+   The resulting framework allows new protocols to reuse existing
+   mechanisms and allows old protocols to make use of new mechanisms.
+   The framework also provides a protocol for securing subsequent
+   protocol exchanges within a data security layer.
+
+   This document describes how a SASL mechanism is structured, describes
+   how protocols include support for SASL, and defines the protocol for
+   carrying a data security layer over a connection.  In addition, this
+   document defines one SASL mechanism, the EXTERNAL mechanism.
+
+   This document obsoletes RFC 2222.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 1]
+
+RFC 4422                          SASL                         June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Document Audiences .........................................4
+      1.2. Relationship to Other Documents ............................4
+      1.3. Conventions ................................................5
+   2. Identity Concepts ...............................................5
+   3. The Authentication Exchange .....................................6
+      3.1. Mechanism Naming ...........................................8
+      3.2. Mechanism Negotiation ......................................9
+      3.3. Request Authentication Exchange ............................9
+      3.4. Challenges and Responses ...................................9
+           3.4.1. Authorization Identity String ......................10
+      3.5. Aborting Authentication Exchanges .........................10
+      3.6. Authentication Outcome ....................................11
+      3.7. Security Layers ...........................................12
+      3.8. Multiple Authentications ..................................12
+   4. Protocol Requirements ..........................................13
+   5. Mechanism Requirements .........................................16
+   6. Security Considerations ........................................18
+      6.1. Active Attacks ............................................19
+           6.1.1. Hijack Attacks .....................................19
+           6.1.2. Downgrade Attacks ..................................19
+           6.1.3. Replay Attacks .....................................20
+           6.1.4. Truncation Attacks .................................20
+           6.1.5. Other Active Attacks ...............................20
+      6.2. Passive Attacks ...........................................20
+      6.3. Re-keying .................................................21
+      6.4. Other Considerations ......................................21
+   7. IANA Considerations ............................................22
+      7.1. SASL Mechanism Registry ...................................22
+      7.2. Registration Changes ......................................26
+   8. References .....................................................26
+      8.1. Normative References ......................................26
+      8.2. Informative References ....................................27
+   9. Acknowledgements ...............................................28
+   Appendix A.  The SASL EXTERNAL Mechanism ..........................29
+      A.1. EXTERNAL Technical Specification ..........................29
+      A.2. SASL EXTERNAL Examples ....................................30
+      A.3. Security Considerations ...................................31
+   Appendix B.  Changes since RFC 2222 ...............................31
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 2]
+
+RFC 4422                          SASL                         June 2006
+
+
+1.  Introduction
+
+   The Simple Authentication and Security Layer (SASL) is a framework
+   for providing authentication and data security services in
+   connection-oriented protocols via replaceable mechanisms.  SASL
+   provides a structured interface between protocols and mechanisms.
+   SASL also provides a protocol for securing subsequent protocol
+   exchanges within a data security layer.  The data security layer can
+   provide data integrity, data confidentiality, and other services.
+
+   SASL's design is intended to allow new protocols to reuse existing
+   mechanisms without requiring redesign of the mechanisms and allows
+   existing protocols to make use of new mechanisms without redesign of
+   protocols.
+
+   SASL is conceptually a framework that provides an abstraction layer
+   between protocols and mechanisms as illustrated in the following
+   diagram.
+
+                  SMTP    LDAP    XMPP   Other protocols ...
+                     \       |    |      /
+                      \      |    |     /
+                     SASL abstraction layer
+                      /      |    |     \
+                     /       |    |      \
+              EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...
+
+   It is through the interfaces of this abstraction layer that the
+   framework allows any protocol to utilize any mechanism.  While this
+   layer does generally hide the particulars of protocols from
+   mechanisms and the particulars of mechanisms from protocols, this
+   layer does not generally hide the particulars of mechanisms from
+   protocol implementations.  For example, different mechanisms require
+   different information to operate, some of them use password-based
+   authentication, some of then require realm information, others make
+   use of Kerberos tickets, certificates, etc.  Also, in order to
+   perform authorization, server implementations generally have to
+   implement identity mapping between authentication identities, whose
+   form is mechanism specific, and authorization identities, whose form
+   is application protocol specific.  Section 2 discusses identity
+   concepts.
+
+   It is possible to design and implement this framework in ways that do
+   abstract away particulars of similar mechanisms.  Such a framework
+   implementation, as well as mechanisms implementations, could be
+   designed not only to be shared by multiple implementations of a
+   particular protocol but to be shared by implementations of multiple
+   protocols.
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 3]
+
+RFC 4422                          SASL                         June 2006
+
+
+   The framework incorporates interfaces with both protocols and
+   mechanisms in which authentication exchanges are carried out.
+   Section 3 discusses SASL authentication exchanges.
+
+   To use SASL, each protocol (amongst other items) provides a method
+   for identifying which mechanism is to be used, a method for exchange
+   of mechanism-specific server-challenges and client-responses, and a
+   method for communicating the outcome of the authentication exchange.
+   Section 4 discusses SASL protocol requirements.
+
+   Each SASL mechanism defines (amongst other items) a series of
+   server-challenges and client-responses that provide authentication
+   services and negotiate data security services.  Section 5 discusses
+   SASL mechanism requirements.
+
+   Section 6 discusses security considerations.  Section 7 discusses
+   IANA considerations.  Appendix A defines the SASL EXTERNAL mechanism.
+
+1.1.  Document Audiences
+
+   This document is written to serve several different audiences:
+
+      -  protocol designers using this specification to support
+         authentication in their protocol,
+
+      -  mechanism designers that define new SASL mechanisms, and
+
+      -  implementors of clients or servers for those protocols that
+         support SASL.
+
+   While the document organization is intended to allow readers to focus
+   on details relevant to their engineering, readers are encouraged to
+   read and understand all aspects of this document.
+
+1.2.  Relationship to Other Documents
+
+   This document obsoletes RFC 2222.  It replaces all portions of RFC
+   2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
+   GSSAPI mechanism), 7.3 (the SKEY mechanism).  The KERBEROS_IV and
+   SKEY mechanisms are now viewed as obsolete and their specifications
+   provided in RFC 2222 are Historic.  The GSSAPI mechanism is now
+   separately specified [SASL-GSSAPI].
+
+   Appendix B provides a summary of changes since RFC 2222.
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 4]
+
+RFC 4422                          SASL                         June 2006
+
+
+1.3.  Conventions
+
+   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 BCP 14 [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+   In examples, "C:" and "S:" indicate lines of data to be sent by the
+   client and server, respectively.  Lines have been wrapped for
+   improved readability.
+
+2.  Identity Concepts
+
+   In practice, authentication and authorization may involve multiple
+   identities, possibly in different forms (simple username, Kerberos
+   principal, X.500 Distinguished Name, etc.), possibly with different
+   representations (e.g., ABNF-described UTF-8 encoded Unicode character
+   string, BER-encoded Distinguished Name).  While technical
+   specifications often prescribe both the identity form and
+   representation used on the network, different identity forms and/or
+   representations may be (and often are) used within implementations.
+   How identities of different forms relate to each other is, generally,
+   a local matter.  In addition, the forms and representations used
+   within an implementation are a local matter.
+
+   However, conceptually, the SASL framework involves two identities:
+
+      1) an identity associated with the authentication credentials
+         (termed the authentication identity), and
+
+      2) an identity to act as (termed the authorization identity).
+
+   SASL mechanism specifications describe the credential form(s) (e.g.,
+   X.509 certificates, Kerberos tickets, simple username/password) used
+   to authenticate the client, including (where appropriate) the syntax
+   and semantics of authentication identities carried in the
+   credentials.  SASL protocol specifications describe the identity
+   form(s) used in authorization and, in particular, prescribe the
+   syntax and semantics of the authorization identity character string
+   to be transferred by mechanisms.
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 5]
+
+RFC 4422                          SASL                         June 2006
+
+
+   The client provides its credentials (which include or imply an
+   authentication identity) and, optionally, a character string
+   representing the requested authorization identity as part of the SASL
+   exchange.  When this character string is omitted or empty, the client
+   is requesting to act as the identity associated with the credentials
+   (e.g., the user is requesting to act as the authentication identity).
+
+   The server is responsible for verifying the client's credentials and
+   verifying that the identity it associates with the client's
+   credentials (e.g., the authentication identity) is allowed to act as
+   the authorization identity.  A SASL exchange fails if either (or
+   both) of these verifications fails.  (The SASL exchange may fail for
+   other reasons, such as service authorization failure.)
+
+   However, the precise form(s) of the authentication identities (used
+   within the server in its verifications, or otherwise) and the precise
+   form(s) of the authorization identities (used in making authorization
+   decisions, or otherwise) are beyond the scope of SASL and this
+   specification.  In some circumstances, the precise identity forms
+   used in some context outside of the SASL exchange may be dictated by
+   other specifications.  For instance, an identity assumption
+   authorization (proxy authorization) policy specification may dictate
+   how authentication and authorization identities are represented in
+   policy statements.
+
+3.  The Authentication Exchange
+
+   Each authentication exchange consists of a message from the client to
+   the server requesting authentication via a particular mechanism,
+   followed by one or more pairs of challenges from the server and
+   responses from the client, followed by a message from the server
+   indicating the outcome of the authentication exchange.  (Note:
+   exchanges may also be aborted as discussed in Section 3.5.)
+
+   The following illustration provides a high-level overview of an
+   authentication exchange.
+
+      C: Request authentication exchange
+      S: Initial challenge
+      C: Initial response
+      <additional challenge/response messages>
+      S: Outcome of authentication exchange
+
+   If the outcome is successful and a security layer was negotiated,
+   this layer is then installed (see Section 3.7).  This also applies to
+   the following illustrations.
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 6]
+
+RFC 4422                          SASL                         June 2006
+
+
+   Some mechanisms specify that the first data sent in the
+   authentication exchange is from the client to the server.  Protocols
+   may provide an optional initial response field in the request message
+   to carry this data.  Where the mechanism specifies that the first
+   data sent in the exchange is from the client to the server, the
+   protocol provides an optional initial response field, and the client
+   uses this field, the exchange is shortened by one round-trip:
+
+      C: Request authentication exchange + Initial response
+      <additional challenge/response messages>
+      S: Outcome of authentication exchange
+
+   Where the mechanism specifies that the first data sent in the
+   exchange is from the client to the server and this field is
+   unavailable or unused, the client request is followed by an empty
+   challenge.
+
+      C: Request authentication exchange
+      S: Empty Challenge
+      C: Initial Response
+      <additional challenge/response messages>
+      S: Outcome of authentication exchange
+
+   Should a client include an initial response in its request where the
+   mechanism does not allow the client to send data first, the
+   authentication exchange fails.
+
+   Some mechanisms specify that the server is to send additional data to
+   the client when indicating a successful outcome.  Protocols may
+   provide an optional additional data field in the outcome message to
+   carry this data.  Where the mechanism specifies that the server is to
+   return additional data with the successful outcome, the protocol
+   provides an optional additional data field in the outcome message,
+   and the server uses this field, the exchange is shortened by one
+   round-trip:
+
+      C: Request authentication exchange
+      S: Initial challenge
+      C: Initial response
+      <additional challenge/response messages>
+      S: Outcome of authentication exchange with
+         additional data with success
+
+   Where the mechanism specifies that the server is to return additional
+   data to the client with a successful outcome and this field is
+   unavailable or unused, the additional data is sent as a challenge
+   whose response is empty.  After receiving this response, the server
+   then indicates the successful outcome.
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 7]
+
+RFC 4422                          SASL                         June 2006
+
+
+      C: Request authentication exchange
+      S: Initial challenge
+      C: Initial response
+      <additional challenge/response messages>
+      S: Additional data challenge
+      C: Empty Response
+      S: Outcome of authentication exchange
+
+   Where mechanisms specify that the first data sent in the exchange is
+   from the client to the server and additional data is sent to the
+   client along with indicating a successful outcome, and the protocol
+   provides fields supporting both, then the exchange takes two fewer
+   round-trips:
+
+      C: Request authentication exchange + Initial response
+      <additional challenge/response messages>
+      S: Outcome of authentication exchange
+         with additional data with success
+
+   instead of:
+
+      C: Request authentication exchange
+      S: Empty Challenge
+      C: Initial Response
+      <additional challenge/response messages>
+      S: Additional data challenge
+      C: Empty Response
+      S: Outcome of authentication exchange
+
+3.1.  Mechanism Naming
+
+   SASL mechanisms are named by character strings, from 1 to 20
+   characters in length, consisting of ASCII [ASCII] uppercase letters,
+   digits, hyphens, and/or underscores.  In the following Augmented
+   Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
+   defines the syntax of a SASL mechanism name.
+
+      sasl-mech    = 1*20mech-char
+      mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
+      ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
+      ; from ASCII character set.
+
+      UPPER-ALPHA  = %x41-5A  ; A-Z (uppercase only)
+      DIGIT        = %x30-39  ; 0-9
+      HYPHEN       = %x2D ; hyphen (-)
+      UNDERSCORE   = %x5F ; underscore (_)
+
+   SASL mechanism names are registered as discussed in Section 7.1.
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 8]
+
+RFC 4422                          SASL                         June 2006
+
+
+3.2.  Mechanism Negotiation
+
+   Mechanism negotiation is protocol specific.
+
+   Commonly, a protocol will specify that the server advertises
+   supported and available mechanisms to the client via some facility
+   provided by the protocol, and the client will then select the "best"
+   mechanism from this list that it supports and finds suitable.
+
+   Note that the mechanism negotiation is not protected by the
+   subsequent authentication exchange and hence is subject to downgrade
+   attacks if not protected by other means.
+
+   To detect downgrade attacks, a protocol can allow the client to
+   discover available mechanisms subsequent to the authentication
+   exchange and installation of data security layers with at least data
+   integrity protection.  This allows the client to detect changes to
+   the list of mechanisms supported by the server.
+
+3.3.  Request Authentication Exchange
+
+   The authentication exchange is initiated by the client by requesting
+   authentication via a mechanism it specifies.  The client sends a
+   message that contains the name of the mechanism to the server.  The
+   particulars of the message are protocol specific.
+
+   Note that the name of the mechanism is not protected by the
+   mechanism, and hence is subject to alteration by an attacker if not
+   integrity protected by other means.
+
+   Where the mechanism is defined to allow the client to send data
+   first, and the protocol's request message includes an optional
+   initial response field, the client may include the response to the
+   initial challenge in the authentication request message.
+
+3.4.  Challenges and Responses
+
+   The authentication exchange involves one or more pairs of server-
+   challenges and client-responses, the particulars of which are
+   mechanism specific.  These challenges and responses are enclosed in
+   protocol messages, the particulars of which are protocol specific.
+
+   Through these challenges and responses, the mechanism may:
+
+      -  authenticate the client to the server,
+
+      -  authenticate the server to the client,
+
+
+
+
+Melnikov & Zeilenga         Standards Track                     [Page 9]
+
+RFC 4422                          SASL                         June 2006
+
+
+      -  transfer an authorization identity string,
+
+      -  negotiate a security layer, and
+
+      -  provide other services.
+
+   The negotiation of the security layer may involve negotiation of the
+   security services to be provided in the layer, how these services
+   will be provided, and negotiation of a maximum cipher-text buffer
+   size each side is able to receive in the layer (see Section 3.6).
+
+   After receiving an authentication request or any client response, the
+   server may issue a challenge, abort the exchange, or indicate the
+   outcome of an exchange.  After receiving a challenge, a client
+   mechanism may issue a response or abort the exchange.
+
+3.4.1.  Authorization Identity String
+
+   The authorization identity string is a sequence of zero or more
+   Unicode [Unicode] characters, excluding the NUL (U+0000) character,
+   representing the identity to act as.
+
+   If the authorization identity string is absent, the client is
+   requesting to act as the identity the server associates with the
+   client's credentials.  An empty string is equivalent to an absent
+   authorization identity.
+
+   A non-empty authorization identity string indicates that the client
+   wishes to act as the identity represented by the string.  In this
+   case, the form of identity represented by the string, as well as the
+   precise syntax and semantics of the string, is protocol specific.
+
+   While the character encoding schema used to transfer the
+   authorization identity string in the authentication exchange is
+   mechanism specific, mechanisms are expected to be capable of carrying
+   the entire Unicode repertoire (with the exception of the NUL
+   character).
+
+3.5.  Aborting Authentication Exchanges
+
+   A client or server may desire to abort an authentication exchange if
+   it is unwilling or unable to continue (or enter into).
+
+   A client may abort the authentication exchange by sending a message,
+   the particulars of which are protocol specific, to the server,
+   indicating that the exchange is aborted.  The server may be required
+   by the protocol to return a message in response to the client's abort
+   message.
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 10]
+
+RFC 4422                          SASL                         June 2006
+
+
+   Likewise, a server may abort the authentication exchange by sending a
+   message, the particulars of which are protocol specific, to the
+   client, indicating that the exchange is aborted.
+
+3.6.  Authentication Outcome
+
+   At the conclusion of the authentication exchange, the server sends a
+   message, the particulars of which are protocol specific, to the
+   client indicating the outcome of the exchange.
+
+   The outcome is not successful if
+
+      -  the authentication exchange failed for any reason,
+
+      -  the client's credentials could not be verified,
+
+      -  the server cannot associate an identity with the client's
+         credentials,
+
+      -  the client-provided authorization identity string is malformed,
+
+      -  the identity associated with the client's credentials is not
+         authorized to act as the requested authorization identity,
+
+      -  the negotiated security layer (or lack thereof) is not
+         suitable, or
+
+      -  the server is not willing to provide service to the client for
+         any reason.
+
+   The protocol may include an optional additional data field in this
+   outcome message.  This field can only include additional data when
+   the outcome is successful.
+
+   If the outcome is successful and a security layer was negotiated,
+   this layer is then installed.  If the outcome is unsuccessful, or a
+   security layer was not negotiated, any existing security is left in
+   place.
+
+   The outcome message provided by the server can provide a way for the
+   client to distinguish between errors that are best dealt with by re-
+   prompting the user for her credentials, errors that are best dealt
+   with by telling the user to try again later, and errors where the
+   user must contact a system administrator for resolution (see the SYS
+   and AUTH POP Response Codes [RFC3206] specification for an example).
+   This distinction is particularly useful during scheduled server
+   maintenance periods as it reduces support costs.  It is also
+   important that the server can be configured such that the outcome
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 11]
+
+RFC 4422                          SASL                         June 2006
+
+
+   message will not distinguish between a valid user with invalid
+   credentials and an invalid user.
+
+3.7.  Security Layers
+
+   SASL mechanisms may offer a wide range of services in security
+   layers.  Typical services include data integrity and data
+   confidentiality.  SASL mechanisms that do not provide a security
+   layer are treated as negotiating no security layer.
+
+   If use of a security layer is negotiated in the authentication
+   protocol exchange, the layer is installed by the server after
+   indicating the outcome of the authentication exchange and installed
+   by the client upon receipt of the outcome indication.  In both cases,
+   the layer is installed before transfer of further protocol data.  The
+   precise position upon which the layer takes effect in the protocol
+   data stream is protocol specific.
+
+   Once the security layer is in effect in the protocol data stream, it
+   remains in effect until either a subsequently negotiated security
+   layer is installed or the underlying transport connection is closed.
+
+   When in effect, the security layer processes protocol data into
+   buffers of protected data.  If at any time the security layer is
+   unable or unwilling to continue producing buffers protecting protocol
+   data, the underlying transport connection MUST be closed.  If the
+   security layer is not able to decode a received buffer, the
+   underlying connection MUST be closed.  In both cases, the underlying
+   transport connection SHOULD be closed gracefully.
+
+   Each buffer of protected data is transferred over the underlying
+   transport connection as a sequence of octets prepended with a four-
+   octet field in network byte order that represents the length of the
+   buffer.  The length of the protected data buffer MUST be no larger
+   than the maximum size that the other side expects.  Upon the receipt
+   of a length field whose value is greater than the maximum size, the
+   receiver SHOULD close the connection, as this might be a sign of an
+   attack.
+
+   The maximum size that each side expects is fixed by the mechanism,
+   either through negotiation or by its specification.
+
+3.8.  Multiple Authentications
+
+   Unless explicitly permitted in the protocol (as stated in the
+   protocol's technical specification), only one successful SASL
+   authentication exchange may occur in a protocol session.  In this
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 12]
+
+RFC 4422                          SASL                         June 2006
+
+
+   case, once an authentication exchange has successfully completed,
+   further attempts to initiate an authentication exchange fail.
+
+   Where multiple successful SASL authentication exchanges are permitted
+   in the protocol, then in no case may multiple SASL security layers be
+   simultaneously in effect.  If a security layer is in effect and a
+   subsequent SASL negotiation selects a second security layer, then the
+   second security layer replaces the first.  If a security layer is in
+   effect and a subsequent SASL negotiation selects no security layer,
+   the original security layer remains in effect.
+
+   Where multiple successful SASL negotiations are permitted in the
+   protocol, the effect of a failed SASL authentication exchange upon
+   the previously established authentication and authorization state is
+   protocol specific.  The protocol's technical specification should be
+   consulted to determine whether the previous authentication and
+   authorization state remains in force, or changed to an anonymous
+   state, or otherwise was affected.  Regardless of the protocol-
+   specific effect upon previously established authentication and
+   authorization state, the previously negotiated security layer remains
+   in effect.
+
+4.  Protocol Requirements
+
+   In order for a protocol to offer SASL services, its specification
+   MUST supply the following information:
+
+   1) A service name, to be selected from registry of "service" elements
+      for the Generic Security Service Application Program Interface
+      (GSSAPI) host-based service name form, as described in Section 4.1
+      of [RFC2743].  Note that this registry is shared by all GSSAPI and
+      SASL mechanisms.
+
+   2) Detail any mechanism negotiation facility that the protocol
+      provides (see Section 3.2).
+
+      A protocol SHOULD specify a facility through which the client may
+      discover, both before initiation of the SASL exchange and after
+      installing security layers negotiated by the exchange, the names
+      of the SASL mechanisms that the server makes available to the
+      client.  The latter is important to allow the client to detect
+      downgrade attacks.  This facility is typically provided through
+      the protocol's extensions or capabilities discovery facility.
+
+   3) Definition of the messages necessary for authentication exchange,
+      including the following:
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 13]
+
+RFC 4422                          SASL                         June 2006
+
+
+      a) A message to initiate the authentication exchange (see Section
+         3.3).
+
+         This message MUST contain a field for carrying the name of the
+         mechanism selected by the client.
+
+         This message SHOULD contain an optional field for carrying an
+         initial response.  If the message is defined with this field,
+         the specification MUST describe how messages with an empty
+         initial response are distinguished from messages with no
+         initial response.  This field MUST be capable of carrying
+         arbitrary sequences of octets (including zero-length sequences
+         and sequences containing zero-valued octets).
+
+      b) Messages to transfer server challenges and client responses
+         (see Section 3.4).
+
+         Each of these messages MUST be capable of carrying arbitrary
+         sequences of octets (including zero-length sequences and
+         sequences containing zero-valued octets).
+
+      c) A message to indicate the outcome of the authentication
+         exchange (see Section 3.6).
+
+         This message SHOULD contain an optional field for carrying
+         additional data with a successful outcome.  If the message is
+         defined with this field, the specification MUST describe how
+         messages with an empty additional data are distinguished from
+         messages with no additional data.  This field MUST be capable
+         of carrying arbitrary sequences of octets (including zero-
+         length sequences and sequences containing zero-valued octets).
+
+   4) Prescribe the syntax and semantics of non-empty authorization
+      identity strings (see Section 3.4.1).
+
+      In order to avoid interoperability problems due to differing
+      normalizations, the protocol specification MUST detail precisely
+      how and where (client or server) non-empty authorization identity
+      strings are prepared, including all normalizations, for comparison
+      and other applicable functions to ensure proper function.
+
+      Specifications are encouraged to prescribe use of existing
+      authorization identity forms as well as existing string
+      representations, such as simple user names [RFC4013].
+
+      Where the specification does not precisely prescribe how
+      identities in SASL relate to identities used elsewhere in the
+      protocol, for instance, in access control policy statements, it
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 14]
+
+RFC 4422                          SASL                         June 2006
+
+
+      may be appropriate for the protocol to provide a facility by which
+      the client can discover information (such as the representation of
+      the identity used in making access control decisions) about
+      established identities for these uses.
+
+   5) Detail any facility the protocol provides that allows the client
+      and/or server to abort authentication exchange (see Section 3.5).
+
+      Protocols that support multiple authentications typically allow a
+      client to abort an ongoing authentication exchange by initiating a
+      new authentication exchange.  Protocols that do not support
+      multiple authentications may require the client to close the
+      connection and start over to abort an ongoing authentication
+      exchange.
+
+      Protocols typically allow the server to abort ongoing
+      authentication exchanges by returning a non-successful outcome
+      message.
+
+   6) Identify precisely where newly negotiated security layers start to
+      take effect, in both directions (see Section 3.7).
+
+      Typically, specifications require security layers to start taking
+      effect on the first octet following the outcome message in data
+      being sent by the server and on the first octet sent after receipt
+      of the outcome message in data being sent by the client.
+
+   7) If the protocol supports other layered security services, such as
+      Transport Layer Security (TLS) [RFC4346], the specification MUST
+      prescribe the order in which security layers are applied to
+      protocol data.
+
+      For instance, where a protocol supports both TLS and SASL security
+      layers, the specification could prescribe any of the following:
+
+      a) SASL security layer is always applied first to data being sent
+         and, hence, applied last to received data,
+
+      b) SASL security layer is always applied last to data being sent
+         and, hence, applied first to received data,
+
+      c) Layers are applied in the order in which they were installed,
+
+      d) Layers are applied in the reverse order in which they were
+         installed, or
+
+      e) Both TLS and SASL security layers cannot be installed.
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 15]
+
+RFC 4422                          SASL                         June 2006
+
+
+   8) Indicate whether the protocol supports multiple authentications
+      (see Section 3.8).  If so, the protocol MUST detail the effect a
+      failed SASL authentication exchange will have upon a previously
+      established authentication and authorization state.
+
+   Protocol specifications SHOULD avoid stating implementation
+   requirements that would hinder replacement of applicable mechanisms.
+   In general, protocol specifications SHOULD be mechanism neutral.
+   There are a number of reasonable exceptions to this recommendation,
+   including
+
+      -  detailing how credentials (which are mechanism specific) are
+         managed in the protocol,
+
+      -  detailing how authentication identities (which are mechanism
+         specific) and authorization identities (which are protocol
+         specific) relate to each other, and
+
+      -  detailing which mechanisms are applicable to the protocol.
+
+5.  Mechanism Requirements
+
+   SASL mechanism specifications MUST supply the following information:
+
+   1) The name of the mechanism (see Section 3.1).  This name MUST be
+      registered as discussed in Section 7.1.
+
+   2) A definition of the server-challenges and client-responses of the
+      authentication exchange, as well as the following:
+
+      a) An indication of whether the mechanism is client-first,
+         variable, or server-first.  If a SASL mechanism is defined as
+         client-first and the client does not send an initial response
+         in the authentication request, then the first server challenge
+         MUST be empty (the EXTERNAL mechanism is an example of this
+         case).  If a SASL mechanism is defined as variable, then the
+         specification needs to state how the server behaves when the
+         initial client response in the authentication request is
+         omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
+         this case).  If a SASL mechanism is defined as server-first,
+         then the client MUST NOT send an initial client response in the
+         authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
+         example of this case).
+
+      b) An indication of whether the server is expected to provide
+         additional data when indicating a successful outcome.  If so,
+         if the server sends the additional data as a challenge, the
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 16]
+
+RFC 4422                          SASL                         June 2006
+
+
+         specification MUST indicate that the response to this challenge
+         is an empty response.
+
+      SASL mechanisms SHOULD be designed to minimize the number of
+      challenges and responses necessary to complete the exchange.
+
+   3) An indication of whether the mechanism is capable of transferring
+      authorization identity strings (see Section 3.4.1).  While some
+      legacy mechanisms are incapable of transmitting an authorization
+      identity (which means that for these mechanisms, the authorization
+      identity is always the empty string), newly defined mechanisms
+      SHOULD be capable of transferring authorization identity strings.
+      The mechanism SHOULD NOT be capable of transferring both no
+      authorization identity string and an empty authorization identity.
+
+      Mechanisms that are capable of transferring an authorization
+      identity string MUST be capable of transferring arbitrary non-
+      empty sequences of Unicode characters, excluding those that
+      contain the NUL (U+0000) character.  Mechanisms SHOULD use the
+      UTF-8 [RFC3629] transformation format.  The specification MUST
+      detail how any Unicode code points special to the mechanism that
+      might appear in the authorization identity string are escaped to
+      avoid ambiguity during decoding of the authorization identity
+      string.  Typically, mechanisms that have special characters
+      require these special characters to be escaped or encoded in the
+      character string (after encoding it in a particular Unicode
+      transformation format) using a data encoding scheme such as Base64
+      [RFC3548].
+
+   4) The specification MUST detail whether the mechanism offers a
+      security layer.  If the mechanism does, the specification MUST
+      detail the security and other services offered in the layer as
+      well as how these services are to be implemented.
+
+   5) If the underlying cryptographic technology used by a mechanism
+      supports data integrity, then the mechanism specification MUST
+      integrity protect the transmission of an authorization identity
+      and the negotiation of the security layer.
+
+   SASL mechanisms SHOULD be protocol neutral.
+
+   SASL mechanisms SHOULD reuse existing credential and identity forms,
+   as well as associated syntaxes and semantics.
+
+   SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
+   for encoding Unicode [Unicode] code points for transfer.
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 17]
+
+RFC 4422                          SASL                         June 2006
+
+
+   In order to avoid interoperability problems due to differing
+   normalizations, when a mechanism calls for character data (other than
+   the authorization identity string) to be used as input to a
+   cryptographic and/or comparison function, the specification MUST
+   detail precisely how and where (client or server) the character data
+   is to be prepared, including all normalizations, for input into the
+   function to ensure proper operation.
+
+   For simple user names and/or passwords in authentication credentials,
+   SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
+   algorithm), SHOULD be specified as the preparation algorithm.
+
+   The mechanism SHOULD NOT use the authorization identity string in
+   generation of any long-term cryptographic keys or hashes as there is
+   no requirement that the authorization identity string be canonical.
+   Long-term, here, means a term longer than the duration of the
+   authentication exchange in which they were generated.  That is, as
+   different clients (of the same or different protocol) may provide
+   different authorization identity strings that are semantically
+   equivalent, use of authorization identity strings in generation of
+   cryptographic keys and hashes will likely lead to interoperability
+   and other problems.
+
+6.  Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   Many existing SASL mechanisms do not provide adequate protection
+   against passive attacks, let alone active attacks, in the
+   authentication exchange.  Many existing SASL mechanisms do not offer
+   security layers.  It is hoped that future SASL mechanisms will
+   provide strong protection against passive and active attacks in the
+   authentication exchange, as well as security layers with strong basic
+   data security features (e.g., data integrity and data
+   confidentiality) services.  It is also hoped that future mechanisms
+   will provide more advanced data security services like re-keying (see
+   Section 6.3).
+
+   Regardless, the SASL framework is susceptible to downgrade attacks.
+   Section 6.1.2 offers a variety of approaches for preventing or
+   detecting these attacks.  In some cases, it is appropriate to use
+   data integrity protective services external to SASL (e.g., TLS) to
+   protect against downgrade attacks in SASL.  Use of external
+   protective security services is also important when the mechanisms
+   available do not themselves offer adequate integrity and/or
+   confidentiality protection of the authentication exchange and/or
+   protocol data.
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 18]
+
+RFC 4422                          SASL                         June 2006
+
+
+6.1.  Active Attacks
+
+6.1.1.  Hijack Attacks
+
+   When the client selects a SASL security layer with at least integrity
+   protection, this protection serves as a counter-measure against an
+   active attacker hijacking the connection and modifying protocol data
+   sent after establishment of the security layer.  Implementations
+   SHOULD close the connection when the security services in a SASL
+   security layer report protocol data report lack of data integrity.
+
+6.1.2.  Downgrade Attacks
+
+   It is important that any security-sensitive protocol negotiations be
+   performed after installation of a security layer with data integrity
+   protection.  Protocols should be designed such that negotiations
+   performed prior to this installation should be revalidated after
+   installation is complete.  Negotiation of the SASL mechanism is
+   security sensitive.
+
+   When a client negotiates the authentication mechanism with the server
+   and/or other security features, it is possible for an active attacker
+   to cause a party to use the least secure security services available.
+   For instance, an attacker can modify the server-advertised mechanism
+   list or can modify the client-advertised security feature list within
+   a mechanism response.  To protect against this sort of attack,
+   implementations SHOULD NOT advertise mechanisms and/or features that
+   cannot meet their minimum security requirements, SHOULD NOT enter
+   into or continue authentication exchanges that cannot meet their
+   minimum security requirements, and SHOULD verify that completed
+   authentication exchanges result in security services that meet their
+   minimum security requirements.  Note that each endpoint needs to
+   independently verify that its security requirements are met.
+
+   In order to detect downgrade attacks to the least (or less) secure
+   mechanism supported, the client can discover the SASL mechanisms that
+   the server makes available both before the SASL authentication
+   exchange and after the negotiated SASL security layer (with at least
+   data integrity protection) has been installed through the protocol's
+   mechanism discovery facility.  If the client finds that the
+   integrity-protected list (the list obtained after the security layer
+   was installed) contains a stronger mechanism than those in the
+   previously obtained list, the client should assume that the
+   previously obtained list was modified by an attacker and SHOULD close
+   the underlying transport connection.
+
+   The client's initiation of the SASL exchange, including the selection
+   of a SASL mechanism, is done in the clear and may be modified by an
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 19]
+
+RFC 4422                          SASL                         June 2006
+
+
+   active attacker.  It is important for any new SASL mechanisms to be
+   designed such that an active attacker cannot obtain an authentication
+   with weaker security properties by modifying the SASL mechanism name
+   and/or the challenges and responses.
+
+   Multi-level negotiation of security features is prone to downgrade
+   attack.  Protocol designers should avoid offering higher-level
+   negotiation of security features in protocols (e.g., above SASL
+   mechanism negotiation) and mechanism designers should avoid lower-
+   level negotiation of security features in mechanisms (e.g., below
+   SASL mechanism negotiation).
+
+6.1.3.  Replay Attacks
+
+   Some mechanisms may be subject to replay attacks unless protected by
+   external data security services (e.g., TLS).
+
+6.1.4.  Truncation Attacks
+
+   Most existing SASL security layers do not themselves offer protection
+   against truncation attack.  In a truncation attack, the active
+   attacker causes the protocol session to be closed, causing a
+   truncation of the possibly integrity-protected data stream that leads
+   to behavior of one or both the protocol peers that inappropriately
+   benefits the attacker.  Truncation attacks are fairly easy to defend
+   against in connection-oriented application-level protocols.  A
+   protocol can defend against these attacks by ensuring that each
+   information exchange has a clear final result and that each protocol
+   session has a graceful closure mechanism, and that these are
+   integrity protected.
+
+6.1.5.  Other Active Attacks
+
+   When use of a security layer is negotiated by the authentication
+   protocol exchange, the receiver SHOULD handle gracefully any
+   protected data buffer larger than the defined/negotiated maximal
+   size.  In particular, it MUST NOT blindly allocate the amount of
+   memory specified in the buffer size field, as this might cause the
+   "out of memory" condition.  If the receiver detects a large block, it
+   SHOULD close the connection.
+
+6.2.  Passive Attacks
+
+   Many mechanisms are subject to various passive attacks, including
+   simple eavesdropping of unprotected credential information as well as
+   online and offline dictionary attacks of protected credential
+   information.
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 20]
+
+RFC 4422                          SASL                         June 2006
+
+
+6.3.  Re-keying
+
+   The secure or administratively permitted lifetimes of SASL
+   mechanisms' security layers are finite.  Cryptographic keys weaken as
+   they are used and as time passes; the more time and/or cipher-text
+   that a cryptanalyst has after the first use of the a key, the easier
+   it is for the cryptanalyst to mount attacks on the key.
+
+   Administrative limits on a security layer's lifetime may take the
+   form of time limits expressed in X.509 certificates, in Kerberos V
+   tickets, or in directories, and are often desired.  In practice, one
+   likely effect of administrative lifetime limits is that applications
+   may find that security layers stop working in the middle of
+   application protocol operation, such as, perhaps, during large data
+   transfers.  As the result of this, the connection will be closed (see
+   Section 3.7), which will result in an unpleasant user experience.
+
+   Re-keying (key renegotiation process) is a way of addressing the
+   weakening of cryptographic keys.  The SASL framework does not itself
+   provide for re-keying; SASL mechanisms may.  Designers of future SASL
+   mechanisms should consider providing re-keying services.
+
+   Implementations that wish to re-key SASL security layers where the
+   mechanism does not provide for re-keying SHOULD reauthenticate the
+   same IDs and replace the expired or soon-to-expire security layers.
+   This approach requires support for reauthentication in the
+   application protocols (see Section 3.8).
+
+6.4.  Other Considerations
+
+   Protocol designers and implementors should understand the security
+   considerations of mechanisms so they may select mechanisms that are
+   applicable to their needs.
+
+   Distributed server implementations need to be careful in how they
+   trust other parties.  In particular, authentication secrets should
+   only be disclosed to other parties that are trusted to manage and use
+   those secrets in a manner acceptable to the disclosing party.
+   Applications using SASL assume that SASL security layers providing
+   data confidentiality are secure even when an attacker chooses the
+   text to be protected by the security layer.  Similarly, applications
+   assume that the SASL security layer is secure even if the attacker
+   can manipulate the cipher-text output of the security layer.  New
+   SASL mechanisms are expected to meet these assumptions.
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 21]
+
+RFC 4422                          SASL                         June 2006
+
+
+   Unicode security considerations [UTR36] apply to authorization
+   identity strings, as well as UTF-8 [RFC3629] security considerations
+   where UTF-8 is used.  SASLprep [RFC4013] and StringPrep [RFC3454]
+   security considerations also apply where used.
+
+7.  IANA Considerations
+
+7.1.  SASL Mechanism Registry
+
+   The SASL mechanism registry is maintained by IANA.  The registry is
+   currently available at <http://www.iana.org/assignments/sasl-
+   mechanisms>.
+
+   The purpose of this registry is not only to ensure uniqueness of
+   values used to name SASL mechanisms, but also to provide a definitive
+   reference to technical specifications detailing each SASL mechanism
+   available for use on the Internet.
+
+   There is no naming convention for SASL mechanisms; any name that
+   conforms to the syntax of a SASL mechanism name can be registered.
+
+   The procedure detailed in Section 7.1.1 is to be used for
+   registration of a value naming a specific individual mechanism.
+
+   The procedure detailed in Section 7.1.2 is to be used for
+   registration of a value naming a family of related mechanisms.
+
+   Comments may be included in the registry as discussed in Section
+   7.1.3 and may be changed as discussed in Section 7.1.4.
+
+   The SASL mechanism registry has been updated to reflect that this
+   document provides the definitive technical specification for SASL and
+   that this section provides the registration procedures for this
+   registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 22]
+
+RFC 4422                          SASL                         June 2006
+
+
+7.1.1.  Mechanism Name Registration Procedure
+
+   IANA will register new SASL mechanism names on a First Come First
+   Served basis, as defined in BCP 26 [RFC2434].  IANA has the right to
+   reject obviously bogus registration requests, but will perform no
+   review of claims made in the registration form.
+
+   Registration of a SASL mechanism is requested by filling in the
+   following template:
+
+      Subject: Registration of SASL mechanism X
+
+      SASL mechanism name (or prefix for the family):
+
+      Security considerations:
+
+      Published specification (recommended):
+
+      Person & email address to contact for further information:
+
+      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
+
+      Owner/Change controller:
+
+      Note: (Any other information that the author deems relevant may be
+      added here.)
+
+   and sending it via electronic mail to IANA at <iana@iana.org>.
+
+   While this registration procedure does not require expert review,
+   authors of SASL mechanisms are encouraged to seek community review
+   and comment whenever that is feasible.  Authors may seek community
+   review by posting a specification of their proposed mechanism as an
+   Internet-Draft.  SASL mechanisms intended for widespread use should
+   be standardized through the normal IETF process, when appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 23]
+
+RFC 4422                          SASL                         June 2006
+
+
+7.1.2.  Family Name Registration Procedure
+
+   As noted above, there is no general naming convention for SASL
+   mechanisms.  However, specifications may reserve a portion of the
+   SASL mechanism namespace for a set of related SASL mechanisms, a
+   "family" of SASL mechanisms.  Each family of SASL mechanisms is
+   identified by a unique prefix, such as X-.  Registration of new SASL
+   mechanism family names requires expert review as defined in BCP 26
+   [RFC2434].
+
+   Registration of a SASL family name is requested by filling in the
+   following template:
+
+      Subject: Registration of SASL mechanism family X
+
+      SASL family name (or prefix for the family):
+
+      Security considerations:
+
+      Published specification (recommended):
+
+      Person & email address to contact for further information:
+
+      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
+
+      Owner/Change controller:
+
+      Note: (Any other information that the author deems relevant may be
+      added here.)
+
+   and sending it via electronic mail to the IETF SASL mailing list at
+   <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>.
+   After allowing two weeks for community input on the IETF SASL mailing
+   list, the expert will determine the appropriateness of the
+   registration request and either approve or disapprove the request
+   with notice to the requestor, the mailing list, and IANA.
+
+   The review should focus on the appropriateness of the requested
+   family name for the proposed use and the appropriateness of the
+   proposed naming and registration plan for existing and future
+   mechanism names in the family.  The scope of this request review may
+   entail consideration of relevant aspects of any provided technical
+   specification, such as their IANA Considerations section.  However,
+   this review is narrowly focused on the appropriateness of the
+   requested registration and not on the overall soundness of any
+   provided technical specification.
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 24]
+
+RFC 4422                          SASL                         June 2006
+
+
+   Authors are encouraged to pursue community review by posting the
+   technical specification as an Internet-Draft and soliciting comment
+   by posting to appropriate IETF mailing lists.
+
+7.1.3.  Comments on SASL Mechanism Registrations
+
+   Comments on a registered SASL mechanism/family should first be sent
+   to the "owner" of the mechanism/family and/or to the <ietf-
+   sasl@imc.org> mailing list.
+
+   Submitters of comments may, after a reasonable attempt to contact the
+   owner, request IANA to attach their comment to the SASL mechanism
+   registration itself by sending mail to <iana@iana.org>.  At IANA's
+   sole discretion, IANA may attach the comment to the SASL mechanism's
+   registration.
+
+7.1.4.  Change Control
+
+   Once a SASL mechanism registration has been published by IANA, the
+   author may request a change to its definition.  The change request
+   follows the same procedure as the registration request.
+
+   The owner of a SASL mechanism may pass responsibility for the SASL
+   mechanism to another person or agency by informing IANA; this can be
+   done without discussion or review.
+
+   The IESG may reassign responsibility for a SASL mechanism.  The most
+   common case of this will be to enable changes to be made to
+   mechanisms where the author of the registration has died, has moved
+   out of contact, or is otherwise unable to make changes that are
+   important to the community.
+
+   SASL mechanism registrations may not be deleted; mechanisms that are
+   no longer believed appropriate for use can be declared OBSOLETE by a
+   change to their "intended usage" field; such SASL mechanisms will be
+   clearly marked in the lists published by IANA.
+
+   The IESG is considered to be the owner of all SASL mechanisms that
+   are on the IETF standards track.
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 25]
+
+RFC 4422                          SASL                         June 2006
+
+
+7.2.  Registration Changes
+
+   The IANA has updated the SASL mechanisms registry as follows:
+
+   1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
+      registrations to OBSOLETE.
+
+   2) Changed the "Published specification" of the EXTERNAL mechanism to
+      this document as indicated below:
+
+      Subject: Updated Registration of SASL mechanism EXTERNAL
+      Family of SASL mechanisms: NO
+      SASL mechanism name: EXTERNAL
+      Security considerations: See A.3 of RFC 4422
+      Published specification (optional, recommended): RFC 4422
+      Person & email address to contact for further information:
+          Alexey Melnikov <Alexey.Melnikov@isode.com>
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+      Note: Updates existing entry for EXTERNAL
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2244]     Newman, C. and J. G. Myers, "ACAP -- Application
+                 Configuration Access Protocol", RFC 2244, November
+                 1997.
+
+   [RFC2434]     Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26, RFC
+                 2434, October 1998.
+
+   [RFC2743]     Linn, J., "Generic Security Service Application Program
+                 Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ("stringprep")", RFC 3454,
+                 December 2002.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
+                 Names and Passwords", RFC 4013, February 2005.
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 26]
+
+RFC 4422                          SASL                         June 2006
+
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [ASCII]       Coded Character Set--7-bit American Standard Code for
+                 Information Interchange, ANSI X3.4-1986.
+
+   [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/).
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+8.2.  Informative References
+
+   [RFC3206]     Gellens, R., "The SYS and AUTH POP Response Codes", RFC
+                 3206, February 2002.
+
+   [RFC3548]     Josefsson, S., "The Base16, Base32, and Base64 Data
+                 Encodings", RFC 3548, July 2003.
+
+   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
+                 Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4346]     Dierks, T. and E. Rescorla, "The Transport Layer
+                 Security (TLS) Protocol Version 1.1", RFC 4346, April
+                 2006.
+
+   [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
+                 Mechanism", Work in Progress, May 2006.
+
+   [UTR36]       Davis, M., "(Draft) Unicode Technical Report #36,
+                 Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr36/>,
+                 February 2005.
+
+   [CRAM-MD5]    Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
+                 Progress.
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 27]
+
+RFC 4422                          SASL                         June 2006
+
+
+   [DIGEST-MD5]  Leach, P., C. Newman, and A. Melnikov, "Using Digest
+                 Authentication as a SASL Mechanism", Work in Progress,
+                 March 2006.
+
+9.  Acknowledgements
+
+   This document is a revision of RFC 2222 written by John Myers.
+
+   This revision is a product of the IETF Simple Authentication and
+   Security Layer (SASL) Working Group.
+
+   The following individuals contributed significantly to this revision:
+   Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
+   Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
+   'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
+   Alsop, and Tony Hansen.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 28]
+
+RFC 4422                          SASL                         June 2006
+
+
+Appendix A.  The SASL EXTERNAL Mechanism
+
+   This appendix is normative.
+
+   The EXTERNAL mechanism allows a client to request the server to use
+   credentials established by means external to the mechanism to
+   authenticate the client.  The external means may be, for instance, IP
+   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
+   priori agreement between the client and the server, the client cannot
+   make any assumption as to what external means the server has used to
+   obtain the client's credentials, nor make an assumption as to the
+   form of credentials.  For example, the client cannot assume that the
+   server will use the credentials the client has established via TLS.
+
+A.1.  EXTERNAL Technical Specification
+
+   The name of this mechanism is "EXTERNAL".
+
+   The mechanism does not provide a security layer.
+
+   The mechanism is capable of transferring an authorization identity
+   string.  If empty, the client is requesting to act as the identity
+   the server has associated with the client's credentials.  If non-
+   empty, the client is requesting to act as the identity represented by
+   the string.
+
+   The client is expected to send data first in the authentication
+   exchange.  Where the client does not provide an initial response data
+   in its request to initiate the authentication exchange, the server is
+   to respond to the request with an empty initial challenge and then
+   the client is to provide its initial response.
+
+   The client sends the initial response containing the UTF-8 [RFC3629]
+   encoding of the requested authorization identity string.  This
+   response is non-empty when the client is requesting to act as the
+   identity represented by the (non-empty) string.  This response is
+   empty when the client is requesting to act as the identity the server
+   associated with its authentication credentials.
+
+   The syntax of the initial response is specified as a value of the
+   <extern-initial-resp> production detailed below using the Augmented
+   Backus-Naur Form (ABNF) [RFC4234] notation.
+
+      external-initial-resp = authz-id-string
+      authz-id-string       = *( UTF8-char-no-nul )
+      UTF8-char-no-nul      = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
+      UTF8-1-no-nul         = %x01-7F
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 29]
+
+RFC 4422                          SASL                         June 2006
+
+
+   where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
+   in [RFC3629].
+
+   There are no additional challenges and responses.
+
+   Hence, the server is to return the outcome of the authentication
+   exchange.
+
+   The exchange fails if
+
+   -  the client has not established its credentials via external means,
+
+   -  the client's credentials are inadequate,
+
+   -  the client provided an empty authorization identity string and the
+      server is unwilling or unable to associate an authorization
+      identity with the client's credentials,
+
+   -  the client provided a non-empty authorization identity string that
+      is invalid per the syntax requirements of the applicable
+      application protocol specification,
+
+   -  the client provided a non-empty authorization identity string
+      representing an identity that the client is not allowed to act as,
+      or
+
+   -  the server is unwilling or unable to provide service to the client
+      for any other reason.
+
+   Otherwise the exchange is successful.  When indicating a successful
+   outcome, additional data is not provided.
+
+A.2.  SASL EXTERNAL Examples
+
+   This section provides examples of EXTERNAL authentication exchanges.
+   The examples are intended to help the readers understand the above
+   text.  The examples are not definitive.  The Application
+   Configuration Access Protocol (ACAP) [RFC2244] is used in the
+   examples.
+
+   The first example shows use of EXTERNAL with an empty authorization
+   identity.  In this example, the initial response is not sent in the
+   client's request to initiate the authentication exchange.
+
+      S: * ACAP (SASL "DIGEST-MD5")
+      C: a001 STARTTLS
+      S: a001 OK "Begin TLS negotiation now"
+      <TLS negotiation, further commands are under TLS layer>
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 30]
+
+RFC 4422                          SASL                         June 2006
+
+
+      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
+      C: a002 AUTHENTICATE "EXTERNAL"
+      S: + ""
+      C: + ""
+      S: a002 OK "Authenticated"
+
+   The second example shows use of EXTERNAL with an authorization
+   identity of "fred@example.com".  In this example, the initial
+   response is sent with the client's request to initiate the
+   authentication exchange.  This saves a round-trip.
+
+      S: * ACAP (SASL "DIGEST-MD5")
+      C: a001 STARTTLS
+      S: a001 OK "Begin TLS negotiation now"
+      <TLS negotiation, further commands are under TLS layer>
+      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
+      C: a002 AUTHENTICATE "EXTERNAL" {16+}
+      C: fred@example.com
+      S: a002 NO "Cannot assume requested authorization identity"
+
+A.3.  Security Considerations
+
+   The EXTERNAL mechanism provides no security protection; it is
+   vulnerable to spoofing by either client or server, active attack, and
+   eavesdropping.  It should only be used when adequate security
+   services have been established.
+
+Appendix B.  Changes since RFC 2222
+
+   This appendix is non-normative.
+
+   The material in RFC 2222 was significantly rewritten in the
+   production of this document.
+
+   RFC 2222, by not stating that the authorization identity string was a
+   string of Unicode characters, let alone character data, implied that
+   the authorization identity string was a string of octets.
+
+   -  The authorization identity string is now defined as a string of
+      Unicode characters.  The NUL (U+0000) character is prohibited.
+      While protocol specifications are responsible for defining the
+      authorization identity form, as well as the Unicode string syntax
+      and related semantics, mechanism specifications are responsible
+      for defining how the Unicode string is carried in the
+      authentication exchange.
+
+   -  Deleted "If so, when the client does not send data first, the
+      initial challenge MUST be specified as being an empty challenge."
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 31]
+
+RFC 4422                          SASL                         June 2006
+
+
+   The following technical change was made to the EXTERNAL mechanism:
+
+      - The authorization identity string is to be UTF-8 encoded.
+
+      Note that protocol and mechanism specification requirements have
+      been significantly tightened.  Existing protocol and mechanism
+      specifications will need to be updated to meet these requirements.
+
+Editors' Addresses
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex,
+   TW12 2BX, United Kingdom
+
+   EMail: Alexey.Melnikov@isode.com
+   URI:   http://www.melnikov.ca/
+
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 32]
+
+RFC 4422                          SASL                         June 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).
+
+
+
+
+
+
+
+Melnikov & Zeilenga         Standards Track                    [Page 33]
+
diff --git a/doc/rfcs/rfc4616.txt b/doc/rfcs/rfc4616.txt
new file mode 100644
index 0000000..991189d
--- /dev/null
+++ b/doc/rfcs/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]
+
diff --git a/doc/rfcs/rfc5802.txt b/doc/rfcs/rfc5802.txt
new file mode 100644
index 0000000..971003a
--- /dev/null
+++ b/doc/rfcs/rfc5802.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         C. Newman
+Request for Comments: 5802                                        Oracle
+Category: Standards Track                                   A. Menon-Sen
+ISSN: 2070-1721                                   Oryx Mail Systems GmbH
+                                                             A. Melnikov
+                                                             Isode, Ltd.
+                                                             N. Williams
+                                                                  Oracle
+                                                               July 2010
+
+
+       Salted Challenge Response Authentication Mechanism (SCRAM)
+                      SASL and GSS-API Mechanisms
+
+Abstract
+
+   The secure authentication mechanism most widely deployed and used by
+   Internet application protocols is the transmission of clear-text
+   passwords over a channel protected by Transport Layer Security (TLS).
+   There are some significant security concerns with that mechanism,
+   which could be addressed by the use of a challenge response
+   authentication mechanism protected by TLS.  Unfortunately, the
+   challenge response mechanisms presently on the standards track all
+   fail to meet requirements necessary for widespread deployment, and
+   have had success only in limited use.
+
+   This specification describes a family of Simple Authentication and
+   Security Layer (SASL; RFC 4422) authentication mechanisms called the
+   Salted Challenge Response Authentication Mechanism (SCRAM), which
+   addresses the security concerns and meets the deployability
+   requirements.  When used in combination with TLS or an equivalent
+   security layer, a mechanism from this family could improve the status
+   quo for application protocol authentication and provide a suitable
+   choice for a mandatory-to-implement mechanism for future application
+   protocol standards.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 1]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5802.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 2]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions Used in This Document ...............................5
+      2.1. Terminology ................................................5
+      2.2. Notation ...................................................6
+   3. SCRAM Algorithm Overview ........................................7
+   4. SCRAM Mechanism Names ...........................................8
+   5. SCRAM Authentication Exchange ...................................9
+      5.1. SCRAM Attributes ..........................................10
+      5.2. Compliance with SASL Mechanism Requirements ...............13
+   6. Channel Binding ................................................14
+      6.1. Default Channel Binding ...................................15
+   7. Formal Syntax ..................................................15
+   8. SCRAM as a GSS-API Mechanism ...................................19
+      8.1. GSS-API Principal Name Types for SCRAM ....................19
+      8.2. GSS-API Per-Message Tokens for SCRAM ......................20
+      8.3. GSS_Pseudo_random() for SCRAM .............................20
+   9. Security Considerations ........................................20
+   10. IANA Considerations ...........................................22
+   11. Acknowledgements ..............................................23
+   12. References ....................................................24
+      12.1. Normative References .....................................24
+      12.2. Normative References for GSS-API Implementors ............24
+      12.3. Informative References ...................................25
+   Appendix A. Other Authentication Mechanisms .......................27
+   Appendix B. Design Motivations ....................................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 3]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+1.  Introduction
+
+   This specification describes a family of authentication mechanisms
+   called the Salted Challenge Response Authentication Mechanism (SCRAM)
+   which addresses the requirements necessary to deploy a challenge-
+   response mechanism more widely than past attempts (see Appendix A and
+   Appendix B).  When used in combination with Transport Layer Security
+   (TLS; see [RFC5246]) or an equivalent security layer, a mechanism
+   from this family could improve the status quo for application
+   protocol authentication and provide a suitable choice for a
+   mandatory-to-implement mechanism for future application protocol
+   standards.
+
+   For simplicity, this family of mechanisms does not presently include
+   negotiation of a security layer [RFC4422].  It is intended to be used
+   with an external security layer such as that provided by TLS or SSH,
+   with optional channel binding [RFC5056] to the external security
+   layer.
+
+   SCRAM is specified herein as a pure Simple Authentication and
+   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
+   bridge between SASL and the Generic Security Service Application
+   Program Interface (GSS-API) called "GS2" [RFC5801].  This means that
+   this document defines both, a SASL mechanism and a GSS-API mechanism.
+
+   SCRAM provides the following protocol features:
+
+   o  The authentication information stored in the authentication
+      database is not sufficient by itself to impersonate the client.
+      The information is salted to prevent a pre-stored dictionary
+      attack if the database is stolen.
+
+   o  The server does not gain the ability to impersonate the client to
+      other servers (with an exception for server-authorized proxies).
+
+   o  The mechanism permits the use of a server-authorized proxy without
+      requiring that proxy to have super-user rights with the back-end
+      server.
+
+   o  Mutual authentication is supported, but only the client is named
+      (i.e., the server has no name).
+
+   o  When used as a SASL mechanism, SCRAM is capable of transporting
+      authorization identities (see [RFC4422], Section 2) from the
+      client to the server.
+
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 4]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   A separate document defines a standard LDAPv3 [RFC4510] attribute
+   that enables storage of the SCRAM authentication information in LDAP.
+   See [RFC5803].
+
+   For an in-depth discussion of why other challenge response mechanisms
+   are not considered sufficient, see Appendix A.  For more information
+   about the motivations behind the design of this mechanism, see
+   Appendix B.
+
+2.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+   Formal syntax is defined by [RFC5234] including the core rules
+   defined in Appendix B of [RFC5234].
+
+   Example lines prefaced by "C:" are sent by the client and ones
+   prefaced by "S:" by the server.  If a single "C:" or "S:" label
+   applies to multiple lines, then the line breaks between those lines
+   are for editorial clarity only, and are not part of the actual
+   protocol exchange.
+
+2.1.  Terminology
+
+   This document uses several terms defined in [RFC4949] ("Internet
+   Security Glossary") including the following: authentication,
+   authentication exchange, authentication information, brute force,
+   challenge-response, cryptographic hash function, dictionary attack,
+   eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
+   one-way encryption function, password, replay attack, and salt.
+   Readers not familiar with these terms should use that glossary as a
+   reference.
+
+   Some clarifications and additional definitions follow:
+
+   o  Authentication information: Information used to verify an identity
+      claimed by a SCRAM client.  The authentication information for a
+      SCRAM identity consists of salt, iteration count, "StoredKey" and
+      "ServerKey" (as defined in the algorithm overview) for each
+      supported cryptographic hash function.
+
+   o  Authentication database: The database used to look up the
+      authentication information associated with a particular identity.
+      For application protocols, LDAPv3 (see [RFC4510]) is frequently
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 5]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+      used as the authentication database.  For network-level protocols
+      such as PPP or 802.11x, the use of RADIUS [RFC2865] is more
+      common.
+
+   o  Base64: An encoding mechanism defined in [RFC4648] that converts
+      an octet string input to a textual output string that can be
+      easily displayed to a human.  The use of base64 in SCRAM is
+      restricted to the canonical form with no whitespace.
+
+   o  Octet: An 8-bit byte.
+
+   o  Octet string: A sequence of 8-bit bytes.
+
+   o  Salt: A random octet string that is combined with a password
+      before applying a one-way encryption function.  This value is used
+      to protect passwords that are stored in an authentication
+      database.
+
+2.2.  Notation
+
+   The pseudocode description of the algorithm uses the following
+   notations:
+
+   o  ":=": The variable on the left-hand side represents the octet
+      string resulting from the expression on the right-hand side.
+
+   o  "+": Octet string concatenation.
+
+   o  "[ ]": A portion of an expression enclosed in "[" and "]" may not
+      be included in the result under some circumstances.  See the
+      associated text for a description of those circumstances.
+
+   o  Normalize(str): Apply the SASLprep profile [RFC4013] of the
+      "stringprep" algorithm [RFC3454] as the normalization algorithm to
+      a UTF-8 [RFC3629] encoded "str".  The resulting string is also in
+      UTF-8.  When applying SASLprep, "str" is treated as a "stored
+      strings", which means that unassigned Unicode codepoints are
+      prohibited (see Section 7 of [RFC3454]).  Note that
+      implementations MUST either implement SASLprep or disallow use of
+      non US-ASCII Unicode codepoints in "str".
+
+   o  HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
+      [RFC2104]) using the octet string represented by "key" as the key
+      and the octet string "str" as the input string.  The size of the
+      result is the hash result size for the hash function in use.  For
+      example, it is 20 octets for SHA-1 (see [RFC3174]).
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 6]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   o  H(str): Apply the cryptographic hash function to the octet string
+      "str", producing an octet string as a result.  The size of the
+      result depends on the hash result size for the hash function in
+      use.
+
+   o  XOR: Apply the exclusive-or operation to combine the octet string
+      on the left of this operator with the octet string on the right of
+      this operator.  The length of the output and each of the two
+      inputs will be the same for this use.
+
+   o  Hi(str, salt, i):
+
+     U1   := HMAC(str, salt + INT(1))
+     U2   := HMAC(str, U1)
+     ...
+     Ui-1 := HMAC(str, Ui-2)
+     Ui   := HMAC(str, Ui-1)
+
+     Hi := U1 XOR U2 XOR ... XOR Ui
+
+      where "i" is the iteration count, "+" is the string concatenation
+      operator, and INT(g) is a 4-octet encoding of the integer g, most
+      significant octet first.
+
+      Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the
+      pseudorandom function (PRF) and with dkLen == output length of
+      HMAC() == output length of H().
+
+3.  SCRAM Algorithm Overview
+
+   The following is a description of a full, uncompressed SASL SCRAM
+   authentication exchange.  Nothing in SCRAM prevents either sending
+   the client-first message with the SASL authentication request defined
+   by an application protocol ("initial client response"), or sending
+   the server-final message as additional data of the SASL outcome of
+   authentication exchange defined by an application protocol.  See
+   [RFC4422] for more details.
+
+   Note that this section omits some details, such as client and server
+   nonces.  See Section 5 for more details.
+
+   To begin with, the SCRAM client is in possession of a username and
+   password (*) (or a ClientKey/ServerKey, or SaltedPassword).  It sends
+   the username to the server, which retrieves the corresponding
+   authentication information, i.e., a salt, StoredKey, ServerKey, and
+   the iteration count i.  (Note that a server implementation may choose
+
+
+
+
+
+Newman, et al.               Standards Track                    [Page 7]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   to use the same iteration count for all accounts.)  The server sends
+   the salt and the iteration count to the client, which then computes
+   the following values and sends a ClientProof to the server:
+
+   (*) Note that both the username and the password MUST be encoded in
+   UTF-8 [RFC3629].
+
+   Informative Note: Implementors are encouraged to create test cases
+   that use both usernames and passwords with non-ASCII codepoints.  In
+   particular, it's useful to test codepoints whose "Unicode
+   Normalization Form C" and "Unicode Normalization Form KC" are
+   different.  Some examples of such codepoints include Vulgar Fraction
+   One Half (U+00BD) and Acute Accent (U+00B4).
+
+     SaltedPassword  := Hi(Normalize(password), salt, i)
+     ClientKey       := HMAC(SaltedPassword, "Client Key")
+     StoredKey       := H(ClientKey)
+     AuthMessage     := client-first-message-bare + "," +
+                        server-first-message + "," +
+                        client-final-message-without-proof
+     ClientSignature := HMAC(StoredKey, AuthMessage)
+     ClientProof     := ClientKey XOR ClientSignature
+     ServerKey       := HMAC(SaltedPassword, "Server Key")
+     ServerSignature := HMAC(ServerKey, AuthMessage)
+
+   The server authenticates the client by computing the ClientSignature,
+   exclusive-ORing that with the ClientProof to recover the ClientKey
+   and verifying the correctness of the ClientKey by applying the hash
+   function and comparing the result to the StoredKey.  If the ClientKey
+   is correct, this proves that the client has access to the user's
+   password.
+
+   Similarly, the client authenticates the server by computing the
+   ServerSignature and comparing it to the value sent by the server.  If
+   the two are equal, it proves that the server had access to the user's
+   ServerKey.
+
+   The AuthMessage is computed by concatenating messages from the
+   authentication exchange.  The format of these messages is defined in
+   Section 7.
+
+4.  SCRAM Mechanism Names
+
+   A SCRAM mechanism name is a string "SCRAM-" followed by the
+   uppercased name of the underlying hash function taken from the IANA
+   "Hash Function Textual Names" registry (see http://www.iana.org),
+   optionally followed by the suffix "-PLUS" (see below).  Note that
+   SASL mechanism names are limited to 20 octets, which means that only
+
+
+
+Newman, et al.               Standards Track                    [Page 8]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   hash function names with lengths shorter or equal to 9 octets
+   (20-length("SCRAM-")-length("-PLUS") can be used.  For cases when the
+   underlying hash function name is longer than 9 octets, an alternative
+   9-octet (or shorter) name can be used to construct the corresponding
+   SCRAM mechanism name, as long as this alternative name doesn't
+   conflict with any other hash function name from the IANA "Hash
+   Function Textual Names" registry.  In order to prevent future
+   conflict, such alternative names SHOULD be registered in the IANA
+   "Hash Function Textual Names" registry.
+
+   For interoperability, all SCRAM clients and servers MUST implement
+   the SCRAM-SHA-1 authentication mechanism, i.e., an authentication
+   mechanism from the SCRAM family that uses the SHA-1 hash function as
+   defined in [RFC3174].
+
+   The "-PLUS" suffix is used only when the server supports channel
+   binding to the external channel.  If the server supports channel
+   binding, it will advertise both the "bare" and "plus" versions of
+   whatever mechanisms it supports (e.g., if the server supports only
+   SCRAM with SHA-1, then it will advertise support for both SCRAM-SHA-1
+   and SCRAM-SHA-1-PLUS).  If the server does not support channel
+   binding, then it will advertise only the "bare" version of the
+   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
+   negotiation of the use of channel binding.  See Section 6.
+
+5.  SCRAM Authentication Exchange
+
+   SCRAM is a SASL mechanism whose client response and server challenge
+   messages are text-based messages containing one or more attribute-
+   value pairs separated by commas.  Each attribute has a one-letter
+   name.  The messages and their attributes are described in
+   Section 5.1, and defined in Section 7.
+
+   SCRAM is a client-first SASL mechanism (see [RFC4422], Section 5,
+   item 2a), and returns additional data together with a server's
+   indication of a successful outcome.
+
+   This is a simple example of a SCRAM-SHA-1 authentication exchange
+   when the client doesn't support channel bindings (username 'user' and
+   password 'pencil' are used):
+
+   C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
+   S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
+      i=4096
+   C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
+      p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
+   S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
+
+
+
+
+Newman, et al.               Standards Track                    [Page 9]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   First, the client sends the "client-first-message" containing:
+
+   o  a GS2 header consisting of a flag indicating whether channel
+      binding is supported-but-not-used, not supported, or used, and an
+      optional SASL authorization identity;
+
+   o  SCRAM username and a random, unique nonce attributes.
+
+   Note that the client's first message will always start with "n", "y",
+   or "p"; otherwise, the message is invalid and authentication MUST
+   fail.  This is important, as it allows for GS2 extensibility (e.g.,
+   to add support for security layers).
+
+   In response, the server sends a "server-first-message" containing the
+   user's iteration count i and the user's salt, and appends its own
+   nonce to the client-specified one.
+
+   The client then responds by sending a "client-final-message" with the
+   same nonce and a ClientProof computed using the selected hash
+   function as explained earlier.
+
+   The server verifies the nonce and the proof, verifies that the
+   authorization identity (if supplied by the client in the first
+   message) is authorized to act as the authentication identity, and,
+   finally, it responds with a "server-final-message", concluding the
+   authentication exchange.
+
+   The client then authenticates the server by computing the
+   ServerSignature and comparing it to the value sent by the server.  If
+   the two are different, the client MUST consider the authentication
+   exchange to be unsuccessful, and it might have to drop the
+   connection.
+
+5.1.  SCRAM Attributes
+
+   This section describes the permissible attributes, their use, and the
+   format of their values.  All attribute names are single US-ASCII
+   letters and are case-sensitive.
+
+   Note that the order of attributes in client or server messages is
+   fixed, with the exception of extension attributes (described by the
+   "extensions" ABNF production), which can appear in any order in the
+   designated positions.  See Section 7 for authoritative reference.
+
+   o  a: This is an optional attribute, and is part of the GS2 [RFC5801]
+      bridge between the GSS-API and SASL.  This attribute specifies an
+      authorization identity.  A client may include it in its first
+      message to the server if it wants to authenticate as one user, but
+
+
+
+Newman, et al.               Standards Track                   [Page 10]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+      subsequently act as a different user.  This is typically used by
+      an administrator to perform some management task on behalf of
+      another user, or by a proxy in some situations.
+
+         Upon the receipt of this value the server verifies its
+         correctness according to the used SASL protocol profile.
+         Failed verification results in failed authentication exchange.
+
+         If this attribute is omitted (as it normally would be), the
+         authorization identity is assumed to be derived from the
+         username specified with the (required) "n" attribute.
+
+         The server always authenticates the user specified by the "n"
+         attribute.  If the "a" attribute specifies a different user,
+         the server associates that identity with the connection after
+         successful authentication and authorization checks.
+
+         The syntax of this field is the same as that of the "n" field
+         with respect to quoting of '=' and ','.
+
+   o  n: This attribute specifies the name of the user whose password is
+      used for authentication (a.k.a. "authentication identity"
+      [RFC4422]).  A client MUST include it in its first message to the
+      server.  If the "a" attribute is not specified (which would
+      normally be the case), this username is also the identity that
+      will be associated with the connection subsequent to
+      authentication and authorization.
+
+         Before sending the username to the server, the client SHOULD
+         prepare the username using the "SASLprep" profile [RFC4013] of
+         the "stringprep" algorithm [RFC3454] treating it as a query
+         string (i.e., unassigned Unicode code points are allowed).  If
+         the preparation of the username fails or results in an empty
+         string, the client SHOULD abort the authentication exchange
+         (*).
+
+         (*) An interactive client can request a repeated entry of the
+         username value.
+
+         Upon receipt of the username by the server, the server MUST
+         either prepare it using the "SASLprep" profile [RFC4013] of the
+         "stringprep" algorithm [RFC3454] treating it as a query string
+         (i.e., unassigned Unicode codepoints are allowed) or otherwise
+         be prepared to do SASLprep-aware string comparisons and/or
+         index lookups.  If the preparation of the username fails or
+         results in an empty string, the server SHOULD abort the
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 11]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+         authentication exchange.  Whether or not the server prepares
+         the username using "SASLprep", it MUST use it as received in
+         hash calculations.
+
+         The characters ',' or '=' in usernames are sent as '=2C' and
+         '=3D' respectively.  If the server receives a username that
+         contains '=' not followed by either '2C' or '3D', then the
+         server MUST fail the authentication.
+
+   o  m: This attribute is reserved for future extensibility.  In this
+      version of SCRAM, its presence in a client or a server message
+      MUST cause authentication failure when the attribute is parsed by
+      the other end.
+
+   o  r: This attribute specifies a sequence of random printable ASCII
+      characters excluding ',' (which forms the nonce used as input to
+      the hash function).  No quoting is applied to this string.  As
+      described earlier, the client supplies an initial value in its
+      first message, and the server augments that value with its own
+      nonce in its first response.  It is important that this value be
+      different for each authentication (see [RFC4086] for more details
+      on how to achieve this).  The client MUST verify that the initial
+      part of the nonce used in subsequent messages is the same as the
+      nonce it initially specified.  The server MUST verify that the
+      nonce sent by the client in the second message is the same as the
+      one sent by the server in its first message.
+
+   o  c: This REQUIRED attribute specifies the base64-encoded GS2 header
+      and channel binding data.  It is sent by the client in its second
+      authentication message.  The attribute data consist of:
+
+      *  the GS2 header from the client's first message (recall that the
+         GS2 header contains a channel binding flag and an optional
+         authzid).  This header is going to include channel binding type
+         prefix (see [RFC5056]), if and only if the client is using
+         channel binding;
+
+      *  followed by the external channel's channel binding data, if and
+         only if the client is using channel binding.
+
+   o  s: This attribute specifies the base64-encoded salt used by the
+      server for this user.  It is sent by the server in its first
+      message to the client.
+
+   o  i: This attribute specifies an iteration count for the selected
+      hash function and user, and MUST be sent by the server along with
+      the user's salt.
+
+
+
+
+Newman, et al.               Standards Track                   [Page 12]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+         For the SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism, servers
+         SHOULD announce a hash iteration-count of at least 4096.  Note
+         that a client implementation MAY cache ClientKey&ServerKey (or
+         just SaltedPassword) for later reauthentication to the same
+         service, as it is likely that the server is going to advertise
+         the same salt value upon reauthentication.  This might be
+         useful for mobile clients where CPU usage is a concern.
+
+   o  p: This attribute specifies a base64-encoded ClientProof.  The
+      client computes this value as described in the overview and sends
+      it to the server.
+
+   o  v: This attribute specifies a base64-encoded ServerSignature.  It
+      is sent by the server in its final message, and is used by the
+      client to verify that the server has access to the user's
+      authentication information.  This value is computed as explained
+      in the overview.
+
+   o  e: This attribute specifies an error that occurred during
+      authentication exchange.  It is sent by the server in its final
+      message and can help diagnose the reason for the authentication
+      exchange failure.  On failed authentication, the entire server-
+      final-message is OPTIONAL; specifically, a server implementation
+      MAY conclude the SASL exchange with a failure without sending the
+      server-final-message.  This results in an application-level error
+      response without an extra round-trip.  If the server-final-message
+      is sent on authentication failure, then the "e" attribute MUST be
+      included.
+
+   o  As-yet unspecified mandatory and optional extensions.  Mandatory
+      extensions are encoded as values of the 'm' attribute (see ABNF
+      for reserved-mext in section 7).  Optional extensions use as-yet
+      unassigned attribute names.
+
+      Mandatory extensions sent by one peer but not understood by the
+      other MUST cause authentication failure (the server SHOULD send
+      the "extensions-not-supported" server-error-value).
+
+      Unknown optional extensions MUST be ignored upon receipt.
+
+5.2.  Compliance with SASL Mechanism Requirements
+
+   This section describes compliance with SASL mechanism requirements
+   specified in Section 5 of [RFC4422].
+
+   1)  "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS".
+
+   2a) SCRAM is a client-first mechanism.
+
+
+
+Newman, et al.               Standards Track                   [Page 13]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   2b) SCRAM sends additional data with success.
+
+   3)  SCRAM is capable of transferring authorization identities from
+       the client to the server.
+
+   4)  SCRAM does not offer any security layers (SCRAM offers channel
+       binding instead).
+
+   5)  SCRAM has a hash protecting the authorization identity.
+
+6.  Channel Binding
+
+   SCRAM supports channel binding to external secure channels, such as
+   TLS.  Clients and servers may or may not support channel binding,
+   therefore the use of channel binding is negotiable.  SCRAM does not
+   provide security layers, however, therefore it is imperative that
+   SCRAM provide integrity protection for the negotiation of channel
+   binding.
+
+   Use of channel binding is negotiated as follows:
+
+   o  Servers that support the use of channel binding SHOULD advertise
+      both the non-PLUS (SCRAM-<hash-function>) and PLUS-variant (SCRAM-
+      <hash-function>-PLUS) mechanism name.  If the server cannot
+      support channel binding, it SHOULD advertise only the non-PLUS-
+      variant.  If the server would never succeed in the authentication
+      of the non-PLUS-variant due to policy reasons, it MUST advertise
+      only the PLUS-variant.
+
+   o  If the client supports channel binding and the server does not
+      appear to (i.e., the client did not see the -PLUS name advertised
+      by the server), then the client MUST NOT use an "n" gs2-cbind-
+      flag.
+
+   o  Clients that support mechanism negotiation and channel binding
+      MUST use a "p" gs2-cbind-flag when the server offers the PLUS-
+      variant of the desired GS2 mechanism.
+
+   o  If the client does not support channel binding, then it MUST use
+      an "n" gs2-cbind-flag.  Conversely, if the client requires the use
+      of channel binding then it MUST use a "p" gs2-cbind-flag.  Clients
+      that do not support mechanism negotiation never use a "y" gs2-
+      cbind-flag, they use either "p" or "n" according to whether they
+      require and support the use of channel binding or whether they do
+      not, respectively.
+
+   o  Upon receipt of the client-first message, the server checks the
+      channel binding flag (gs2-cbind-flag).
+
+
+
+Newman, et al.               Standards Track                   [Page 14]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+      *  If the flag is set to "y" and the server supports channel
+         binding, the server MUST fail authentication.  This is because
+         if the client sets the channel binding flag to "y", then the
+         client must have believed that the server did not support
+         channel binding -- if the server did in fact support channel
+         binding, then this is an indication that there has been a
+         downgrade attack (e.g., an attacker changed the server's
+         mechanism list to exclude the -PLUS suffixed SCRAM mechanism
+         name(s)).
+
+      *  If the channel binding flag was "p" and the server does not
+         support the indicated channel binding type, then the server
+         MUST fail authentication.
+
+   The server MUST always validate the client's "c=" field.  The server
+   does this by constructing the value of the "c=" attribute and then
+   checking that it matches the client's c= attribute value.
+
+   For more discussions of channel bindings, and the syntax of channel
+   binding data for various security protocols, see [RFC5056].
+
+6.1.  Default Channel Binding
+
+   A default channel binding type agreement process for all SASL
+   application protocols that do not provide their own channel binding
+   type agreement is provided as follows.
+
+   'tls-unique' is the default channel binding type for any application
+   that doesn't specify one.
+
+   Servers MUST implement the "tls-unique" [RFC5929] channel binding
+   type, if they implement any channel binding.  Clients SHOULD
+   implement the "tls-unique" [RFC5929] channel binding type, if they
+   implement any channel binding.  Clients and servers SHOULD choose the
+   highest-layer/innermost end-to-end TLS channel as the channel to
+   which to bind.
+
+   Servers MUST choose the channel binding type indicated by the client,
+   or fail authentication if they don't support it.
+
+7.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3",
+   and "UTF8-4" non-terminal are defined in [RFC3629].
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 15]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   ALPHA = <as defined in RFC 5234 appendix B.1>
+   DIGIT = <as defined in RFC 5234 appendix B.1>
+   UTF8-2 = <as defined in RFC 3629 (STD 63)>
+   UTF8-3 = <as defined in RFC 3629 (STD 63)>
+   UTF8-4 = <as defined in RFC 3629 (STD 63)>
+
+   attr-val        = ALPHA "=" value
+                     ;; Generic syntax of any attribute sent
+                     ;; by server or client
+
+   value           = 1*value-char
+
+   value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
+                     UTF8-2 / UTF8-3 / UTF8-4
+                     ;; UTF8-char except NUL, "=", and ",".
+
+   value-char      = value-safe-char / "="
+
+   printable       = %x21-2B / %x2D-7E
+                     ;; Printable ASCII except ",".
+                     ;; Note that any "printable" is also
+                     ;; a valid "value".
+
+   base64-char     = ALPHA / DIGIT / "/" / "+"
+
+   base64-4        = 4base64-char
+
+   base64-3        = 3base64-char "="
+
+   base64-2        = 2base64-char "=="
+
+   base64          = *base64-4 [base64-3 / base64-2]
+
+   posit-number = %x31-39 *DIGIT
+                     ;; A positive number.
+
+   saslname        = 1*(value-safe-char / "=2C" / "=3D")
+                     ;; Conforms to <value>.
+
+   authzid         = "a=" saslname
+                     ;; Protocol specific.
+
+   cb-name         = 1*(ALPHA / DIGIT / "." / "-")
+                      ;; See RFC 5056, Section 7.
+                      ;; E.g., "tls-server-end-point" or
+                      ;; "tls-unique".
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 16]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   gs2-cbind-flag  = ("p=" cb-name) / "n" / "y"
+                     ;; "n" -> client doesn't support channel binding.
+                     ;; "y" -> client does support channel binding
+                     ;;        but thinks the server does not.
+                     ;; "p" -> client requires channel binding.
+                     ;; The selected channel binding follows "p=".
+
+   gs2-header      = gs2-cbind-flag "," [ authzid ] ","
+                     ;; GS2 header for SCRAM
+                     ;; (the actual GS2 header includes an optional
+                     ;; flag to indicate that the GSS mechanism is not
+                     ;; "standard", but since SCRAM is "standard", we
+                     ;; don't include that flag).
+
+   username        = "n=" saslname
+                     ;; Usernames are prepared using SASLprep.
+
+   reserved-mext  = "m=" 1*(value-char)
+                     ;; Reserved for signaling mandatory extensions.
+                     ;; The exact syntax will be defined in
+                     ;; the future.
+
+   channel-binding = "c=" base64
+                     ;; base64 encoding of cbind-input.
+
+   proof           = "p=" base64
+
+   nonce           = "r=" c-nonce [s-nonce]
+                     ;; Second part provided by server.
+
+   c-nonce         = printable
+
+   s-nonce         = printable
+
+   salt            = "s=" base64
+
+   verifier        = "v=" base64
+                     ;; base-64 encoded ServerSignature.
+
+   iteration-count = "i=" posit-number
+                     ;; A positive number.
+
+   client-first-message-bare =
+                     [reserved-mext ","]
+                     username "," nonce ["," extensions]
+
+   client-first-message =
+                     gs2-header client-first-message-bare
+
+
+
+Newman, et al.               Standards Track                   [Page 17]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   server-first-message =
+                     [reserved-mext ","] nonce "," salt ","
+                     iteration-count ["," extensions]
+
+   client-final-message-without-proof =
+                     channel-binding "," nonce [","
+                     extensions]
+
+   client-final-message =
+                     client-final-message-without-proof "," proof
+
+   server-error = "e=" server-error-value
+
+   server-error-value = "invalid-encoding" /
+                  "extensions-not-supported" /  ; unrecognized 'm' value
+                  "invalid-proof" /
+                  "channel-bindings-dont-match" /
+                  "server-does-support-channel-binding" /
+                    ; server does not support channel binding
+                  "channel-binding-not-supported" /
+                  "unsupported-channel-binding-type" /
+                  "unknown-user" /
+                  "invalid-username-encoding" /
+                    ; invalid username encoding (invalid UTF-8 or
+                    ; SASLprep failed)
+                  "no-resources" /
+                  "other-error" /
+                  server-error-value-ext
+           ; Unrecognized errors should be treated as "other-error".
+           ; In order to prevent information disclosure, the server
+           ; may substitute the real reason with "other-error".
+
+   server-error-value-ext = value
+           ; Additional error reasons added by extensions
+           ; to this document.
+
+   server-final-message = (server-error / verifier)
+                     ["," extensions]
+
+   extensions = attr-val *("," attr-val)
+                     ;; All extensions are optional,
+                     ;; i.e., unrecognized attributes
+                     ;; not defined in this document
+                     ;; MUST be ignored.
+
+   cbind-data    = 1*OCTET
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 18]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   cbind-input   = gs2-header [ cbind-data ]
+                     ;; cbind-data MUST be present for
+                     ;; gs2-cbind-flag of "p" and MUST be absent
+                     ;; for "y" or "n".
+
+8.  SCRAM as a GSS-API Mechanism
+
+   This section and its sub-sections and all normative references of it
+   not referenced elsewhere in this document are INFORMATIONAL for SASL
+   implementors, but they are NORMATIVE for GSS-API implementors.
+
+   SCRAM is actually also a GSS-API mechanism.  The messages are the
+   same, but a) the GS2 header on the client's first message and channel
+   binding data is excluded when SCRAM is used as a GSS-API mechanism,
+   and b) the RFC2743 section 3.1 initial context token header is
+   prefixed to the client's first authentication message (context
+   token).
+
+   The GSS-API mechanism OID for SCRAM-SHA-1 is 1.3.6.1.5.5.14 (see
+   Section 10).
+
+   SCRAM security contexts always have the mutual_state flag
+   (GSS_C_MUTUAL_FLAG) set to TRUE.  SCRAM does not support credential
+   delegation, therefore SCRAM security contexts alway have the
+   deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
+
+8.1.  GSS-API Principal Name Types for SCRAM
+
+   SCRAM does not explicitly name acceptor principals.  However, the use
+   of acceptor principal names to find or prompt for passwords is
+   useful.  Therefore, SCRAM supports standard generic name syntaxes for
+   acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section
+   4.1).  Implementations should use the target name passed to
+   GSS_Init_sec_context(), if any, to help retrieve or prompt for SCRAM
+   passwords.
+
+   SCRAM supports only a single name type for initiators:
+   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
+   SCRAM.
+
+   There is no name canonicalization procedure for SCRAM beyond applying
+   SASLprep as described in Section 5.1.
+
+   The query, display, and exported name syntaxes for SCRAM principal
+   names are all the same.  There are no SCRAM-specific name syntaxes
+   (SCRAM initiator principal names are free-form); -- applications
+   should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
+
+
+
+
+Newman, et al.               Standards Track                   [Page 19]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4).  The exported
+   name token does, of course, conform to [RFC2743], Section 3.2, but
+   the "NAME" part of the token is just a SCRAM user name.
+
+8.2.  GSS-API Per-Message Tokens for SCRAM
+
+   The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
+   same as those for the Kerberos V GSS-API mechanism [RFC4121] (see
+   Section 4.2 and sub-sections), using the Kerberos V "aes128-cts-hmac-
+   sha1-96" enctype [RFC3962].
+
+   The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state
+   (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail
+   (GSS_C_CONF_FLAG) security context flags are always set to TRUE.
+
+   The 128-bit session "protocol key" SHALL be derived by using the
+   least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API
+   session key" || ClientKey || AuthMessage).  "Specific keys" are then
+   derived as usual as described in Section 2 of [RFC4121], [RFC3961],
+   and [RFC3962].
+
+   The terms "protocol key" and "specific key" are Kerberos V5 terms
+   [RFC3961].
+
+   SCRAM does support PROT_READY, and is PROT_READY on the initiator
+   side first upon receipt of the server's reply to the initial security
+   context token.
+
+8.3.  GSS_Pseudo_random() for SCRAM
+
+   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
+   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
+   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
+   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
+   The protocol key to be used for the GSS_Pseudo_random() SHALL be the
+   same as the key defined in Section 8.2.
+
+9.  Security Considerations
+
+   If the authentication exchange is performed without a strong security
+   layer (such as TLS with data confidentiality), then a passive
+   eavesdropper can gain sufficient information to mount an offline
+   dictionary or brute-force attack that can be used to recover the
+   user's password.  The amount of time necessary for this attack
+   depends on the cryptographic hash function selected, the strength of
+   the password, and the iteration count supplied by the server.  An
+   external security layer with strong encryption will prevent this
+   attack.
+
+
+
+Newman, et al.               Standards Track                   [Page 20]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   If the external security layer used to protect the SCRAM exchange
+   uses an anonymous key exchange, then the SCRAM channel binding
+   mechanism can be used to detect a man-in-the-middle attack on the
+   security layer and cause the authentication to fail as a result.
+   However, the man-in-the-middle attacker will have gained sufficient
+   information to mount an offline dictionary or brute-force attack.
+   For this reason, SCRAM allows to increase the iteration count over
+   time.  (Note that a server that is only in possession of "StoredKey"
+   and "ServerKey" can't automatically increase the iteration count upon
+   successful authentication.  Such an increase would require resetting
+   the user's password.)
+
+   If the authentication information is stolen from the authentication
+   database, then an offline dictionary or brute-force attack can be
+   used to recover the user's password.  The use of salt mitigates this
+   attack somewhat by requiring a separate attack on each password.
+   Authentication mechanisms that protect against this attack are
+   available (e.g., the EKE class of mechanisms).  RFC 2945 [RFC2945] is
+   an example of such technology.  The WG elected not to use EKE like
+   mechanisms as a basis for SCRAM.
+
+   If an attacker obtains the authentication information from the
+   authentication repository and either eavesdrops on one authentication
+   exchange or impersonates a server, the attacker gains the ability to
+   impersonate that user to all servers providing SCRAM access using the
+   same hash function, password, iteration count, and salt.  For this
+   reason, it is important to use randomly generated salt values.
+
+   SCRAM does not negotiate a hash function to use.  Hash function
+   negotiation is left to the SASL mechanism negotiation.  It is
+   important that clients be able to sort a locally available list of
+   mechanisms by preference so that the client may pick the appropriate
+   mechanism to use from a server's advertised mechanism list.  This
+   preference order is not specified here as it is a local matter.  The
+   preference order should include objective and subjective notions of
+   mechanism cryptographic strength (e.g., SCRAM with a successor to
+   SHA-1 may be preferred over SCRAM with SHA-1).
+
+   Note that to protect the SASL mechanism negotiation applications
+   normally must list the server mechanisms twice: once before and once
+   after authentication, the latter using security layers.  Since SCRAM
+   does not provide security layers, the only ways to protect the
+   mechanism negotiation are a) use channel binding to an external
+   channel, or b) use an external channel that authenticates a user-
+   provided server name.
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 21]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   SCRAM does not protect against downgrade attacks of channel binding
+   types.  The complexities of negotiating a channel binding type, and
+   handling down-grade attacks in that negotiation, were intentionally
+   left out of scope for this document.
+
+   A hostile server can perform a computational denial-of-service attack
+   on clients by sending a big iteration count value.
+
+   See [RFC4086] for more information about generating randomness.
+
+10.  IANA Considerations
+
+   IANA has added the following family of SASL mechanisms to the SASL
+   Mechanism registry established by [RFC4422]:
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL family SCRAM
+
+   SASL mechanism name (or prefix for the family): SCRAM-*
+   Security considerations: Section 7 of [RFC5802]
+   Published specification (optional, recommended): [RFC5802]
+   Person & email address to contact for further information:
+   IETF SASL WG <sasl@ietf.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note: Members of this family MUST be explicitly registered
+   using the "IETF Review" [RFC5226] registration procedure.
+   Reviews MUST be requested on the SASL mailing list
+   <sasl@ietf.org> (or a successor designated by the responsible
+   Security AD).
+
+   Note to future SCRAM-mechanism designers: each new SCRAM-SASL
+   mechanism MUST be explicitly registered with IANA and MUST comply
+   with SCRAM-mechanism naming convention defined in Section 4 of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 22]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   IANA has added the following entries to the SASL Mechanism registry
+   established by [RFC4422]:
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-SHA-1
+
+   SASL mechanism name (or prefix for the family): SCRAM-SHA-1
+   Security considerations: Section 7 of [RFC5802]
+   Published specification (optional, recommended): [RFC5802]
+   Person & email address to contact for further information:
+   IETF SASL WG <sasl@ietf.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS
+
+   SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS
+   Security considerations: Section 7 of [RFC5802]
+   Published specification (optional, recommended): [RFC5802]
+   Person & email address to contact for further information:
+   IETF SASL WG <sasl@ietf.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+   Per this document, IANA has assigned a GSS-API mechanism OID for
+   SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms prefix
+   (see "SMI Security for Mechanism Codes" registry).
+
+11.  Acknowledgements
+
+   This document benefited from discussions on the SASL WG mailing list.
+   The authors would like to specially thank Dave Cridland, Simon
+   Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen, Ben
+   Campbell, Peter Saint-Andre, and Tobias Markmann for their
+   contributions to this document.  A special thank you to Simon
+   Josefsson for shepherding this document and for doing one of the
+   first implementations of this specification.
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 23]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
+
+   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+              and Passwords", RFC 4013, February 2005.
+
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
+              for TLS", RFC 5929, July 2010.
+
+12.2.  Normative References for GSS-API Implementors
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 24]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
+              Kerberos V Generic Security Service Application Program
+              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
+
+   [RFC5801]  Josefsson, S. and N. Williams, "Using Generic Security
+              Service Application Program Interface (GSS-API) Mechanisms
+              in Simple Authentication and Security Layer (SASL): The
+              GS2 Mechanism Family", RFC 5801, July 2010.
+
+12.3.  Informative References
+
+   [CRAMHISTORIC]
+              Zeilenga, K., "CRAM-MD5 to Historic", Work in Progress,
+              November 2008.
+
+   [DIGESTHISTORIC]
+              Melnikov, A., "Moving DIGEST-MD5 to Historic", Work
+              in Progress, July 2008.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, June 2000.
+
+   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
+
+   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
+              RFC 2945, September 2000.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
+
+
+
+
+Newman, et al.               Standards Track                   [Page 25]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
+              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5803]  Melnikov, A., "Lightweight Directory Access Protocol
+              (LDAP) Schema for Storing Salted Challenge Response
+              Authentication Mechanism (SCRAM) Secrets", RFC 5803,
+              July 2010.
+
+   [tls-server-end-point]
+              IANA, "Registration of TLS server end-point channel
+              bindings", available from http://www.iana.org, June 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 26]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+Appendix A.  Other Authentication Mechanisms
+
+   The DIGEST-MD5 [DIGESTHISTORIC] mechanism has proved to be too
+   complex to implement and test, and thus has poor interoperability.
+   The security layer is often not implemented, and almost never used;
+   everyone uses TLS instead.  For a more complete list of problems with
+   DIGEST-MD5 that led to the creation of SCRAM, see [DIGESTHISTORIC].
+
+   The CRAM-MD5 SASL mechanism, while widely deployed, also has some
+   problems.  In particular, it is missing some modern SASL features
+   such as support for internationalized usernames and passwords,
+   support for passing of authorization identity, and support for
+   channel bindings.  It also doesn't support server authentication.
+   For a more complete list of problems with CRAM-MD5, see
+   [CRAMHISTORIC].
+
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
+
+Appendix B.  Design Motivations
+
+   The following design goals shaped this document.  Note that some of
+   the goals have changed since the initial version of the document.
+
+   o  The SASL mechanism has all modern SASL features: support for
+      internationalized usernames and passwords, support for passing of
+      authorization identity, and support for channel bindings.
+
+   o  The protocol supports mutual authentication.
+
+   o  The authentication information stored in the authentication
+      database is not sufficient by itself to impersonate the client.
+
+   o  The server does not gain the ability to impersonate the client to
+      other servers (with an exception for server-authorized proxies),
+      unless such other servers allow SCRAM authentication and use the
+      same salt and iteration count for the user.
+
+   o  The mechanism is extensible, but (hopefully) not over-engineered
+      in this respect.
+
+   o  The mechanism is easier to implement than DIGEST-MD5 in both
+      clients and servers.
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 27]
+
+RFC 5802                          SCRAM                        July 2010
+
+
+Authors' Addresses
+
+   Chris Newman
+   Oracle
+   800 Royal Oaks
+   Monrovia, CA  91016
+   USA
+
+   EMail: chris.newman@oracle.com
+
+
+   Abhijit Menon-Sen
+   Oryx Mail Systems GmbH
+
+   EMail: ams@toroid.org
+
+
+   Alexey Melnikov
+   Isode, Ltd.
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+   Nicolas Williams
+   Oracle
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   USA
+
+   EMail: Nicolas.Williams@oracle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et al.               Standards Track                   [Page 28]
+
diff --git a/doc/rfcs/rfc7628.txt b/doc/rfcs/rfc7628.txt
new file mode 100644
index 0000000..447786a
--- /dev/null
+++ b/doc/rfcs/rfc7628.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          W. Mills
+Request for Comments: 7628                                     Microsoft
+Category: Standards Track                                   T. Showalter
+ISSN: 2070-1721
+                                                           H. Tschofenig
+                                                                ARM Ltd.
+                                                             August 2015
+
+
+  A Set of Simple Authentication and Security Layer (SASL) Mechanisms
+                               for OAuth
+
+Abstract
+
+   OAuth enables a third-party application to obtain limited access to a
+   protected resource, either on behalf of a resource owner by
+   orchestrating an approval interaction or by allowing the third-party
+   application to obtain access on its own behalf.
+
+   This document defines how an application client uses credentials
+   obtained via OAuth over the Simple Authentication and Security Layer
+   (SASL) to access a protected resource at a resource server.  Thereby,
+   it enables schemes defined within the OAuth framework for non-HTTP-
+   based application protocols.
+
+   Clients typically store the user's long-term credential.  This does,
+   however, lead to significant security vulnerabilities, for example,
+   when such a credential leaks.  A significant benefit of OAuth for
+   usage in those clients is that the password is replaced by a shared
+   secret with higher entropy, i.e., the token.  Tokens typically
+   provide limited access rights and can be managed and revoked
+   separately from the user's long-term password.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7628.
+
+
+
+
+
+Mills, et al.                Standards Track                    [Page 1]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  OAuth SASL Mechanism Specifications . . . . . . . . . . . . .   6
+     3.1.  Initial Client Response . . . . . . . . . . . . . . . . .   7
+       3.1.1.  Reserved Key/Values . . . . . . . . . . . . . . . . .   8
+     3.2.  Server's Response . . . . . . . . . . . . . . . . . . . .   8
+       3.2.1.  OAuth Identifiers in the SASL Context . . . . . . . .   9
+       3.2.2.  Server Response to Failed Authentication  . . . . . .   9
+       3.2.3.  Completing an Error Message Sequence  . . . . . . . .  10
+     3.3.  OAuth Access Token Types using Keyed Message Digests  . .  11
+   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     4.1.  Successful Bearer Token Exchange  . . . . . . . . . . . .  12
+     4.2.  Successful OAuth 1.0a Token Exchange  . . . . . . . . . .  13
+     4.3.  Failed Exchange . . . . . . . . . . . . . . . . . . . . .  14
+     4.4.  SMTP Example of a Failed Negotiation  . . . . . . . . . .  15
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   6.  Internationalization Considerations . . . . . . . . . . . . .  17
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
+     7.1.  SASL Registration . . . . . . . . . . . . . . . . . . . .  18
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21
+
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                    [Page 2]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+1.  Introduction
+
+   OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks
+   that enable a third-party application to obtain limited access to a
+   protected resource, either by orchestrating an approval interaction
+   on behalf of a resource owner or by allowing the third-party
+   application to obtain access on its own behalf.
+
+   The core OAuth 2.0 specification [RFC6749] specifies the interaction
+   between the OAuth client and the authorization server; it does not
+   define the interaction between the OAuth client and the resource
+   server for the access to a protected resource using an access token.
+   Instead, the OAuth client to resource server interaction is described
+   in separate specifications, such as the bearer token specification
+   [RFC6750].  OAuth 1.0a includes the protocol specification for the
+   communication between the OAuth client and the resource server in
+   [RFC5849].
+
+   The main use cases for OAuth 1.0a and OAuth 2.0 have so far focused
+   on an HTTP-based [RFC7230] environment only.  This document
+   integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications
+   using the integration into the Simple Authentication and Security
+   Layer (SASL) [RFC4422].  Hence, this document takes advantage of the
+   OAuth protocol and its deployment base to provide a way to use SASL
+   to gain access to resources when using non-HTTP-based protocols, such
+   as the Internet Message Access Protocol (IMAP) [RFC3501] and the
+   Simple Mail Transfer Protocol (SMTP) [RFC5321].  This document gives
+   examples of use in IMAP and SMTP.
+
+   To illustrate the impact of integrating this specification into an
+   OAuth-enabled application environment, Figure 1 shows the abstract
+   message flow of OAuth 2.0 [RFC6749].  As indicated in the figure,
+   this document impacts the exchange of messages (E) and (F) since SASL
+   is used for interaction between the client and the resource server
+   instead of HTTP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                    [Page 3]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+                                                              ----+
+   +--------+                                  +---------------+  |
+   |        |--(A)-- Authorization Request --->|   Resource    |  |
+   |        |                                  |    Owner      |  |Plain
+   |        |<-(B)------ Access Grant ---------|               |  |OAuth
+   |        |                                  +---------------+  |2.0
+   |        |                                                     |
+   |        |         Client Credentials &     +---------------+  |
+   |        |--(C)------ Access Grant -------->| Authorization |  |
+   | Client |                                  |    Server     |  |
+   |        |<-(D)------ Access Token ---------|               |  |
+   |        |      (w/ Optional Refresh Token) +---------------+  |
+   |        |                                                 ----+
+   |        |                                                 ----+
+   |        |                                  +---------------+  |
+   |        |                                  |               |  |OAuth
+   |        |--(E)------ Access Token -------->|   Resource    |  |over
+   |        |                                  |    Server     |  |SASL
+   |        |<-(F)---- Protected Resource -----|               |  |
+   |        |                                  |               |  |
+   +--------+                                  +---------------+  |
+                                                              ----+
+
+                     Figure 1: OAuth 2.0 Protocol Flow
+
+   SASL is a framework for providing authentication and data security
+   services in connection-oriented protocols via replaceable
+   authentication mechanisms.  It provides a structured interface
+   between protocols and mechanisms.  The resulting framework allows new
+   protocols to reuse existing authentication mechanisms and allows old
+   protocols to make use of new authentication mechanisms.  The
+   framework also provides a protocol for securing subsequent exchanges
+   within a data security layer.
+
+   When OAuth is integrated into SASL, the high-level steps are as
+   follows:
+
+   (A)  The client requests authorization from the resource owner.  The
+        authorization request can be made directly to the resource owner
+        (as shown) or indirectly via the authorization server as an
+        intermediary.
+
+   (B)  The client receives an authorization grant, which is a
+        credential representing the resource owner's authorization,
+        expressed using one of the grant types defined in [RFC6749] or
+        [RFC5849] or using an extension grant type.  The authorization
+        grant type depends on the method used by the client to request
+
+
+
+
+Mills, et al.                Standards Track                    [Page 4]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+        authorization and the types supported by the authorization
+        server.
+
+   (C)  The client requests an access token by authenticating with the
+        authorization server and presenting the authorization grant.
+
+   (D)  The authorization server authenticates the client and validates
+        the authorization grant, and if valid, it issues an access
+        token.
+
+   (E)  The client requests the protected resource from the resource
+        server and authenticates it by presenting the access token.
+
+   (F)  The resource server validates the access token, and if valid, it
+        indicates a successful authentication.
+
+   Again, steps (E) and (F) are not defined in [RFC6749] (but are
+   described in, for example, [RFC6750] for the OAuth bearer token
+   instead) and are the main functionality specified within this
+   document.  Consequently, the message exchange shown in Figure 1 is
+   the result of this specification.  The client will generally need to
+   determine the authentication endpoints (and perhaps the service
+   endpoints) before the OAuth 2.0 protocol exchange messages in steps
+   (A)-(D) are executed.  The discovery of the resource owner,
+   authorization server endpoints, and client registration are outside
+   the scope of this specification.  The client must discover the
+   authorization endpoints using a discovery mechanism such as OpenID
+   Connect Discovery (OIDCD) [OpenID.Discovery] or WebFinger using host-
+   meta [RFC7033].  Once credentials are obtained, the client proceeds
+   to steps (E) and (F) defined in this specification.  Authorization
+   endpoints MAY require client registration, and generic clients SHOULD
+   support the Dynamic Client Registration protocol [RFC7591].
+
+   OAuth 1.0a follows a similar model but uses a different terminology
+   and does not separate the resource server from the authorization
+   server.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   The reader is assumed to be familiar with the terms used in the OAuth
+   2.0 specification [RFC6749] and SASL [RFC4422].
+
+
+
+
+
+Mills, et al.                Standards Track                    [Page 5]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.  Line breaks have been inserted for
+   readability.
+
+   Note that the IMAP SASL specification requires base64 encoding, as
+   specified in Section 4 of [RFC4648].
+
+3.  OAuth SASL Mechanism Specifications
+
+   SASL is used as an authentication framework in a variety of
+   application-layer protocols.  This document defines the following
+   SASL mechanisms for usage with OAuth:
+
+      OAUTHBEARER:  OAuth 2.0 bearer tokens, as described in [RFC6750].
+         RFC 6750 uses Transport Layer Security (TLS) [RFC5246] to
+         secure the protocol interaction between the client and the
+         resource server.
+
+      OAUTH10A:  OAuth 1.0a Message Authentication Code (MAC) tokens
+         (using the HMAC-SHA1 keyed message digest), as described in
+         Section 3.4.2 of [RFC5849].
+
+   New extensions may be defined to add additional OAuth Access Token
+   Types.  Such a new SASL OAuth mechanism can be added by registering
+   the new name(s) with IANA in the SASL Mechanisms registry and citing
+   this specification for the further definition.
+
+   SASL mechanisms using this document as their definition do not
+   provide a data security layer; that is, they cannot provide integrity
+   or confidentiality protection for application messages after the
+   initial authentication.  If such protection is needed, TLS or some
+   similar solution should be used.  Additionally, for the two
+   mechanisms specified in this document, TLS MUST be used for
+   OAUTHBEARER to protect the bearer token; for OAUTH10A, the use of TLS
+   is RECOMMENDED.
+
+   These mechanisms are client initiated and in lockstep, with the
+   server always replying to a client message.  In the case where the
+   client has and correctly uses a valid token, the flow is:
+
+   1.  Client sends a valid and correct initial client response.
+
+   2.  Server responds with a successful authentication.
+
+   In the case where authentication fails, the server sends an error
+   result; the client MUST then send an additional message to the server
+   in order to allow the server to finish the exchange.  Some protocols
+   and common SASL implementations do not support both sending a SASL
+
+
+
+Mills, et al.                Standards Track                    [Page 6]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   message and finalizing a SASL negotiation.  The additional client
+   message in the error case deals with this problem.  This exchange is:
+
+   1.  Client sends an invalid initial client response.
+
+   2.  Server responds with an error message.
+
+   3.  Client sends a dummy client response.
+
+   4.  Server fails the authentication.
+
+3.1.  Initial Client Response
+
+   Client responses are a GS2 [RFC5801] header followed by zero or more
+   key/value pairs, or it may be empty.  The gs2-header rule is defined
+   here as a placeholder for compatibility with GS2 if a GS2 mechanism
+   is formally defined, but this document does not define one.  The key/
+   value pairs take the place of the corresponding HTTP headers and
+   values to convey the information necessary to complete an OAuth-style
+   HTTP authorization.  Unknown key/value pairs MUST be ignored by the
+   server.  The ABNF [RFC5234] syntax is:
+
+     kvsep          = %x01
+     key            = 1*(ALPHA)
+     value          = *(VCHAR / SP / HTAB / CR / LF )
+     kvpair         = key "=" value kvsep
+   ;;gs2-header     = See RFC 5801
+     client-resp    = (gs2-header kvsep *kvpair kvsep) / kvsep
+
+   The GS2 header MAY include the username associated with the resource
+   being accessed, the "authzid".  It is worth noting that application
+   protocols are allowed to require an authzid, as are specific server
+   implementations.
+
+   The client response consisting of only a single kvsep is used only
+   when authentication fails and is only valid in that context.  If sent
+   as the first message from the client, the server MAY simply fail the
+   authentication without returning discovery information since there is
+   no user or server name indication.
+
+   The following keys and corresponding values are defined in the client
+   response:
+
+      auth (REQUIRED):  The payload that would be in the HTTP
+         Authorization header if this OAuth exchange was being carried
+         out over HTTP.
+
+
+
+
+
+Mills, et al.                Standards Track                    [Page 7]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+      host:  Contains the hostname to which the client connected.  In an
+         HTTP context, this is the value of the HTTP Host header.
+
+      port:  Contains the destination port that the client connected to,
+         represented as a decimal positive integer string without
+         leading zeros.
+
+   For OAuth token types such as OAuth 1.0a that use keyed message
+   digests, the client MUST send host and port number key/values, and
+   the server MUST fail an authorization request requiring keyed message
+   digests that are not accompanied by host and port values.  In OAuth
+   1.0a, for example, the so-called "signature base string calculation"
+   includes the reconstructed HTTP URL.
+
+3.1.1.  Reserved Key/Values
+
+   In these mechanisms, values for path, query string and post body are
+   assigned default values.  OAuth authorization schemes MAY define
+   usage of these in the SASL context and extend this specification.
+   For OAuth Access Token Types that include a keyed message digest of
+   the request, the default values MUST be used unless explicit values
+   are provided in the client response.  The following key values are
+   reserved for future use:
+
+      mthd (RESERVED):  HTTP method; the default value is "POST".
+
+      path (RESERVED):  HTTP path data; the default value is "/".
+
+      post (RESERVED):  HTTP post data; the default value is the empty
+         string ("").
+
+      qs (RESERVED):  The HTTP query string; the default value is the
+         empty string ("").
+
+3.2.  Server's Response
+
+   The server validates the response according to the specification for
+   the OAuth Access Token Types used.  If the OAuth Access Token Type
+   utilizes a keyed message digest of the request parameters, then the
+   client must provide a client response that satisfies the data
+   requirements for the scheme in use.
+
+   The server fully validates the client response before generating a
+   server response; this will necessarily include the validation steps
+   listed in the specification for the OAuth Access Token Type used.
+   However, additional validation steps may be needed, depending on the
+   particular application protocol making use of SASL.  In particular,
+   values included as kvpairs in the client response (such as host and
+
+
+
+Mills, et al.                Standards Track                    [Page 8]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   port) that correspond to values known to the application server by
+   some other mechanism (such as an application protocol data unit or
+   preconfigured values) MUST be validated to match between the initial
+   client response and the other source(s) of such information.  As a
+   concrete example, when SASL is used over IMAP to an IMAP server for a
+   single domain, the hostname can be available via configuration; this
+   hostname must be validated to match the value sent in the 'host'
+   kvpair.
+
+   The server responds to a successfully verified client message by
+   completing the SASL negotiation.  The authenticated identity reported
+   by the SASL mechanism is the identity securely established for the
+   client with the OAuth credential.  The application, not the SASL
+   mechanism, based on local access policy determines whether the
+   identity reported by the mechanism is allowed access to the requested
+   resource.  Note that the semantics of the authzid are specified by
+   the SASL framework [RFC4422].
+
+3.2.1.  OAuth Identifiers in the SASL Context
+
+   In the OAuth framework, the client may be authenticated by the
+   authorization server, and the resource owner is authenticated to the
+   authorization server.  OAuth access tokens may contain information
+   about the authentication of the resource owner and about the client
+   and may therefore make this information accessible to the resource
+   server.
+
+   If both identifiers are needed by an application the developer will
+   need to provide a way to communicate that from the SASL mechanism
+   back to the application.
+
+3.2.2.  Server Response to Failed Authentication
+
+   For a failed authentication, the server returns an error result in
+   JSON [RFC7159] format and fails the authentication.  The error result
+   consists of the following values:
+
+      status (REQUIRED):  The authorization error code.  Valid error
+         codes are defined in the IANA "OAuth Extensions Error Registry"
+         as specified in the OAuth 2.0 core specification.
+
+      scope (OPTIONAL):  An OAuth scope that is valid to access the
+         service.  This may be omitted, which implies that unscoped
+         tokens are required.  If a scope is specified, then a single
+         scope is preferred.  At the time this document was written,
+         there are several implementations that do not properly support
+         space-separated lists of scopes, so the use of a space-
+         separated list of scopes is NOT RECOMMENDED.
+
+
+
+Mills, et al.                Standards Track                    [Page 9]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+      openid-configuration (OPTIONAL):  The URL for a document following
+         the OpenID Provider Configuration Information schema as
+         described in OIDCD [OpenID.Discovery], Section 3 that is
+         appropriate for the user.  As specified in OIDCD, this will
+         have the "https" URL scheme.  This document MUST have all
+         OAuth-related data elements populated.  The server MAY return
+         different URLs for users in different domains, and the client
+         SHOULD NOT cache a single returned value and assume it applies
+         for all users/domains that the server supports.  The returned
+         discovery document SHOULD have all data elements required by
+         the OpenID Connect Discovery specification populated.  In
+         addition, the discovery document SHOULD contain the
+         'registration_endpoint' element to identify the endpoint to be
+         used with the Dynamic Client Registration protocol [RFC7591] to
+         obtain the minimum number of parameters necessary for the OAuth
+         protocol exchange to function.  Another comparable discovery or
+         client registration mechanism MAY be used if available.
+
+         The use of the 'offline_access' scope, as defined in
+         [OpenID.Core], is RECOMMENDED to give clients the capability to
+         explicitly request a refresh token.
+
+   If the resource server provides a scope, then the client MUST always
+   request scoped tokens from the token endpoint.  If the resource
+   server does not return a scope, the client SHOULD presume an unscoped
+   token is required to access the resource.
+
+   Since clients may interact with a number of application servers, such
+   as email servers and Extensible Messaging and Presence Protocol
+   (XMPP) [RFC6120] servers, they need to have a way to determine
+   whether dynamic client registration has been performed already and
+   whether an already available refresh token can be reused to obtain an
+   access token for the desired resource server.  This specification
+   RECOMMENDS that a client uses the information in the 'iss' element
+   defined in OpenID Connect Core [OpenID.Core] to make this
+   determination.
+
+3.2.3.  Completing an Error Message Sequence
+
+   Section 3.6 of SASL [RFC4422] explicitly prohibits additional
+   information in an unsuccessful authentication outcome.  Therefore,
+   the error message is sent in a normal message.  The client MUST then
+   send either an additional client response consisting of a single %x01
+   (control A) character to the server in order to allow the server to
+   finish the exchange or a SASL abort message as generally defined in
+   Section 3.5 of SASL [RFC4422].  A specific example of an abort
+   message is the "BAD" response to an AUTHENTICATE in IMAP [RFC3501],
+   Section 6.2.2.
+
+
+
+Mills, et al.                Standards Track                   [Page 10]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+3.3.  OAuth Access Token Types using Keyed Message Digests
+
+   OAuth Access Token Types may use keyed message digests, and the
+   client and the resource server may need to perform a cryptographic
+   computation for integrity protection and data origin authentication.
+
+   OAuth is designed for access to resources identified by URIs.  SASL
+   is designed for user authentication and has no facility for more
+   fine-grained access control.  In this specification, we require or
+   define default values for the data elements from an HTTP request that
+   allows the signature base string to be constructed properly.  The
+   default HTTP path is "/", and the default post body is empty.  These
+   atoms are defined as extension points so that no changes are needed
+   if there is a revision of SASL that supports more specific resource
+   authorization, e.g., IMAP access to a specific folder or FTP access
+   limited to a specific directory.
+
+   Using the example in the OAuth 1.0a specification as a starting
+   point, below is the authorization request in OAuth 1.0a style (with
+   %x01 shown as ^A and line breaks added for readability), assuming it
+   is on an IMAP server running on port 143:
+
+   n,a=user@example.com,^A
+   host=example.com^A
+   port=143^A
+   auth=OAuth realm="Example",
+              oauth_consumer_key="9djdj82h48djs9d2",
+              oauth_token="kkk9d7dh3k39sjv7",
+              oauth_signature_method="HMAC-SHA1",
+              oauth_timestamp="137131201",
+              oauth_nonce="7d8f3e4a",
+              oauth_signature="Tm90IGEgcmVhbCBzaWduYXR1cmU"^A^A
+
+   The signature base string would be constructed per the OAuth 1.0a
+   specification [RFC5849] with the following things noted:
+
+   o  The method value is defaulted to POST.
+
+   o  The scheme defaults to be "http", and any port number other than
+      80 is included.
+
+   o  The path defaults to "/".
+
+   o  The query string defaults to "".
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 11]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   In this example, the signature base string with line breaks added for
+   readability would be:
+
+   POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4
+   8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
+   A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7
+
+4.  Examples
+
+   These examples illustrate exchanges between IMAP and SMTP clients and
+   servers.  All IMAP examples use SASL-IR [RFC4959] and send payload in
+   the initial client response.  The bearer token examples assume
+   encrypted transport; if the underlying connection is not already TLS,
+   then STARTTLS MUST be used as TLS is required in the bearer token
+   specification.
+
+   Note to implementers: The SASL OAuth method names are case
+   insensitive.  One example uses "Bearer" but that could as easily be
+   "bearer", "BEARER", or "BeArEr".
+
+4.1.  Successful Bearer Token Exchange
+
+   This example shows a successful OAuth 2.0 bearer token exchange in
+   IMAP.  Note that line breaks are inserted for readability.
+
+   [Initial connection and TLS establishment...]
+   S: * OK IMAP4rev1 Server Ready
+   C: t0 CAPABILITY
+   S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
+   S: t0 OK Completed
+   C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhv
+         c3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyI
+         HZGOWRmdDRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQ
+         EB
+   S: t1 OK SASL authentication succeeded
+
+   As required by IMAP [RFC3501], the payloads are base64 encoded.  The
+   decoded initial client response (with %x01 represented as ^A and long
+   lines wrapped for readability) is:
+
+   n,a=user@example.com,^Ahost=server.example.com^Aport=143^A
+   auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 12]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   The same credential used in an SMTP exchange is shown below.  Again,
+   this example assumes that TLS is already established per the bearer
+   token specification requirements.
+
+   [connection begins]
+   S: 220 mx.example.com ESMTP 12sm2095603fks.9
+   C: EHLO sender.example.com
+   S: 250-mx.example.com at your service,[172.31.135.47]
+   S: 250-SIZE 35651584
+   S: 250-8BITMIME
+   S: 250-AUTH LOGIN PLAIN OAUTHBEARER
+   S: 250-ENHANCEDSTATUSCODES
+   S: 250-STARTTLS
+   S: 250 PIPELINING
+   [Negotiate TLS...]
+   C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2Vy
+         dmVyLmV4YW1wbGUuY29tAXBvcnQ9NTg3AWF1dGg9QmVhcmVyIHZGOWRmd
+         DRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
+   S: 235 Authentication successful.
+   [connection continues...]
+
+   The decoded initial client response is:
+
+   n,a=user@example.com,^Ahost=server.example.com^Aport=587^A
+   auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
+
+4.2.  Successful OAuth 1.0a Token Exchange
+
+   This IMAP example shows a successful OAuth 1.0a token exchange.  Note
+   that line breaks are inserted for readability.  This example assumes
+   that TLS is already established.  Signature computation is discussed
+   in Section 3.3.
+
+   S: * OK IMAP4rev1 Server Ready
+   C: t0 CAPABILITY
+   S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER AUTH=OAUTH10A SASL-IR
+   S: t0 OK Completed
+   C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
+         XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
+         dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
+         ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy
+         1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I
+         jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1
+         WVhSMWNtVSUzRCIBAQ==
+   S: t1 OK SASL authentication succeeded
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 13]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   As required by IMAP [RFC3501], the payloads are base64 encoded.  The
+   decoded initial client response (with %x01 represented as ^A and
+   lines wrapped for readability) is:
+
+   n,a=user@example.com,^A
+   host=example.com^A
+   port=143^A
+   auth=OAuth realm="Example",
+              oauth_consumer_key="9djdj82h48djs9d2",
+              oauth_token="kkk9d7dh3k39sjv7",
+              oauth_signature_method="HMAC-SHA1",
+              oauth_timestamp="137131201",
+              oauth_nonce="7d8f3e4a",
+              oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
+
+4.3.  Failed Exchange
+
+   This IMAP example shows a failed exchange because of the empty
+   Authorization header, which is how a client can query for the needed
+   scope.  Note that line breaks are inserted for readability.
+
+   S: * OK IMAP4rev1 Server Ready
+   C: t0 CAPABILITY
+   S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
+   S: t0 OK Completed
+   C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
+         hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
+   S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
+        X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
+        YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
+        In0=
+   C: AQ==
+   S: t1 NO SASL authentication failed
+
+   The decoded initial client response is:
+
+   n,a=user@example.com,^Ahost=server.example.com^A
+   port=143^Aauth=^A^A
+
+   The decoded server error response is:
+
+  {
+  "status":"invalid_token",
+  "scope":"example_scope",
+  "openid-configuration":"https://example.com/.well-known/openid-config"
+  }
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 14]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   The client responds with the required dummy response; "AQ==" is the
+   base64 encoding of the ASCII value 0x01.  The same exchange using the
+   IMAP-specific method of canceling an AUTHENTICATE command sends "*"
+   and is shown below.
+
+   S: * OK IMAP4rev1 Server Ready
+   C: t0 CAPABILITY
+   S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1
+   S: t0 OK Completed
+   C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
+        hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
+   S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
+        X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
+        YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
+        In0=
+   C: *
+   S: t1 NO SASL authentication failed
+
+4.4.  SMTP Example of a Failed Negotiation
+
+   This example shows an authorization failure in an SMTP exchange.  TLS
+   negotiation is not shown, but as noted above, it is required for the
+   use of bearer tokens.
+
+[connection begins]
+S: 220 mx.example.com ESMTP 12sm2095603fks.9
+C: EHLO sender.example.com
+S: 250-mx.example.com at your service,[172.31.135.47]
+S: 250-SIZE 35651584
+S: 250-8BITMIME
+S: 250-AUTH LOGIN PLAIN OAUTHBEARER
+S: 250-ENHANCEDSTATUSCODES
+S: 250 PIPELINING
+[Negotiate TLS...]
+C: AUTH OAUTHBEARER bix1c2VyPXNvbWV1c2VyQGV4YW1wbGUuY29tLAFhdXRoPUJlYXJl
+       ciB2RjlkZnQ0cW1UYzJOdmIzUmxja0JoZEhSaGRtbHpkR0V1WTI5dENnPT0BAQ==
+S: 334 eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NoZW1lcyI6ImJlYXJlciBtYWMiL
+       CJzY29wZSI6Imh0dHBzOi8vbWFpbC5leGFtcGxlLmNvbS8ifQ==
+C: AQ==
+S: 535-5.7.1 Username and Password not accepted. Learn more at
+S: 535 5.7.1 http://support.example.com/mail/oauth
+[connection continues...]
+
+   The initial client response is:
+
+   n,user=someuser@example.com,^A
+   auth=Bearer vF9dft4qmTc2Nvb3RlckBhdHRhdmlzdGEuY29tCg==^A^A
+
+
+
+
+Mills, et al.                Standards Track                   [Page 15]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   The server returned an error message in the 334 SASL message; the
+   client responds with the required dummy response, and the server
+   finalizes the negotiation.
+
+   {
+       "status":"invalid_token",
+       "schemes":"bearer mac",
+       "scope":"https://mail.example.com/"
+   }
+
+5.  Security Considerations
+
+   OAuth 1.0a and OAuth 2.0 allow for a variety of deployment scenarios,
+   and the security properties of these profiles vary.  As shown in
+   Figure 1, this specification is aimed to be integrated into a larger
+   OAuth deployment.  Application developers therefore need to
+   understand their security requirements based on a threat assessment
+   before selecting a specific SASL OAuth mechanism.  For OAuth 2.0, a
+   detailed security document [RFC6819] provides guidance to select
+   those OAuth 2.0 components that help to mitigate threats for a given
+   deployment.  For OAuth 1.0a, Section 4 of [RFC5849] provides guidance
+   specific to OAuth 1.0a.
+
+   This document specifies two SASL Mechanisms for OAuth and each comes
+   with different security properties.
+
+   OAUTHBEARER:  This mechanism borrows from OAuth 2.0 bearer tokens
+      [RFC6750].  It relies on the application using TLS to protect the
+      OAuth 2.0 bearer token exchange; without TLS usage at the
+      application layer, this method is completely insecure.
+      Consequently, TLS MUST be provided by the application when
+      choosing this authentication mechanism.
+
+   OAUTH10A:  This mechanism reuses OAuth 1.0a MAC tokens (using the
+      HMAC-SHA1 keyed message digest), as described in Section 3.4.2 of
+      [RFC5849].  To compute the keyed message digest in the same way as
+      in RFC 5839, this specification conveys additional parameters
+      between the client and the server.  This SASL mechanism only
+      supports client authentication.  If server-side authentication is
+      desirable, then it must be provided by the application underneath
+      the SASL layer.  The use of TLS is strongly RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 16]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   Additionally, the following aspects are worth pointing out:
+
+   An access token is not equivalent to the user's long term password.
+
+      Care has to be taken when these OAuth credentials are used for
+      actions like changing passwords (as it is possible with some
+      protocols, e.g., XMPP [RFC6120]).  The resource server should
+      ensure that actions taken in the authenticated channel are
+      appropriate to the strength of the presented credential.
+
+   Lifetime of the application sessions.
+
+      It is possible that SASL will be used to authenticate a
+      connection, and the life of that connection may outlast the life
+      of the access token used to establish it.  This is a common
+      problem in application protocols where connections are long lived
+      and not a problem with this mechanism, per se.  Resource servers
+      may unilaterally disconnect clients in accordance with the
+      application protocol.
+
+   Access tokens have a lifetime.
+
+      Reducing the lifetime of an access token provides security
+      benefits, and OAuth 2.0 introduces refresh tokens to obtain new
+      access tokens on the fly without any need for human interaction.
+      Additionally, a previously obtained access token might be revoked
+      or rendered invalid at any time.  The client MAY request a new
+      access token for each connection to a resource server, but it
+      SHOULD cache and reuse valid credentials.
+
+6.  Internationalization Considerations
+
+   The identifier asserted by the OAuth authorization server about the
+   resource owner inside the access token may be displayed to a human.
+   For example, when SASL is used in the context of IMAP, the client may
+   assert the resource owner's email address to the IMAP server for
+   usage in an email-based application.  The identifier may therefore
+   contain internationalized characters, and an application needs to
+   ensure that the mapping between the identifier provided by OAuth is
+   suitable for use with the application-layer protocol SASL is
+   incorporated into.  An example of a SASL-compatible container is the
+   JSON Web Token (JWT) [RFC7519], which provides a standardized format
+   for exchanging authorization and identity information that supports
+   internationalized characters.
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 17]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+7.  IANA Considerations
+
+7.1.  SASL Registration
+
+   The IANA has registered the following entry in the SASL Mechanisms
+   registry:
+
+      SASL mechanism name: OAUTHBEARER
+
+      Security Considerations: See this document
+
+      Published Specification: See this document
+
+      For further information: Contact the authors of this document.
+
+      Intended usage: COMMON
+
+      Owner/Change controller: the IESG
+
+      Note: None
+
+   The IANA has registered the following entry in the SASL Mechanisms
+   registry:
+
+      SASL mechanism name: OAUTH10A
+
+      Security Considerations: See this document
+
+      Published Specification: See this document
+
+      For further information: Contact the authors of this document.
+
+      Intended usage: COMMON
+
+      Owner/Change controller: the IESG
+
+      Note: None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 18]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+8.  References
+
+8.1.  Normative References
+
+   [OpenID.Core]
+              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
+              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
+              <http://openid.net/specs/openid-connect-core-1_0.html>.
+
+   [OpenID.Discovery]
+              Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
+              Connect Discovery 1.0", November 2014,
+              <http://openid.net/specs/
+              openid-connect-discovery-1_0.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              DOI 10.17487/RFC4422, June 2006,
+              <http://www.rfc-editor.org/info/rfc4422>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <http://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5801]  Josefsson, S. and N. Williams, "Using Generic Security
+              Service Application Program Interface (GSS-API) Mechanisms
+              in Simple Authentication and Security Layer (SASL): The
+              GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
+              July 2010, <http://www.rfc-editor.org/info/rfc5801>.
+
+   [RFC5849]  Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849,
+              DOI 10.17487/RFC5849, April 2010,
+              <http://www.rfc-editor.org/info/rfc5849>.
+
+
+
+Mills, et al.                Standards Track                   [Page 19]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
+              RFC 6749, DOI 10.17487/RFC6749, October 2012,
+              <http://www.rfc-editor.org/info/rfc6749>.
+
+   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
+              Framework: Bearer Token Usage", RFC 6750,
+              DOI 10.17487/RFC6750, October 2012,
+              <http://www.rfc-editor.org/info/rfc6750>.
+
+   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
+              2014, <http://www.rfc-editor.org/info/rfc7159>.
+
+   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
+              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
+              RFC 7591, DOI 10.17487/RFC7591, July 2015,
+              <http://www.rfc-editor.org/info/rfc7591>.
+
+8.2.  Informative References
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <http://www.rfc-editor.org/info/rfc3501>.
+
+   [RFC4959]  Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
+              Simple Authentication and Security Layer (SASL) Initial
+              Client Response", RFC 4959, DOI 10.17487/RFC4959,
+              September 2007, <http://www.rfc-editor.org/info/rfc4959>.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              DOI 10.17487/RFC5321, October 2008,
+              <http://www.rfc-editor.org/info/rfc5321>.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+              March 2011, <http://www.rfc-editor.org/info/rfc6120>.
+
+   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
+              Threat Model and Security Considerations", RFC 6819,
+              DOI 10.17487/RFC6819, January 2013,
+              <http://www.rfc-editor.org/info/rfc6819>.
+
+   [RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
+              "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
+              2013, <http://www.rfc-editor.org/info/rfc7033>.
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 20]
+
+RFC 7628                       SASL OAuth                    August 2015
+
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+              <http://www.rfc-editor.org/info/rfc7519>.
+
+Acknowledgements
+
+   The authors would like to thank the members of the KITTEN working
+   group and in addition and specifically: Simon Josefson, Torsten
+   Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico
+   Williams, Matt Miller, and Benjamin Kaduk.
+
+   This document was produced under the chairmanship of Alexey Melnikov,
+   Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman, Matthew Miller, and
+   Benjamin Kaduk.  The supervising Area Director was Stephen Farrell.
+
+Authors' Addresses
+
+   William Mills
+   Microsoft
+
+   Email: wmills_92105@yahoo.com
+
+
+   Tim Showalter
+
+   Email: tjs@psaux.com
+
+
+   Hannes Tschofenig
+   ARM Ltd.
+   110 Fulbourn Rd
+   Cambridge  CB1 9NJ
+   United Kingdom
+
+   Email: Hannes.tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+
+
+
+
+
+
+
+
+Mills, et al.                Standards Track                   [Page 21]
+
diff --git a/doc/rfcs/rfc7677.txt b/doc/rfcs/rfc7677.txt
new file mode 100644
index 0000000..d90ea86
--- /dev/null
+++ b/doc/rfcs/rfc7677.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         T. Hansen
+Request for Comments: 7677                             AT&T Laboratories
+Updates: 5802                                              November 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                  SCRAM-SHA-256 and SCRAM-SHA-256-PLUS
+       Simple Authentication and Security Layer (SASL) Mechanisms
+
+Abstract
+
+   This document registers the Simple Authentication and Security Layer
+   (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides
+   guidance for secure implementation of the original SCRAM-SHA-1-PLUS
+   mechanism, and updates the SCRAM registration procedures of RFC 5802.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7677.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Hansen                       Standards Track                    [Page 1]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Key Word Definitions  . . . . . . . . . . . . . . . . . . . .   2
+   3.  SCRAM-SHA-256 and SCRAM-SHA-256-PLUS  . . . . . . . . . . . .   2
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
+     5.1.  Updates to SCRAM-* Registration . . . . . . . . . . . . .   4
+     5.2.  SASL-SCRAM Family Mechanisms Registration Procedure . . .   4
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
+   SHA-256-PLUS.  SHA-256 has stronger security properties than SHA-1,
+   and it is expected that SCRAM mechanisms based on it will have
+   greater predicted longevity than the SCRAM mechanisms based on SHA-1.
+
+   The registration form for the SCRAM family of algorithms is also
+   updated from [RFC5802].
+
+   After publication of [RFC5802], it was discovered that Transport
+   Layer Security (TLS) [RFC5246] does not have the expected properties
+   for the "tls-unique" channel binding to be secure [RFC7627].
+   Therefore, this document contains normative text that applies to both
+   the original SCRAM-SHA-1-PLUS and the newly introduced SCRAM-SHA-
+   256-PLUS mechanism.
+
+2.  Key Word Definitions
+
+   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 [RFC2119].
+
+3.  SCRAM-SHA-256 and SCRAM-SHA-256-PLUS
+
+   The SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms are defined
+   in the same way that SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are defined in
+   [RFC5802], except that the hash function for HMAC() and H() uses
+   SHA-256 instead of SHA-1 [RFC6234].
+
+   For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the
+   hash iteration-count announced by a server SHOULD be at least 4096.
+
+
+
+
+Hansen                       Standards Track                    [Page 2]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+   The GSS-API mechanism OID for SCRAM-SHA-256 is 1.3.6.1.5.5.18 (see
+   Section 5).
+
+   This is a simple example of a SCRAM-SHA-256 authentication exchange
+   when the client doesn't support channel bindings.  The username
+   'user' and password 'pencil' are being used.
+
+   C: n,,n=user,r=rOprNGfwEbeRWgbNEkqO
+
+   S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
+      s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096
+
+   C: c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
+      p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
+
+   S: v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
+
+4.  Security Considerations
+
+   The security considerations from [RFC5802] still apply.
+
+   To be secure, either SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS MUST be
+   used over a TLS channel that has had the session hash extension
+   [RFC7627] negotiated, or session resumption MUST NOT have been used.
+
+   See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a
+   strong security mechanism like SHA-256.
+
+   The strength of this mechanism is dependent in part on the hash
+   iteration-count, as denoted by "i" in [RFC5802].  As a rule of thumb,
+   the hash iteration-count should be such that a modern machine will
+   take 0.1 seconds to perform the complete algorithm; however, this is
+   unlikely to be practical on mobile devices and other relatively low-
+   performance systems.  At the time this was written, the rule of thumb
+   gives around 15,000 iterations required; however, a hash iteration-
+   count of 4096 takes around 0.5 seconds on current mobile handsets.
+   This computational cost can be avoided by caching the ClientKey
+   (assuming the Salt and hash iteration-count is stable).  Therefore,
+   the recommendation of this specification is that the hash iteration-
+   count SHOULD be at least 4096, but careful consideration ought to be
+   given to using a significantly higher value, particularly where
+   mobile use is less important.
+
+
+
+
+
+
+
+
+
+Hansen                       Standards Track                    [Page 3]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+5.  IANA Considerations
+
+5.1.  Updates to SCRAM-* Registration
+
+   The IANA registry for SCRAM-* (the SCRAM family of SASL mechanisms)
+   in the SASL mechanism registry ([RFC4422]) has been updated as
+   follows.  The email address for reviews has been updated, and the
+   note at the end changed.
+
+      To: iana@iana.org
+      Subject: Registration of a new SASL family SCRAM
+
+      SASL mechanism name (or prefix for the family): SCRAM-*
+      Security considerations: Section 7 of [RFC5802]
+      Published specification (optional, recommended): RFC 7677
+      Person & email address to contact for further information:
+         IETF KITTEN WG <kitten@ietf.org>
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+      Note: Members of this family MUST be explicitly registered using
+         the "IETF Review" [RFC5226] registration procedure.  Reviews
+         MUST be requested on the KITTEN mailing list kitten@ietf.org
+         (or a successor designated by the responsible Security AD).
+
+      Note to future SCRAM-mechanism designers: each new SASL SCRAM
+      mechanism MUST be explicitly registered with IANA within the SASL
+      SCRAM Family Mechanisms registry.
+
+5.2.  SASL-SCRAM Family Mechanisms Registration Procedure
+
+   A new IANA registry has been added for members of the SCRAM family of
+   SASL mechanisms, named "SASL SCRAM Family Mechanisms".  It adds two
+   new fields to the existing SCRAM mechanism registry: Minimum
+   iteration-count and Associated OID.  Below is the template for
+   registration of a new SASL family SCRAM.  (Note that the string
+   "TBD-BY-IANA" should be left as is, so that it may be filled in at
+   registration time by IANA.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen                       Standards Track                    [Page 4]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+      To: iana@iana.org
+      Subject: Registration of a new SASL SCRAM family mechanism
+
+      SASL mechanism name (or prefix for the family): SCRAM-<NAME>
+      Security considerations: Section 7 of [RFC5802]
+      Published specification (optional, recommended): RFC 7677
+      Minimum iteration-count: The minimum hash iteration-count that
+         servers SHOULD announce
+      Associated OID: TBD-BY-IANA
+      Person & email address to contact for further information:
+         IETF KITTEN WG <kitten@ietf.org>
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+
+      Note: Members of this family MUST be explicitly registered using
+      the "IETF Review" [RFC5226] registration procedure.  Reviews MUST
+      be requested on the KITTEN mailing list kitten@ietf.org (or a
+      successor designated by the responsible Security Area Director).
+
+      Note: At publication of a new SASL SCRAM Family Mechanism, IANA
+      SHOULD assign a GSS-API mechanism OID for this mechanism from the
+      iso.org.dod.internet.security.mechanisms prefix (see the "SMI
+      Security for Mechanism Codes" registry) and fill in the value for
+      "TBD-BY-IANA" above.  Only one OID needs to be assigned for a
+      SCRAM-<NAME> and SCRAM-<NAME>-PLUS pair.  The same OID should be
+      assigned to both entries in the registry.
+
+      Note to future SASL SCRAM mechanism designers: each new SASL SCRAM
+      mechanism MUST be explicitly registered with IANA and MUST comply
+      with the SCRAM-mechanism naming convention defined in Section 4 of
+      [RFC5802].
+
+   The existing entries for SASL SCRAM-SHA-1 and SCRAM-SHA-1-PLUS have
+   been moved from the existing SASL mechanism registry to the "SASL
+   SCRAM Family Mechanisms" registry.  At that time, the following
+   values were added:
+
+      Minimum iteration-count: 4096
+      OID: 1.3.6.1.5.5.14 (from [RFC5802])
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen                       Standards Track                    [Page 5]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+   The following new SASL SCRAM mechanisms have been added to the "SASL
+   SCRAM Family Mechanisms" registry:
+
+      To: iana@iana.org
+      Subject: Registration of a new SASL SCRAM Family mechanism
+         SCRAM-SHA-256
+
+      SASL mechanism name (or prefix for the family): SCRAM-SHA-256
+      Security considerations: Section 4 of RFC 7677
+      Published specification (optional, recommended): RFC 7677
+      Minimum iteration-count: 4096
+      OID: 1.3.6.1.5.5.18
+      Person & email address to contact for further information:
+         IETF KITTEN WG <kitten@ietf.org>
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+      Note:
+
+      To: iana@iana.org
+      Subject: Registration of a new SASL SCRAM Family mechanism
+         SCRAM-SHA-256-PLUS
+
+      SASL mechanism name (or prefix for the family): SCRAM-SHA-256-PLUS
+      Security considerations: Section 4 of RFC 7677
+      Published specification (optional, recommended): RFC 7677
+      Minimum iteration-count: 4096
+      OID: 1.3.6.1.5.5.18
+      Person & email address to contact for further information:
+         IETF KITTEN WG <kitten@ietf.org>
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+      Note:
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              DOI 10.17487/RFC4422, June 2006,
+              <http://www.rfc-editor.org/info/rfc4422>.
+
+
+
+
+
+Hansen                       Standards Track                    [Page 6]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+   [RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
+              "Salted Challenge Response Authentication Mechanism
+              (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
+              DOI 10.17487/RFC5802, July 2010,
+              <http://www.rfc-editor.org/info/rfc5802>.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
+              DOI 10.17487/RFC6234, May 2011,
+              <http://www.rfc-editor.org/info/rfc6234>.
+
+   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
+              Langley, A., and M. Ray, "Transport Layer Security (TLS)
+              Session Hash and Extended Master Secret Extension",
+              RFC 7627, DOI 10.17487/RFC7627, September 2015,
+              <http://www.rfc-editor.org/info/rfc7627>.
+
+6.2.  Informative References
+
+   [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
+              Hashes in Internet Protocols", RFC 4270,
+              DOI 10.17487/RFC4270, November 2005,
+              <http://www.rfc-editor.org/info/rfc4270>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
+              Considerations for the SHA-0 and SHA-1 Message-Digest
+              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
+              <http://www.rfc-editor.org/info/rfc6194>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+Acknowledgements
+
+   This document benefited from discussions on the KITTEN WG mailing
+   list.  The author would like to specially thank Russ Allbery, Dave
+   Cridland, Shawn Emery, Stephen Farrell, Simon Josefsson, Pearl Liang,
+   Alexey Melnikov, Peter Saint-Andre, Robert Sparks, Martin Thompson,
+   and Nico Williams for their comments on this topic.
+
+
+
+
+
+Hansen                       Standards Track                    [Page 7]
+
+RFC 7677          SASL SCRAM-SHA-256/SCRAM-SHA-256-PLUS    November 2015
+
+
+Author's Address
+
+   Tony Hansen
+   AT&T Laboratories
+   200 Laurel Ave. South
+   Middletown, NJ  07748
+   United States
+
+   Email: tony+scramsha256@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen                       Standards Track                    [Page 8]
+