rfc4513.txt

samba最新软件

   decides that the security level is inadequate for it to continue, it
   SHOULD remove the TLS layer immediately after the TLS (re)negotiation
   has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
   Implementations may reevaluate the security level at any time and,
   upon finding it inadequate, should remove the TLS layer.

3.1.5.  Refresh of Server Capabilities Information

   After a TLS layer is established in an LDAP session, the client
   SHOULD discard or refresh all information about the server that it
   obtained prior to the initiation of the TLS negotiation and that it
   did not obtain through secure mechanisms.  This protects against
   man-in-the-middle attacks that may have altered any server
   capabilities information retrieved prior to TLS layer installation.





Harrison                    Standards Track                    [Page 11]

RFC 4513              LDAP Authentication Methods              June 2006


   The server may advertise different capabilities after installing a
   TLS layer.  In particular, the value of 'supportedSASLMechanisms' may
   be different after a TLS layer has been installed (specifically, the
   EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
   after a TLS layer has been installed).

3.2.  Effect of TLS on Authorization State

   The establishment, change, and/or closure of TLS may cause the
   authorization state to move to a new state.  This is discussed
   further in Section 4.

3.3.  TLS Ciphersuites

   Several issues should be considered when selecting TLS ciphersuites
   that are appropriate for use in a given circumstance.  These issues
   include the following:

      - The ciphersuite's ability to provide adequate confidentiality
        protection for passwords and other data sent over the transport
        connection.  Client and server implementers should recognize
        that some TLS ciphersuites provide no confidentiality
        protection, while other ciphersuites that do provide
        confidentiality protection may be vulnerable to being cracked
        using brute force methods, especially in light of ever-
        increasing CPU speeds that reduce the time needed to
        successfully mount such attacks.

      - Client and server implementers should carefully consider the
        value of the password or data being protected versus the level
        of confidentiality protection provided by the ciphersuite to
        ensure that the level of protection afforded by the ciphersuite
        is appropriate.

      - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
        middle attacks.  Ciphersuites vulnerable to man-in-the-middle
        attacks SHOULD NOT be used to protect passwords or sensitive
        data, unless the network configuration is such that the danger
        of a man-in-the-middle attack is negligible.

      - After a TLS negotiation (either initial or subsequent) is
        completed, both protocol peers should independently verify that
        the security services provided by the negotiated ciphersuite are
        adequate for the intended use of the LDAP session.  If they are
        not, the TLS layer should be closed.






Harrison                    Standards Track                    [Page 12]

RFC 4513              LDAP Authentication Methods              June 2006


4.  Authorization State

   Every LDAP session has an associated authorization state.  This state
   is comprised of numerous factors such as what (if any) authentication
   state has been established, how it was established, and what security
   services are in place.  Some factors may be determined and/or
   affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
   and some factors may be determined by external events (e.g., time of
   day or server load).

   While it is often convenient to view authorization state in
   simplistic terms (as we often do in this technical specification)
   such as "an anonymous state", it is noted that authorization systems
   in LDAP implementations commonly involve many factors that
   interrelate in complex manners.

   Authorization in LDAP is a local matter.  One of the key factors in
   making authorization decisions is authorization identity.  The Bind
   operation (defined in Section 4.2 of [RFC4511] and discussed further
   in Section 5 below) allows information to be exchanged between the
   client and server to establish an authorization identity for the LDAP
   session.  The Bind operation may also be used to move the LDAP
   session to an anonymous authorization state (see Section 5.1.1).

   Upon initial establishment of the LDAP session, the session has an
   anonymous authorization identity.  Among other things this implies
   that the client need not send a BindRequest in the first PDU of the
   LDAP message layer.  The client may send any operation request prior
   to performing a Bind operation, and the server MUST treat it as if it
   had been performed after an anonymous Bind operation (Section 5.1.1).

   Upon receipt of a Bind request, the server immediately moves the
   session to an anonymous authorization state.  If the Bind request is
   successful, the session is moved to the requested authentication
   state with its associated authorization state.  Otherwise, the
   session remains in an anonymous state.

   It is noted that other events both internal and external to LDAP may
   result in the authentication and authorization states being moved to
   an anonymous one.  For instance, the establishment, change, or
   closure of data security services may result in a move to an
   anonymous state, or the user's credential information (e.g.,
   certificate) may have expired.  The former is an example of an event
   internal to LDAP, whereas the latter is an example of an event
   external to LDAP.






Harrison                    Standards Track                    [Page 13]

RFC 4513              LDAP Authentication Methods              June 2006


5.  Bind Operation

   The Bind operation ([RFC4511], Section 4.2) allows authentication
   information to be exchanged between the client and server to
   establish a new authorization state.

   The Bind request typically specifies the desired authentication
   identity.  Some Bind mechanisms also allow the client to specify the
   authorization identity.  If the authorization identity is not
   specified, the server derives it from the authentication identity in
   an implementation-specific manner.

   If the authorization identity is specified, the server MUST verify
   that the client's authentication identity is permitted to assume
   (e.g., proxy for) the asserted authorization identity.  The server
   MUST reject the Bind operation with an invalidCredentials resultCode
   in the Bind response if the client is not so authorized.

5.1.  Simple Authentication Method

   The simple authentication method of the Bind Operation provides three
   authentication mechanisms:

      - An anonymous authentication mechanism (Section 5.1.1).

      - An unauthenticated authentication mechanism (Section 5.1.2).

      - A name/password authentication mechanism using credentials
        consisting of a name (in the form of an LDAP distinguished name
        [RFC4514]) and a password (Section 5.1.3).

5.1.1.  Anonymous Authentication Mechanism of Simple Bind

   An LDAP client may use the anonymous authentication mechanism of the
   simple Bind method to explicitly establish an anonymous authorization
   state by sending a Bind request with a name value of zero length and
   specifying the simple authentication choice containing a password
   value of zero length.

5.1.2.  Unauthenticated Authentication Mechanism of Simple Bind

   An LDAP client may use the unauthenticated authentication mechanism
   of the simple Bind method to establish an anonymous authorization
   state by sending a Bind request with a name value (a distinguished
   name in LDAP string form [RFC4514] of non-zero length) and specifying
   the simple authentication choice containing a password value of zero
   length.




Harrison                    Standards Track                    [Page 14]

RFC 4513              LDAP Authentication Methods              June 2006


   The distinguished name value provided by the client is intended to be
   used for trace (e.g., logging) purposes only.  The value is not to be
   authenticated or otherwise validated (including verification that the
   DN refers to an existing directory object).  The value is not to be
   used (directly or indirectly) for authorization purposes.

   Unauthenticated Bind operations can have significant security issues
   (see Section 6.3.1).  In particular, users intending to perform
   Name/Password Authentication may inadvertently provide an empty
   password and thus cause poorly implemented clients to request
   Unauthenticated access.  Clients SHOULD be implemented to require
   user selection of the Unauthenticated Authentication Mechanism by
   means other than user input of an empty password.  Clients SHOULD
   disallow an empty password input to a Name/Password Authentication
   user interface.  Additionally, Servers SHOULD by default fail
   Unauthenticated Bind requests with a resultCode of
   unwillingToPerform.

5.1.3.  Name/Password Authentication Mechanism of Simple Bind

   An LDAP client may use the name/password authentication mechanism of
   the simple Bind method to establish an authenticated authorization
   state by sending a Bind request with a name value (a distinguished
   name in LDAP string form [RFC4514] of non-zero length) and specifying
   the simple authentication choice containing an OCTET STRING password
   value of non-zero length.

   Servers that map the DN sent in the Bind request to a directory entry
   with an associated set of one or more passwords used with this
   mechanism will compare the presented password to that set of
   passwords.  The presented password is considered valid if it matches
   any member of this set.

   A resultCode of invalidDNSyntax indicates that the DN sent in the
   name value is syntactically invalid.  A resultCode of
   invalidCredentials indicates that the DN is syntactically correct but
   not valid for purposes of authentication, that the password is not
   valid for the DN, or that the server otherwise considers the
   credentials invalid.  A resultCode of success indicates that the
   credentials are valid and that the server is willing to provide
   service to the entity these credentials identify.

   Server behavior is undefined for Bind requests specifying the
   name/password authentication mechanism with a zero-length name value
   and a password value of non-zero length.






Harrison                    Standards Track                    [Page 15]

RFC 4513              LDAP Authentication Methods              June 2006


   The name/password authentication mechanism of the simple Bind method
   is not suitable for authentication in environments without
   confidentiality protection.

5.2.  SASL Authentication Method

   The sasl authentication method of the Bind Operation provides
   facilities for using any SASL mechanism including authentication
   mechanisms and other services (e.g., data security services).

5.2.1.  SASL Protocol Profile

   LDAP allows authentication via any SASL mechanism [RFC4422].  As LDAP
   includes native anonymous and name/password (plain text)
   authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
   SASL mechanisms are typically not used with LDAP.

   Each protocol that utilizes SASL services is required to supply
   certain information profiling the way they are exposed through the
   protocol ([RFC4422], Section 4).  This section explains how each of
   these profiling requirements is met by LDAP.

5.2.1.1.  SASL Service Name for LDAP

   The SASL service name for LDAP is "ldap", which has been registered
   with the IANA as a SASL service name.

5.2.1.2.  SASL Authentication Initiation and Protocol Exchange

   SASL authentication is initiated via a BindRequest message
   ([RFC4511], Section 4.2) with the following parameters:

      - The version is 3.
      - The AuthenticationChoice is sasl.
      - The mechanism element of the SaslCredentials sequence contains
        the value of the desired SASL mechanism.
      - The optional credentials field of the SaslCredentials sequence
        MAY be used to provide an initial client response for mechanisms
        that are defined to have the client send data first (see
        [RFC4422], Sections 3 and 5).

   In general, a SASL authentication protocol exchange consists of a
   series of server challenges and client responses, the contents of
   which are specific to and defined by the SASL mechanism.  Thus, for
   some SASL authentication mechanisms, it may be necessary for the
   client to respond to one or more server challenges by sending
   BindRequest messages multiple times.  A challenge is indicated by the
   server sending a BindResponse message with the resultCode set to