Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
obsoletes
- rfc-2251 — Lightweight Directory Access Protocol (v3)
- rfc-2829 — Authentication Methods for LDAP
- rfc-2830 — Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (30)
The name/password authentication mechanism protected by TLS replaces SASL DIGEST-MD5 as LDAP's mandatory-to-implement password-based authentication mechanism, as experience showed that mandating only optional mechanisms did not lead to interoperability.
The wildcard '*' character is permitted in subjectAltName dNSName values only as the left-most DNS label. For example, *.example.com matches a.example.com but not example.com or a.b.example.com.
A client MUST NOT send a StartTLS request when TLS is currently established, when a multi-stage SASL negotiation is in progress, or when there are outstanding responses for previously issued operations; violation results in an operationsError resultCode.
After a TLS layer is established, the client SHOULD discard or refresh all server information obtained prior to TLS negotiation that was not obtained through secure mechanisms, to protect against man-in-the-middle attacks.
Clients sending a SASL BindRequest SHOULD send a zero-length value in the name field. Servers receiving a SASL BindRequest SHALL ignore any value in the name field.
Clients SHOULD require user selection of the Unauthenticated Authentication Mechanism by means other than empty password input, and SHOULD disallow empty password input in Name/Password Authentication UIs. Servers SHOULD by default fail unauthenticated Bind requests with unwillingToPerform.
If a client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with resultCode of authMethodNotSupported.
If a lower-level security layer (such as TLS) is installed, any SASL layer SHALL be layered on top of it regardless of negotiation order. Removing TLS does not affect the continuing service of the SASL layer.
If the authorization identity is specified in a Bind request, the server MUST verify that the client's authentication identity is permitted to assume the asserted authorization identity, and MUST reject with invalidCredentials if not.
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to ACE format per RFC 3490 before comparison with subjectAltName values of type dNSName.
If the SASL EXTERNAL mechanism is invoked but the client's authentication credentials have not been established at a lower security layer, the SASL EXTERNAL Bind MUST fail with inappropriateAuthentication.
Implementations supporting TLS MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to encourage interoperability with earlier LDAP StartTLS specifications.
LDAP implementations that support any authentication mechanism other than anonymous MUST support the name/password authentication mechanism of the simple Bind method and MUST be capable of protecting it using TLS via StartTLS.
LDAP server implementations MUST support the anonymous authentication mechanism of the simple Bind method.
SASL security layers take effect following the server's transmission and client's reception of the final BindResponse with resultCode success. An established SASL layer is not affected by a failed or non-SASL Bind.
The DN value provided in an unauthenticated Bind is for trace/logging purposes only and MUST NOT be authenticated, validated, or used directly or indirectly for authorization.
To compare uAuthzId values, each MUST be prepared as a 'query' string using SASLprep (RFC 4013) algorithm before octet-wise comparison. A uAuthzId SHOULD NOT be assumed to be globally unique.
To prevent man-in-the-middle attacks, the client MUST verify the server's identity as presented in the server's Certificate message by comparing the reference identity against subjectAltName values.
When the reference identity is an IP address, it MUST be converted to network byte order octet string representation and compared against subjectAltName values of type iPAddress; IPv4 yields 4 octets, IPv6 yields 16 octets.
Where a client intends to perform both a Bind operation and a StartTLS operation, it SHOULD first perform StartTLS so that Bind request and response messages are protected by the established data security services.
Zero-length initial SASL response data is distinguished from absent data by the presence of SaslCredentials.credentials OCTET STRING of length zero; if no initial response is intended, the client MUST omit the OCTET STRING entirely.
SASL authentication in LDAP uses the sasl AuthenticationChoice in BindRequest. Challenges are sent via serverSaslCreds (OCTET STRING) in BindResponse with resultCode saslBindInProgress; client responses use the credentials field in SaslCredentials. LDAP does not Base64-transform these values unlike text-based protocols.
SASL authorization identities (authzId) use the form 'dn:<distinguishedName>' (dnAuthzId) or 'u:<userid>' (uAuthzId) where userid is a sequence of UTF-8 encoded Unicode characters with implementation-specific interpretation.
The simple Bind authentication method provides three mechanisms: anonymous (zero-length name and password), unauthenticated (non-zero name, zero-length password), and name/password (non-zero name and non-zero password as OCTET STRING).
IANA registries updated by this document: LDAP Protocol Mechanism registry (StartTLS OID 1.3.6.1.4.1.1466.20037), LDAP LDAPMessage types (bindRequest 0, bindResponse 1), LDAP Bind Authentication Method (simple 0, sasl 3), and LDAP authzid prefixes (dn:, u:).
A man-in-the-middle attacker can remove StartTLS from the root DSE's 'supportedExtension' attribute. Both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established. Clients MUST warn users or refuse to proceed when the achieved security level is inadequate.
LDAP implementations SHOULD NOT by default support authentication using clear text passwords unless the session is protected by TLS or other data confidentiality mechanisms. Server implementations supporting clear-text password authentication MUST support a policy requiring TLS or equivalent confidentiality protection.
Sessions without data integrity and privacy services (e.g., via StartTLS, IPsec, or SASL) are subject to man-in-the-middle attacks. Client and server implementers SHOULD use data protection services; a resultCode of confidentialityRequired indicates the server requires stronger data confidentiality.
Until data integrity is installed, an attacker can modify 'supportedSASLMechanisms' to downgrade available SASL mechanisms. Clients should retrieve SASL mechanisms both before and after data integrity is installed to detect downgrade attacks; if a stronger mechanism appears post-install, the client should close and reconnect.
Every LDAP session has an authorization state. Upon initial establishment the state is anonymous. Upon receipt of a Bind request the server immediately moves to anonymous state; on successful Bind it moves to the requested authentication state. TLS establishment, change, or closure may also trigger state transitions.