RE: Issues with current authmeth draft.

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

Two concepts discussed in this document are authentication identity and authorisation identity. I take it that access control decisions are made on the basis of the authorisation identity. Therefore, I believe this should be a DN. I think RFC 2829 requires that it is a DN if it is provided. Digest-MD5 seems, through the notion of realm, to assume that authentication will take place in another domain.

Of TLS, RFC 2829 requires that the certificate subject be taken as the identity of the user.

It is not clear to me whether the directory actually requires an authentication identity, but it probably requires an authorisation identity. Under this interpretation, SASL may provide an authentication identity and this may or may not be understood by the directory. In the case of simple bind, the directory must understand it as it is responsible for authentication. In the case of Digest-MD5 there would be no need to understand it as authentication is handled 'outside' the directory. In the case of EXTERNAL, no identity is provided.

For simple bind, the authorisation identity would be the same as the authentication identity. For EXTERNAL, the authorisation identity should be the certificate subject. It would seem, for Digest-MD5, that the authorisation identity, a DN, should be provided unless the server can derive it by some out-of-band method.

If you agree with this, then the logical course of action would be to require, for Digest-MD5, that the autorisation identity be a LDAP DN as per RFC 2253 and that it be provided unless the client has out-of-band knowledge that the server will derive it.

>From the point of view of a server that performs Digest-MD5 authentication internally, it could use such an authorization identity to locate data necessary to perform the computation. But in this case, the authentication identity has no function!

So, how can an authentication identity be useful if it is not a DN? Unless it, to, is optional. What is our model?

Ron

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


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? 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.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). I question the value in defining the usage of 
one and not the other by the LDAP specification.

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

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

However, I do not accept that SASL prevents my use of an LDAPDN as an 
identifier in authentication credentials. 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. 
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 
> 
> 
>