SASL Authentication Protocol with No Cleartext passwords

Question

As you know, LDAP supports three authentication mechanisms: anonymous, simple and SASL.

The first one is only suitable for particular cases, and therefore I'm not going to talk about that. The second one sends the password in clear, and hence is not suitable if one is not willing to implement it over something like SSL (due to compatibility issues or legal reasons).

This leaves us with the third option: SASL. As listed on IANA, there are several SASL-based authentication mechanisms to pick from. Some of them are obsolete or in limited use, but others are common.

I want to pick a SASL-based authentication mechanism, with the following features:

1. It is password based (in contrast to, say, SecurID, which AFAIK is token based).
2. Its security is not based on an underlying protocol (e.g., SSL).
3. The protocol does not require users' passwords to be stored in clear (for instance, CRAM-MD5 may do this).
4. It is widely implemented.

Could you please suggest my options?

Answer 1

There are two mechanisms used to authenticate an LDAP session:

• simple
• SASL

The simple BIND mechanism takes one of four forms:

• anonymous - null name, null credentials. This is the initial state of a session.
• unauthenticated - non-null name, null credentials. Directory servers should be configured to reject this request because no authentication takes place.
• name/password - name, credentials
• undefined - null name, non-null credentials. The behavior of the server is undefined by the LDAP standards. Directory servers should be configured to reject this request because no authentication takes place.

When an LDAP client connects to directory server, that connection has an anonymous authentication state. The client can request the state be changed by using the BIND request. The BIND can also "reset" the authentication state to anonymous.

The recommended authentication method is simple BIND using either a secure connection (SSL) or a non-secure connection promoted to a secure connection using the StartTLS extended operation. Modern, professional quality directory servers support strong cryptographic hashes of salted passwords to make the construction of dictionaries difficult.

Another method is the SASL GSSAPI mechanism, which avoids transmitting the password altogether.

Another method is the SASL EXTERNAL mechanism, which uses information not provided by LDAP, for example, the client certificate presented during establishment of the secure session.

Another method is the SASL DIGEST-MD5 mechanism which avoids transmitting the password but has the disadvantage of the requirement that the server must have access to the clear-text password or be able to decrypt the user's password, which means using a reversible password storage scheme. DIGEST-MD5 should be avoided for this reason. If DIGEST-MD5 is required, AES might be the best block cipher.

CRAM-MD5 is weaker than DIGEST-MD5, and should be avoided.

see also

• LDAP: Authentication Best Practices

Answer 2

You don't really have an option I'm afraid.

SCRAM does what you want, but isn't widely implemented, and as you've seen CRAM-MD5 is fairly weak.