rfc4513.txt

samba最新软件

   All security gained via use of the StartTLS operation is gained by
   the use of TLS itself.  The StartTLS operation, on its own, does not
   provide any additional security.

   The level of security provided through the use of TLS depends
   directly on both the quality of the TLS implementation used and the
   style of usage of that implementation.  Additionally, a man-in-the-
   middle attacker can remove the StartTLS extended operation from the
   'supportedExtension' attribute of the root DSE.  Both parties SHOULD
   independently ascertain and consent to the security level achieved
   once TLS is established and before beginning use of the TLS-
   protected session.  For example, the security level of the TLS layer
   might have been negotiated down to plaintext.

   Clients MUST either warn the user when the security level achieved
   does not provide an acceptable level of data confidentiality and/or
   data integrity protection, or be configurable to refuse to proceed
   without an acceptable level of security.

   As stated in Section 3.1.2, a server may use a local security policy
   to determine whether to successfully complete TLS negotiation.
   Information in the user's certificate that is originated or verified
   by the certification authority should be used by the policy
   administrator when configuring the identification and authorization
   policy.

   Server implementers SHOULD allow server administrators to elect
   whether and when data confidentiality and integrity are required, as
   well as elect whether authentication of the client during the TLS
   handshake is required.

   Implementers should be aware of and understand TLS security
   considerations as discussed in the TLS specification [RFC4346].



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


6.3.  Bind Operation Security Considerations

   This section discusses several security considerations relevant to
   LDAP authentication via the Bind operation.

6.3.1.  Unauthenticated Mechanism Security Considerations

   Operational experience shows that clients can (and frequently do)
   misuse the unauthenticated authentication mechanism of the simple
   Bind method (see Section 5.1.2).  For example, a client program might
   make a decision to grant access to non-directory information on the
   basis of successfully completing a Bind operation.  LDAP server
   implementations may return a success response to an unauthenticated
   Bind request.  This may erroneously leave the client with the
   impression that the server has successfully authenticated the
   identity represented by the distinguished name when in reality, an
   anonymous authorization state has been established.  Clients that use
   the results from a simple Bind operation to make authorization
   decisions should actively detect unauthenticated Bind requests (by
   verifying that the supplied password is not empty) and react
   appropriately.

6.3.2.  Name/Password Mechanism Security Considerations

   The name/password authentication mechanism of the simple Bind method
   discloses the password to the server, which is an inherent security
   risk.  There are other mechanisms, such as SASL DIGEST-MD5
   [DIGEST-MD5], that do not disclose the password to the server.

6.3.3.  Password-Related Security Considerations

   LDAP allows multi-valued password attributes.  In systems where
   entries are expected to have one and only one password,
   administrative controls should be provided to enforce this behavior.

   The use of clear text passwords and other unprotected authentication
   credentials is strongly discouraged over open networks when the
   underlying transport service cannot guarantee confidentiality.  LDAP
   implementations SHOULD NOT by default support authentication methods
   using clear text passwords and other unprotected authentication
   credentials unless the data on the session is protected using TLS or
   other data confidentiality and data integrity protection.

   The transmission of passwords in the clear -- typically for
   authentication or modification -- poses a significant security risk.
   This risk can be avoided by using SASL authentication [RFC4422]





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


   mechanisms that do not transmit passwords in the clear or by
   negotiating transport or session layer data confidentiality services
   before transmitting password values.

   To mitigate the security risks associated with the transfer of
   passwords, a server implementation that supports any password-based
   authentication mechanism that transmits passwords in the clear MUST
   support a policy mechanism that at the time of authentication or
   password modification, requires that:

         A TLS layer has been successfully installed.

         OR

         Some other data confidentiality mechanism that protects the
         password value from eavesdropping has been provided.

         OR

         The server returns a resultCode of confidentialityRequired for
         the operation (i.e., name/password Bind with password value,
         SASL Bind transmitting a password value in the clear, add or
         modify including a userPassword value, etc.), even if the
         password value is correct.

   Server implementations may also want to provide policy mechanisms to
   invalidate or otherwise protect accounts in situations where a server
   detects that a password for an account has been transmitted in the
   clear.

6.3.4.  Hashed Password Security Considerations

   Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
   the password value that may be vulnerable to offline dictionary
   attacks.  Implementers should take care to protect such hashed
   password values during transmission using TLS or other
   confidentiality mechanisms.

6.4.  SASL Security Considerations

   Until data integrity service is installed on an LDAP session, an
   attacker can modify the transmitted values of the
   'supportedSASLMechanisms' attribute response and thus downgrade the
   list of available SASL mechanisms to include only the least secure
   mechanism.  To detect this type of attack, the client may retrieve
   the SASL mechanisms the server makes available both before and after
   data integrity service is installed on an LDAP session.  If the
   client finds that the integrity-protected list (the list obtained



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


   after data integrity service was installed) contains a stronger
   mechanism than those in the previously obtained list, the client
   should assume the previously obtained list was modified by an
   attacker.  In this circumstance it is recommended that the client
   close the underlying transport connection and then reconnect to
   reestablish the session.

6.5.  Related Security Considerations

   Additional security considerations relating to the various
   authentication methods and mechanisms discussed in this document
   apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
   [RFC3629].

7.  IANA Considerations

   The IANA has updated the LDAP Protocol Mechanism registry to indicate
   that this document and [RFC4511] provide the definitive technical
   specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
   operation.

   The IANA has updated the LDAP LDAPMessage types registry to indicate
   that this document and [RFC4511] provide the definitive technical
   specification for the bindRequest (0) and bindResponse (1) message
   types.

   The IANA has updated the LDAP Bind Authentication Method registry to
   indicate that this document and [RFC4511] provide the definitive
   technical specification for the simple (0) and sasl (3) bind
   authentication methods.

   The IANA has updated the LDAP authzid prefixes registry to indicate
   that this document provides the definitive technical specification
   for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.

8.  Acknowledgements

   This document combines information originally contained in RFC 2251,
   RFC 2829, and RFC 2830.  RFC 2251 was a product of the Access,
   Searching, and Indexing of Directories (ASID) Working Group.  RFC
   2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
   Working Group.

   This document is a product of the IETF LDAP Revision (LDAPBIS)
   working group.






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


9.  Normative References

   [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.

   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
                "Internationalizing Domain Names in Applications
                (IDNA)", RFC 3490, March 2003.

   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

   [RFC4013]    Zeilenga, K., "SASLprep: Stringprep Profile for User
                Names and Passwords", RFC 4013, February 2005.

   [RFC4234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

   [RFC4346]    Dierks, T. and E. Rescorla, "The TLS Protocol Version
                1.1", RFC 4346, March 2006.

   [RFC4422]    Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
                Authentication and Security Layer (SASL)", RFC 4422,
                June 2006.

   [RFC4510]    Zeilenga, K., Ed., "Lightweight Directory Access
                Protocol (LDAP): Technical Specification Road Map", RFC
                4510, June 2006.

   [RFC4511]    Sermersheim, J., Ed., "Lightweight Directory Access
                Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]    Zeilenga, K., "Lightweight Directory Access Protocol
                (LDAP): Directory Information Models", RFC 4512, June
                2006.






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


   [RFC4514]    Zeilenga, K., Ed., "Lightweight Directory Access
                Protocol (LDAP): String Representation of Distinguished
                Names", RFC 4514, June 2006.

   [RFC4517]    Legg, S., Ed., "Lightweight Directory Access Protocol
                (LDAP): Syntaxes and Matching Rules", RFC 4517, June
                2006.

   [RFC4519]    Sciberras, A., Ed., "Lightweight Directory Access
                Protocol (LDAP): Schema for User Applications", RFC
                4519, June 2006.

   [RFC4520]    Zeilenga, K., "Internet Assigned Numbers Authority
                (IANA) Considerations for the Lightweight Directory
                Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

   [Unicode]    The Unicode Consortium, "The Unicode Standard, Version
                3.2.0" is defined by "The Unicode Standard, Version 3.0"
                (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-61633-
                5), as amended by the "Unicode Standard Annex #27:
                Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
                by the "Unicode Standard Annex #28: Unicode 3.2"
                (http://www.unicode.org/reports/tr28/).

   [X.501]      ITU-T Rec. X.501, "The Directory: Models", 1993.

10.  Informative References

   [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
                Authentication