[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SASL Semantics Within LDAP

Hallvard B Furuseth wrote:

After preparing these values as specified in [DIGEST-MD5], the
server may choose to use LDAP semantics to locate an entry with the
user's authentication information. For example, it may expect the
username to have the form of a DN and look up the named entry, or it may
search for (cn=<username>) below cn=<realm>,cn=auth,dc=example,dc=com.
However, when the entry is located, authentication will fail if the
realm and username values do not match according to DIGEST-MD5's
semantics.



Maybe s/authentication will fail/authentication may fail/.


I completely agree. Otherwise the last sentence might be read as being prescriptive.

Isode implementation might be configured to search for (<attr>=<username>) below a realm entry, but we certainly never check that the found entry contain <attr> value exactly as specified in the SASL Bind request.

As I wrote in that old message (a bit less clearly:-), I wonder if both
the quoted text and the original authmeth DIGEST-MD5 text is too strict,
though I didn't know what to do about it at the time:

Formally, I imagine the server could regard <cn=Bob,...> and
<cn=bob,...> as different DIGEST-MD5 usernames which have the same
password:  Since the username => password mapping in the example is
implemented in LDAP, the mapping has LDAP semantics.

For DIGEST-MD5, that would only work if the server stores the password
as plaintext so it can hash it with the username provided by the client.
It won't work if what the server stores is a hash of (password, DN,
realm).

I don't know the intent of either SASL or LDAP specs in this regard
though.