RE: AuthMeth issue summary

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

At 11:57 AM 12/10/99 -0800, Paul Leach (Exchange) wrote: 
>> From: Kurt D. Zeilenga [<mailto:Kurt@OpenLDAP.Org>mailto:Kurt@OpenLDAP.Org] 
>> AuthMeth draft provides a secure Bind mechanism (DIGEST-MD5) 
>> for authentication users who provide a simple username/password. 
>> Though the mechanism describes how to provide an LDAP DN 
>> authorization identity, it doesn't not allow an LDAP DN 
>> authentication identity (DIGEST-MD5 username) [and it shouldn't]. 

> Yes, it does allow an LDAP DN as an authentication ID.

Not without an canonical string representation of an LDAP DN.

DIGEST-MD5 uses arbitrary utf-8 string as the authentication ID.
A utf-8 that differs from another is considered a different
authentication identity.  That is:  "cn=foo" and "CN=FOO" are
two differnet authentication identities in terms of SASL/DIGEST-MD5.

However, "cn=foo" and "CN=FOO" (and "2.5.4.3=#666f4f"), as LDAPDN,
are all refer to the same authentication identity.

Though a SASL/DIGEST-MD5 service could be implemented where the
eight upper case vs lower case varients of "foo" are treated as
the same identity, such approaches, this cannot be done for
LDAP DN in general.  There are countless LDAPDN strings
representing a particular DN (especially when you consider
optional extra spaces, RDN ordering, quoting options, etc.).

>It in fact places no constraints on the form of authentication IDs
>at all (other than that they be strings, ASCII or UTF-8, and
>that the user supply exactly the same value (including case, etc)
>as the server stored when the users account was created).

EXACTLY!  A user cannot be told they can enter an LDAP DN, they
must be told to enter a canonical utf-8 string which represents
their LDAP DN.

> Obviously, the security subsystem on the server would have to use DNs as usernames in order for users to supply DNs as user names.

The SASL/DIGEST subsystem would use a canonical string representation
of a DN as the username.   This is quite different than using the DN.

>> However, I do believe that we need to provide a secure Bind 
>> mechanism for authentication users who provide an LDAP DN as 
>> their authentication identity. 
>
>I believe all the necessary protocol elements are in place
>so that systems can be built that use LDAP DNs as their
>authentication IDs. And for ones that don't.

Given a canonical string representation for LDAP DNs, such that a
client can map the DN provided by the user into the exact string
representation expected by the server, I agree.  However, we do
not have specification for a canonical string representation for
LDAP DNs.