rfc2829.txt

RFC 的详细文档！

   dn         = utf8string    ; with syntax defined in RFC 2253

   ; unspecified userid, UTF-8 encoded.
   uAuthzId   = "u:" userid
   userid     = utf8string    ; syntax unspecified

   A utf8string is defined to be the UTF-8 encoding of one or more ISO
   10646 characters.

   All servers which support the storage of authentication credentials,
   such as passwords or certificates, in the directory MUST support the
   dnAuthzId choice.





Wahl, et al.                Standards Track                    [Page 11]

RFC 2829            Authentication Methods for LDAP             May 2000


   The uAuthzId choice allows for compatibility with client applications
   which wish to authenticate to a local directory but do not know their
   own Distinguished Name or have a directory entry.  The format of the
   string is defined as only a sequence of UTF-8 encoded ISO 10646
   characters, and further interpretation is subject to prior agreement
   between the client and server.

   For example, the userid could identify a user of a specific directory
   service, or be a login name or the local-part of an RFC 822 email
   address. In general a uAuthzId MUST NOT be assumed to be globally
   unique.

   Additional authorization identity schemes MAY be defined in future
   versions of this document.

10. TLS Ciphersuites

   The following ciphersuites defined in [6] MUST NOT be used for
   confidentiality protection of passwords or data:

         TLS_NULL_WITH_NULL_NULL
         TLS_RSA_WITH_NULL_MD5
         TLS_RSA_WITH_NULL_SHA

   The following ciphersuites defined in [6] can be cracked easily (less
   than a week of CPU time on a standard CPU in 1997).  The client and
   server SHOULD carefully consider the value of the password or data
   being protected before using these ciphersuites:

         TLS_RSA_EXPORT_WITH_RC4_40_MD5
         TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
         TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
         TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
         TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
         TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
         TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
         TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
         TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

   The following ciphersuites are vulnerable to man-in-the-middle
   attacks, and 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 tolerable:








Wahl, et al.                Standards Track                    [Page 12]

RFC 2829            Authentication Methods for LDAP             May 2000


         TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
         TLS_DH_anon_WITH_RC4_128_MD5
         TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
         TLS_DH_anon_WITH_DES_CBC_SHA
         TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

   A client or server that supports TLS MUST support at least
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

11. SASL service name for LDAP

   For use with SASL [2], a protocol must specify a service name to be
   used with various SASL mechanisms, such as GSSAPI.  For LDAP, the
   service name is "ldap", which has been registered with the IANA as a
   GSSAPI service name.

12. Security Considerations

   Security issues are discussed throughout this memo; the
   (unsurprising) conclusion is that mandatory security is important,
   and that session encryption is required when snooping is a problem.

   Servers are encouraged to prevent modifications by anonymous users.
   Servers may also wish to minimize denial of service attacks by timing
   out idle connections, and returning the unwillingToPerform result
   code rather than performing computationally expensive operations
   requested by unauthorized clients.

   A connection on which the client has not performed the Start TLS
   operation or negotiated a suitable SASL mechanism for connection
   integrity and encryption services is subject to man-in-the-middle
   attacks to view and modify information in transit.

   Additional security considerations relating to the EXTERNAL mechanism
   to negotiate TLS can be found in [2], [5] and [6].

13. Acknowledgements

   This document is a product of the LDAPEXT Working Group of the IETF.
   The contributions of its members is greatly appreciated.











Wahl, et al.                Standards Track                    [Page 13]

RFC 2829            Authentication Methods for LDAP             May 2000


14. Bibliography

   [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

   [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
       2222, October 1997.

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

   [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
       Mechanism", RFC 2831, May 2000.

   [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
       Protocol (v3): Extension for Transport Layer Security", RFC 2830,
       May 2000.

   [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
       2246, January 1999.

   [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
       Specifications: ABNF", RFC 2234, November 1997.

   [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
       Protocol", RFC 2401, November 1998.

























Wahl, et al.                Standards Track                    [Page 14]

RFC 2829            Authentication Methods for LDAP             May 2000


15. Authors' Addresses

   Mark Wahl
   Sun Microsystems, Inc.
   8911 Capital of Texas Hwy #4140
   Austin TX 78759
   USA

   EMail: [e-mail]


   Harald Tveit Alvestrand
   EDB Maxware
   Pirsenteret
   N-7462 Trondheim, Norway

   Phone: [phone]
   EMail: [e-mail]


   Jeff Hodges
   Oblix, Inc.
   18922 Forge Drive
   Cupertino, CA 95014
   USA

   Phone: [phone]
   EMail: [e-mail]


   RL "Bob" Morgan
   Computing and Communications
   University of Washington
   Seattle, WA 98105
   USA

   Phone: [phone]
   EMail: [e-mail]













Wahl, et al.                Standards Track                    [Page 15]

RFC 2829            Authentication Methods for LDAP             May 2000


16.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Wahl, et al.                Standards Track                    [Page 16]