Re: Issues with current authmeth draft.

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

At 12:25 AM 5/12/2003, Mark Ennis wrote:
>Kurt D. Zeilenga wrote:
>>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.
>So?

Because RFC 2222 makes it fairly clear that the form of the
authentication identity is mechanism specific while the form
of the authorization identity is specific to the application-level
protocol profiling its use of SASL.

>I am not questioning the appropriateness of [authmeth] defining the authzid syntax for the authorization identity defined in RFC2831. I was intending to point out that RFC2222 and RFC2831 are not LDAP specifications.  Their use and the appropriate content of their fields with respect to LDAP are defined by an LDAP specification,

I think we need to be careful here.  The LDAP SASL profile defines
a few application protocol specific particulars, in accordance with
SASL profiling requirements.  Beyond this, it is generally inappropriate
for any other application protocol TS, to overload fields of specific
mechanisms.  That would defeats many of the values the SASL framework
brings to the Internet.

>i.e. [authmeth], which sees fit to define the content of the authzid field (and therefore the form the authorization identity will take), but not the username field (and therefore the form the authentication credentials will take).

RFC 2222 says the authorization identity form is application protocol
specific.  RFC 2222 implies the form of the authentication identity
is mechanism specific.

>I question the value in defining the usage of one and not the other by the LDAP specification.

Noted.


>>>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.
>
>So, if I have an authentication engine which uses distinguished names as the unique identifier in the realm and passwords for the shared secret, I can't use this authentication engine with the SASL "DIGEST-MD5" mechanism because I can't use the LDAPDN in the username-value in this mechanism?

A username value doesn't have LDAPDN syntax or semantics in the
protocol.

>I must introduce a new arbitrary identifier and a mapping of this identifier to a distinguished name in order to bind? This does not seem reasonable.

Or introduce identity mapping.
Or use a more appropriate mechanism.



>>>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.
>I conceed I used a poor argument here. I agree that there is not a requirement for an entry identified by the LDAPDN used in authentication to exist. I also agree that SASL allows for authentication using credentials which do not include an LDAPDN, and that the server is responsible for defining a mapping if it requires it.

Okay, DIGEST-MD5 is clearly one of those mechanisms.

>However, I do not accept that SASL prevents my use of an LDAPDN as an identifier in authentication credentials.

Well, a username might look like an LDAPDN... but clearly the username
does not have LDAPDN semantics.

>One of the possible forms of an identifier in the authentication credentials for an "EXTERNAL" SASL authentication is the subject name of a certificate, i.e. a distinguished name. Where my authentication engine is an LDAP or X.500 system, I do accept that I should need to introduce a new identifier, if the directory does contain entries associated with LDAPDNs where the entries hold user passwords (or their hashes), if I wish to use SASL "DIGEST-MD5" authentication. [This would seem to be the point Ron Ramsey was making.]
>
>I feel that [authmeth] should make some statement as to the usage of the username field in the SASL "DIGEST-MD5" credentials when used for digest authentication in LDAP, even if this is to clarify that the content of the username-value is an arbitrary octet string assigned by the server.

I note that RFC 2222 and 2831 are being revised and they will include
some clarification in this area.  I would likely support (I'd have to
see the exact wording to be sure, please suggest something) an
[authmeth] clarification that reiterate these general statements
with a "for instance" for the DIGEST-MD5 username instance.

>Clients which make assumptions about the content of this field based on prior experience may have problems interworking with other servers. As I mentioned previously, I have already encountered LDAP clients which appear to make assumptions about the content of this field.
>
>>
>>>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.
>
>Accepted.
>
>>It's certainly a matter which the client should not concern itself
>>with...
>>Kurt