Re: SASL Semantics Within LDAP

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Roger Harrison writes:
> Shortly after sending a proposed new section 5.2.2 for authmeth-17, I
> rediscovered your email on the same subject from last March. I've
> reworked section 5.2.2, as below. I'd appreciate comments and feedback
> prior to my submitting authmeth-17 on Friday.

> 5.2.2. SASL Semantics Within LDAP
>
> Implementers must take care to ensure that they maintain the semantics
> of SASL specifications when handling data that has different semantics
> in the LDAP protocol.

That can be shortened even more since my original clumsy wording:

s/take care to ensure that they maintain/take care to maintain/.

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

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.

-- 
Hallvard