> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.Org]
> Sent: Sunday, November 21, 1999 6:40 PM
> To: Paul Leach (Exchange)
> Cc: ietf-ldapext@netscape.com
> Subject: RE: LDAPDN and AuthMeth/DIGEST-MD5
>
>
> My terminology was off and I confused A1 with the stored
> hash. I'll try to clarify my comments.
>
> At 05:53 PM 11/21/99 -0800, you wrote:
> > No. It can store
> > H( { username-value, ":", realm-value, ":", passwd }
> > which is what was intended to be precomputed, not A1.
>
> If the user provided identity (username-value) is an
> LDAP DN, this cannot be precomputed unless both client
> and server agree on a canonical string encoding for
> DNs. Without such an agreement, the password would
> have to be stored in clear text.
Now you're on solid ground. Yes, both client and server have to agree on the format of username-value.
It's not quite true that there has to be a cononical form. For example, as long as the user uses the same form consistently, including when giving their username to the server when setting/changing their password, then no canonical form is needed.
>
> From previous discussions, you noted that use of LDAPDN
> format user identities was inappropriate for SASL based
> authentication.
That's not quite what I said. One could certainly implement a Digest-SASL mechanism that has LDAPDNs as the username. What I said was that it is inappropriate for the LDAP protocol spec to mandate that such an implementation be used, since SASL mechanisms are application protocol independent. (It is equally inappropriate for POP3, IMAP4, ACAP, to mandate that user names in the authentication mechanisms they use be e-mail addresses.) In a system where the user name was an LDAPDN for all purposes -- mail, web access, file access, directory access, etc. -- then use of an LDAPDN as the user name is fine.
This may be true. However, it does
> leave AuthMeth without providing a secure mechanism for
> authenticating users who provide LDAPDN identities.
Not true. If the username for the system is an LDAPDN, then one can do it. Otherwise, not.
What you are trying to do is force all systems that run an LDAP server to have the form of their username be an LDAPDN. I don't think _that_ is appropriate.
Paul