RE: Issues with current authmeth draft.

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

I find this a bit hard to deal with. We are authenticating to a directory, aren't we? I remember quite an extensive discussion once about how the user name in the simple bind alternative related to a user entry. At that time it was pointed out the X.500 requires it to be the 'distinguished' name of an entry. This actually precludes there being no entry and also precludes the name being an alias.

Has LDAP jettisoned the X.500 model?

So, I'm finding it difficult, Kurt, following the non-directory approach you are following in directory authentication.

In short, I oppose it.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, 12 May 2003 09:24
To: Mark Ennis
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Issues with current authmeth draft.


At 03:51 PM 5/11/2003, Mark Ennis wrote:
>Kurt D. Zeilenga wrote:
>>At 10:28 PM 5/6/2003, Mark Ennis wrote:
>>
>>>2) DIGEST-MD5 authentication identity
>>>
>>>There does not appear to be a clear statement as to the form of the authentication identity (as opposed to authorization identity) to be provided in the username-value of the SASL credentials for DIGEST-MD5 (or other mechanisms).
>>
>>RFC 2831 says its a user name.  That is, it's not a LDAPDN, not
>>an authzid, not a domain name, not a ....
>
>On the other hand, RFC2831 does not specify the authzid field in the SASL parameters should use the authzid syntax defined in RFC2829 either.

RFC 2222 says the form of the (proxy) authorization identity
is application protocol specific.

>It does, however, define the username SASL parameter as
>     "The user's name in the specified realm, encoded according to the
>      value of the "charset" directive. This directive is required and
>      MUST be present exactly once; otherwise, authentication fails."

I think this is an issue which already came up in the SASL WG.

>I suggest this supports the potential to use LDAPDN

I don't believe it supports any such thing.

>which is the closest thing to a username within LDAP that is required by the LDAP specifications.

I don't think the LDAP specifications require a DN for authentication
proposes.  If one considers EXTERNAL, the underlying authentication
identity can be anything.  Likewise, any SASL mechanism can be used.
Here the form of the authentication identity is mechanism specific.

Regardless of the mechanism, it is the server's responsibility to
derive an appropriate authorization identity from the authentication
identity associated with the credentials.  And if a (proxy) authorization
identity is asserted, make sure the identity associated with the
credentials is authorized to assume that asserted (proxy)
authorization identity and, as appropriate, derive an identity
representation suitable for application of access control and other
administrative policies.

>After all, the "user's name" in LDAP is the LDAPDN of the user's entry.

Not necessarily.  There may be no LDAPDN associated with the user
and, even if so, it may not refer to an entry.

>Furthermore, [authmeth] has the statement:
>  "Clients sending a bind request with the sasl choice selected SHOULD
>   NOT send a value in the name field. Servers receiving a bind request
>   with the sasl choice selected SHALL ignore any value in the name
>   field. "
>in *4.3 SASL Authentication* which appears to prohibits the use of the BindRequest name field to establish the authentication identity.
>Without this or the  SASL username providing a LDAPDN, how should the authentication credentials be determined?

A local matter.  That is, how identities of different forms (or
of the same form used in different contexts) relate to each other is
a local matter.  How and where credentials are stored is a local
matter.  Which identities may assume (proxy for) other identities is
also a local matter.  And the form of identity used in access control
systems is local matter.

It's certainly a matter which the client should not concern itself
with...

Kurt