rfc4513.txt

samba最新软件

   summarizes the substantive changes made to RFC 2251 by this document.

   This document obsoletes RFC 2829 in its entirety.  Appendix B.2
   summarizes the substantive changes made to RFC 2829 by this document.

   Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511].  The
   remainder of RFC 2830 is obsoleted by this document.  Appendix B.3
   summarizes the substantive changes made to RFC 2830 by this document.

1.2.  Conventions

   The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in RFC 2119 [RFC2119].

   The term "user" represents any human or application entity that is
   accessing the directory using a directory client.  A directory client
   (or client) is also known as a directory user agent (DUA).

   The term "transport connection" refers to the underlying transport
   services used to carry the protocol exchange, as well as associations
   established by these services.

   The term "TLS layer" refers to TLS services used in providing
   security services, as well as associations established by these
   services.

   The term "SASL layer" refers to SASL services used in providing
   security services, as well as associations established by these
   services.

   The term "LDAP message layer" refers to the LDAP Message (PDU)
   services used in providing directory services, as well as
   associations established by these services.




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


   The term "LDAP session" refers to combined services (transport
   connection, TLS layer, SASL layer, LDAP message layer) and their
   associations.

   In general, security terms in this document are used consistently
   with the definitions provided in [RFC2828].  In addition, several
   terms and concepts relating to security, authentication, and
   authorization are presented in Appendix A of this document.  While
   the formal definition of these terms and concepts is outside the
   scope of this document, an understanding of them is prerequisite to
   understanding much of the material in this document.  Readers who are
   unfamiliar with security-related concepts are encouraged to review
   Appendix A before reading the remainder of this document.

2.  Implementation Requirements

   LDAP server implementations MUST support the anonymous authentication
   mechanism of the simple Bind method (Section 5.1.1).

   LDAP implementations that support any authentication mechanism other
   than the anonymous authentication mechanism of the simple Bind method
   MUST support the name/password authentication mechanism of the simple
   Bind method (Section 5.1.3) and MUST be capable of protecting this
   name/password authentication using TLS as established by the StartTLS
   operation (Section 3).

   Implementations SHOULD disallow the use of the name/password
   authentication mechanism by default when suitable data security
   services are not in place, and they MAY provide other suitable data
   security services for use with this authentication mechanism.

   Implementations MAY support additional authentication mechanisms.
   Some of these mechanisms are discussed below.

   LDAP server implementations SHOULD support client assertion of
   authorization identity via the SASL EXTERNAL mechanism (Section
   5.2.3).

   LDAP server implementations that support no authentication mechanism
   other than the anonymous mechanism of the simple bind method SHOULD
   support use of TLS as established by the StartTLS operation (Section
   3).  (Other servers MUST support TLS per the second paragraph of this
   section.)








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


   Implementations supporting TLS MUST support the
   TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.  Support for the
   latter ciphersuite is recommended to encourage interoperability with
   implementations conforming to earlier LDAP StartTLS specifications.

3.  StartTLS Operation

   The Start Transport Layer Security (StartTLS) operation defined in
   Section 4.14 of [RFC4511] provides the ability to establish TLS
   [RFC4346] in an LDAP session.

   The goals of using the TLS protocol with LDAP are to ensure data
   confidentiality and integrity, and to optionally provide for
   authentication.  TLS expressly provides these capabilities, although
   the authentication services of TLS are available to LDAP only in
   combination with the SASL EXTERNAL authentication method (see Section
   5.2.3), and then only if the SASL EXTERNAL implementation chooses to
   make use of the TLS credentials.

3.1.  TLS Establishment Procedures

   This section describes the overall procedures clients and servers
   must follow for TLS establishment.  These procedures take into
   consideration various aspects of the TLS layer including discovery of
   resultant security level and assertion of the client's authorization
   identity.

3.1.1.  StartTLS Request Sequencing

   A client may send the StartTLS extended request at any time after
   establishing an LDAP session, except:

      - when TLS is currently established on the session,
      - when a multi-stage SASL negotiation is in progress on the
        session, or
      - when there are outstanding responses for operation requests
        previously issued on the session.

   As described in [RFC4511], Section 4.14.1, a (detected) violation of
   any of these requirements results in a return of the operationsError
   resultCode.

   Client implementers should ensure that they strictly follow these
   operation sequencing requirements to prevent interoperability issues.
   Operational experience has shown that violating these requirements





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


   causes interoperability issues because there are race conditions that
   prevent servers from detecting some violations of these requirements
   due to factors such as server hardware speed and network latencies.

   There is no general requirement that the client have or have not
   already performed a Bind operation (Section 5) before sending a
   StartTLS operation request; however, where a client intends to
   perform both a Bind operation and a StartTLS operation, it SHOULD
   first perform the StartTLS operation so that the Bind request and
   response messages are protected by the data security services
   established by the StartTLS operation.

3.1.2.  Client Certificate

   If an LDAP server requests or demands that a client provide a user
   certificate during TLS negotiation and the client does not present a
   suitable user certificate (e.g., one that can be validated), the
   server may use a local security policy to determine whether to
   successfully complete TLS negotiation.

   If a client that has provided a suitable certificate subsequently
   performs a Bind operation using the SASL EXTERNAL authentication
   mechanism (Section 5.2.3), information in the certificate may be used
   by the server to identify and authenticate the client.

3.1.3.  Server Identity Check

   In order to prevent man-in-the-middle attacks, the client MUST verify
   the server's identity (as presented in the server's Certificate
   message).  In this section, the client's understanding of the
   server's identity (typically the identity used to establish the
   transport connection) is called the "reference identity".

   The client determines the type (e.g., DNS name or IP address) of the
   reference identity and performs a comparison between the reference
   identity and each subjectAltName value of the corresponding type
   until a match is produced.  Once a match is produced, the server's
   identity has been verified, and the server identity check is
   complete.  Different subjectAltName types are matched in different
   ways.  Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
   various subjectAltName types.

   The client may map the reference identity to a different type prior
   to performing a comparison.  Mappings may be performed for all
   available subjectAltName types to which the reference identity can be
   mapped; however, the reference identity should only be mapped to
   types for which the mapping is either inherently secure (e.g.,
   extracting the DNS name from a URI to compare with a subjectAltName



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


   of type dNSName) or for which the mapping is performed in a secure
   manner (e.g., using DNSSEC, or using user- or admin-configured host-
   to-address/address-to-host lookup tables).

   The server's identity may also be verified by comparing the reference
   identity to the Common Name (CN) [RFC4519] value in the leaf Relative
   Distinguished Name (RDN) of the subjectName field of the server's
   certificate.  This comparison is performed using the rules for
   comparison of DNS names in Section 3.1.3.1, below, with the exception
   that no wildcard matching is allowed.  Although the use of the Common
   Name value is existing practice, it is deprecated, and Certification
   Authorities are encouraged to provide subjectAltName values instead.
   Note that the TLS implementation may represent DNs in certificates
   according to X.500 or other conventions.  For example, some X.500
   implementations order the RDNs in a DN using a left-to-right (most
   significant to least significant) convention instead of LDAP's
   right-to-left convention.

   If the server identity check fails, user-oriented clients SHOULD
   either notify the user (clients may give the user the opportunity to
   continue with the LDAP session in this case) or close the transport
   connection and indicate that the server's identity is suspect.
   Automated clients SHOULD close the transport connection and then
   return or log an error indicating that the server's identity is
   suspect or both.

   Beyond the server identity check described in this section, clients
   should be prepared to do further checking to ensure that the server
   is authorized to provide the service it is requested to provide.  The
   client may need to make use of local policy information in making
   this determination.

3.1.3.1.  Comparison of DNS Names

   If the reference identity is an internationalized domain name,
   conforming implementations MUST convert it to the ASCII Compatible
   Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
   before comparison with subjectAltName values of type dNSName.
   Specifically, conforming implementations MUST perform the conversion
   operation specified in Section 4 of RFC 3490 as follows:

      * in step 1, the domain name SHALL be considered a "stored
        string";
      * in step 3, set the flag called "UseSTD3ASCIIRules";
      * in step 4, process each label with the "ToASCII" operation; and
      * in step 5, change all label separators to U+002E (full stop).





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


   After performing the "to-ASCII" conversion, the DNS labels and names
   MUST be compared for equality according to the rules specified in
   Section 3 of RFC3490.

   The '*' (ASCII 42) wildcard character is allowed in subjectAltName
   values of type dNSName, and then only as the left-most (least
   significant) DNS label in that value.  This wildcard matches any
   left-most DNS label in the server name.  That is, the subject
   *.example.com matches the server names a.example.com and
   b.example.com, but does not match example.com or a.b.example.com.

3.1.3.2.  Comparison of IP Addresses

   When the reference identity is an IP address, the identity MUST be
   converted to the "network byte order" octet string representation
   [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
   octet string will contain exactly four octets.  For IP Version 6, as
   specified in RFC 2460, the octet string will contain exactly sixteen
   octets.  This octet string is then compared against subjectAltName
   values of type iPAddress.  A match occurs if the reference identity
   octet string and value octet strings are identical.

3.1.3.3.  Comparison of Other subjectName Types

   Client implementations MAY support matching against subjectAltName
   values of other types as described in other documents.

3.1.4.  Discovery of Resultant Security Level

   After a TLS layer is established in an LDAP session, both parties are
   to each independently decide whether or not to continue based on
   local policy and the security level achieved.  If either party