RE: Authentication Methods for LDAP - last call (mandatory CRAM-M D5)

[Paul Leach <paulle@microsoft.com>]

I propose the following replacement for section 8.1. It uses the HTTP Digest
access authentication mechanism instead of CRAM-MD5. It is both a much
stronger mechanism than CRAM-MD5, and it will very convenient to only have
one mechanism that works for both LDAP and HTTP. I have also been working
with Chris Newman to also adapt it for mail protocols such as IMAP and POP.

I made the replacement mostly by substitution into the previous section for
CRAM-MD5. I beleive I can do the same for IMAP and POP with the same kind of
simple substitution into RFC 2195...

(NB -- the examples don't compute...I'll correct them if this flies)

8.1. Digest authentication

A client which has a password available to the directory (e.g. stored in the
userPassword attribute of the client's directory entry) MAY authenticate to
the directory by performing a protected password bind sequence based on the
Digest mechanism [4].  

An LDAP client may determine whether the server supports this mechanism by
performing a search request on the root DSE, requesting the
supportedSASLMechanisms attribute, and checking whether the string "Digest"
is present as a value of this attribute.

In the first stage of authentication, the client sends a bind request in
which the version number is 3, the name field is the name of the user's
entry (if known to the client), the authentication choice is sasl, the sasl
mechanism name is "Digest", and the credentials are absent.  The client then
waits for a response from the server to this request.

The server shall generate a challenge and return a bind response in which
the resultCode is saslBindInProgress, and the serverSaslCreds field is
present.  The contents of the serverSaslCreds string is a
"digest-challenge", as defined in [draft-ietf-http-authentication-01].  An
example challenge is
realm="postoffice.reston.mci.net",nonce="34af5690dcfe"
Note that in this stage of the mechanism, the server need not access the
user's password. The server will save the challenge (in this example, the
realm and nonce values) internally, associated with the connection, until
the next stage of the bind operation is completed.

The challenge string MUST NOT be reused.
   
Upon receipt of the challenge, the client will generate the
"digest-response"  value, again as defined in
[draft-ietf-http-authentication-01]. The client  will send a bind request,
with a different message id, in which the version number is 3, the name
field is the name of the user's entry (if known), the authentication choice
is sasl, the sasl mechanism name is "Digest", and the credentials field
contains a "digest-response":
   
user-name="dn: cn=J Smith\, Esq.,dc=acme,dc=com",cnonce="9871231adf",
response="b913a602c7eda7a495b4e6e7334d3890"
    
The client then will wait for another response from the server.

If the server performs password authentication based on the userPassword
attribute, the server will then, for each value of the userPassword
attribute in the named user's entry, generate the response-digest value
itself, and compare the result with the client's presented
"digest-response".  A similar process can be used by servers which maintain
password through other means. Storing the "A1" value (as defined in
[draft-ietf-http-authentication-01]), which is a hash of the user's name,
realm, and password, instead of just the password, is encouraged because it
does not expose the user's password if they use the same password for more
than one server or realm.

If there is a match, then the server will respond with resultCode success,
otherwise the server will respond with resultCode invalidCredentials.  The
serverSaslCreds field will be absent.

The server will delete the challenge from memory when the SASL negotiation
completes, or if the client does not complete the SASL negotiation, as
challenge strings MUST never be used twice.  A client MUST NOT send more
than one bind request containing response digest values in which the same
challenge string was used.  If a client wishes to change authentication, it
MUST start from the beginning and request a new challenge.