* Update to version 2.19.1

 *  Upgrade UW-IMAP to Panda IMAP from https://github.com/jonabbey/panda-imap.
 *  Replace tabs by spaces in From and Subject fields to control for size in
    screen of these fields. Change only in index screen display.

1 files changed, 1851 insertions, 0 deletions

diff --git a/imap/docs/rfc/rfc4422.txt b/imap/docs/rfc/rfc4422.txt
new file mode 100644
index 00000000..049fa8c5
--- /dev/null
+++ b/imap/docs/rfc/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]
+