rfc4422.txt

广泛使用的邮件服务器！同时

      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