Authentication Methods for LDAP
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4513 — Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
updated by
- rfc-3377 — Lightweight Directory Access Protocol (v3): Technical Specification
Extracted elements (29)
Mandating DIGEST-MD5 as the required password mechanism prevents the scenario where clients implement only cleartext passwords, which provide inadequate security. Without a mandated mechanism, interoperability in authentication cannot be achieved, as clients and servers may support disjoint security mechanisms.
The ANONYMOUS and PLAIN SASL mechanisms are not used with LDAP because LDAP provides native anonymous and plaintext authentication methods. This avoids redundancy and potential confusion between equivalent mechanisms.
The authorization identity may differ from the authentication identity, allowing proxy servers to authenticate with their own credentials while requesting access privileges of the identity they are proxying. The uAuthzId form allows backwards compatibility for clients not using DNs.
There is a strong desire for authentication identities to take the form of Distinguished Names so that authentication data can be stored in the directory itself. This means the stored data must either be useless for faking authentication or never passed across the wire unprotected.
A server MAY support certificate subject name mappings to directory entry names, but a server supporting such mappings MUST also be configurable to support certificates requiring no mapping. This ensures that standard certificate deployments remain interoperable.
The LDAP 'simple' authentication choice is not suitable for authentication on the Internet where there is no network or transport layer confidentiality. If a non-DN authorization identity is requested, a mechanism that protects the password in transit SHOULD be used.
A client or server that supports TLS MUST support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA as a minimum baseline ciphersuite.
A uAuthzId MUST NOT be assumed to be globally unique; its further interpretation is subject to prior agreement between the client and server.
All servers which support the storage of authentication credentials (passwords or certificates) in the directory MUST support the dnAuthzId authorization identity choice.
An LDAP server SHOULD allow an anonymously-bound client to retrieve the supportedSASLMechanisms attribute of the root DSE, even when access controls restrict other directory entries.
For certificate-based authentication, the server MUST request a certificate during TLS negotiation, the client MUST perform a private key-based encryption proving possession of the private key, and the server MUST verify that the client's certificate is valid.
For simple authentication under TLS (section 6.2), the client and server MUST negotiate a ciphersuite containing a bulk encryption algorithm of appropriate strength, and the client MUST send an LDAP bind request with version number 3.
If a SASL EXTERNAL Bind is requested without a prior TLS session and no other external source of authentication credentials exists, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication, leaving the LDAP association in an anonymous state.
If a SASL security layer is negotiated, the client MUST discard all information about the server fetched prior to SASL. The client SHOULD fetch supportedSASLMechanisms both before and after SASL security layer negotiation and verify the value has not changed, to detect active attacks removing supported mechanisms.
If TLS is negotiated, the client MUST discard all information about the server fetched prior to the TLS negotiation. In particular, the value of supportedSASLMechanisms MAY be different after TLS negotiation.
Implementations providing password-based authenticated access MUST support authentication using the DIGEST-MD5 SASL mechanism. This provides client authentication with protection against passive eavesdropping attacks but does not protect against active intermediary attacks.
Implementations SHOULD support authentication with a password under TLS (section 6.2) and SHOULD support authentication with a certificate (section 7.1) for directories needing both session protection and authentication.
LDAP implementations MUST support anonymous authentication as defined in section 5.1. Implementations MAY also support anonymous authentication with TLS.
The ciphersuites TLS_NULL_WITH_NULL_NULL, TLS_RSA_WITH_NULL_MD5, and TLS_RSA_WITH_NULL_SHA MUST NOT be used for confidentiality protection of passwords or data.
Anonymous authentication applies to any LDAP client that has not successfully completed a bind operation on a connection, or that explicitly sends a bind request with a zero-length OCTET STRING using the simple authentication choice.
Certificate-based authentication uses TLS negotiation in which the server requests the client certificate, followed by an LDAPv3 bind request with the SASL 'EXTERNAL' mechanism after successful TLS completion. The user's certificate subject field SHOULD be the name of the user's directory entry.
DIGEST-MD5 authentication is a multi-stage bind procedure: the client sends a bind with sasl mechanism 'DIGEST-MD5' and absent credentials; the server responds with saslBindInProgress and a digest-challenge in serverSaslCreds; the client responds with a digest-response; the server returns success or error, optionally with response-auth for subsequent authentication.
Simple password authentication under TLS requires the client to first complete TLS negotiation using Start TLS, then send an LDAPv3 bind request with the user's DN in the name field and the 'simple' authentication choice containing the password. The server performs case-sensitive equality comparison against each userPassword value.
The SASL service name for LDAP is 'ldap', registered with IANA as a GSSAPI service name. This name is used with various SASL mechanisms such as GSSAPI.
A connection on which the client has not performed the Start TLS operation or negotiated a suitable SASL mechanism for connection integrity and encryption is subject to man-in-the-middle attacks to view and modify information in transit.
Anonymous Diffie-Hellman TLS ciphersuites (TLS_DH_anon_*) are vulnerable to man-in-the-middle attacks and SHOULD NOT be used to protect passwords or sensitive data unless the network configuration makes such attacks tolerable.
Export-grade TLS ciphersuites using 40-bit keys (RC4-40, RC2-CBC-40, DES40) can be cracked in less than a week of CPU time. Clients and servers SHOULD carefully consider the sensitivity of data before using these ciphersuites.
Servers are encouraged to prevent modifications by anonymous users, to time out idle connections to minimize denial of service, and to return unwillingToPerform rather than performing computationally expensive operations requested by unauthorized clients.
The authorization identity (authzId) is a UTF-8 string carried in the SASL credentials field of the LDAP Bind request and response. It has two forms: dnAuthzId = 'dn:' followed by a DN with syntax from RFC 2253, and uAuthzId = 'u:' followed by an unspecified UTF-8 userid string.