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.
>  
>