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

RE: LDAPDN and AuthMeth/DIGEST-MD5



At 09:09 PM 11/21/99 -0800, Paul Leach (Exchange) wrote: 
> 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.

No.  I am trying to ensure we provide secure authentication
and authorization services for identities of both DN and
non-DN forms.

Please note that my suggestion not to introduce a second on-the-wire
format for authorization identities IS NOT a call to eliminate user
(or application) specified non-DN identities.  It's a call to not
unnecessarily complicate the protocol and information model.

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

It would be quite problematic to rely on users consistently entering
their DN... and different clients could rewrite them differently...
and admins could generate them using external tools.  A simple
specification of a canonical string representation of a DN would
eliminate these problems.

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

Great.  All we then need is to include in AuthMeth a specification
for generating canonical LDAPDN string encoding of the user
specified DN.  This scheme should be mandatory for all clients
and servers supporting LDAPDN based authentication and
authorization.