rfc4422.txt

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

   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 <[e-mail]>.

   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