rfc4422.txt

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

   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.