RE: LDAPDN and AuthMeth/DIGEST-MD5

["Paul Leach (Exchange)" <paulle@Exchange.Microsoft.com>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
> Sent: Friday, November 19, 1999 6:17 PM
> To: Mark Wahl
> Cc: ietf-ldapext@netscape.com
> Subject: Re: LDAPDN and AuthMeth/DIGEST-MD5
> 
> 
> > let me see if I can summarize each person's position
> 
> My position is that users should be able to authenticate securely
> regardless of whether they provide a DN or non-DN authorization
> identity to the client.

First, authorization identities have nothing to do with authentication and
hence nothing to do with whether a user can authenticate securely.

Second, when using SASL, whether or not a particular form of authzid is
supported is up to the implementation of SASL mechanism, not LDAP. I believe
that section 11 of the AuthMeth draft is ambiguous -- but my interpretation
is that it defines how authzid works for non-SASL mechanisms (builtin LDAP
methods and EXTERNAL).

Finally, support for authzid is not required to be SASL compliant or
Digest-MD5 compliant.

> 
> I believe non-DN authorization identities should be encapulated
> within an LDAPDN so as to avoid introduction of a second on-the-wire
> representation of authorization identities.

For non-SASL mechanisms, I have no objection to this. I agree that u: or dn:
is just a different syntax, and your proposed syntax works just fine.

> 
> I believe that the server, upon successful authentication, SHOULD
> determine DN representing the user which is usable as the
> creatorsname, modifiersname, ACL subjectDN, etc..  This DN may
> or may not be the same DN provided by the client.

I think this conflicts with 2251, which says that those attributes are
optional.
If an implementation supports them, then it must map the user identity to a
DN, because they are DN valued attributes.
If an implementation does not support them, then the SHOULD is irrelevant.

Paul