RE: Issues with current authmeth draft.

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

I don't see how you can say that these authentication methods are not expected to use DNs. RFC 2829 states:

"All servers which support the storage of authentication credentials, such as passwords or certificates, in the directory MUST support the dnAuthzId choice."

The word is MUST!

I don't know what you make of

"The user's certificate subject field SHOULD be the name of the user's directory entry...."

but it suggests to me that the subject DN is the authetication name.

But without dwelling on the technicalities I think we have a simple problem here. If Digest-MD5 is a non-directory authentication method it must be removed from authmeth (to its own RFC). Authmeth should only deal with LDAP-based authentication methods.

The problem with Digest-MD5 is that either the password or a hash of the password has to be stored somewhere. A "directory" implementation would store this in a "user" entry and use an authentication identity which is the name of this entry. I see that you propose that the auth ID shoudl be a simple string, and that the directory should resolve this to a DN, if it needs to, but this is using the directory as a directory application! and is clearly not appropriate for a mandatory-to-implement procedure as the actual mechanism is not specified.

Ron


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 13 May 2003 09:26
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Issues with current authmeth draft.


At 01:08 AM 5/12/2003, Ramsay, Ron wrote:
>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.

The form of the authorization identity used in access control
decisions may not be the same as the form asserted by the
client wishing to assume some identity.  Note that when a
client does asserts an authorization identity, is requesting
to assume an identity other than that associated with its
credentials.  When an client wishes to act under its own
identity is should not assert a proxy authorization identity.

>Therefore, I believe this should be a DN. I think RFC 2829 requires that it is a DN if it is provided.

Sorry, no.

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

Sorry, no.  RFC 2829, 5.1.2.1:
   The server will derive the client's authorization identity from
   the authentication identity supplied in the client's TLS
   credentials (typically a public key certificate) according
   to local policy.   The underlying mechanics of  
   how this is accomplished are implementation specific.

>It is not clear to me whether the directory actually requires an authentication identity, but it probably requires an authorisation identity. 

Yes, one can take the view that SASL authentication results in the
establishment of an authorization identity suitable for use in
subsequent access control decisions.

>Under this interpretation, SASL may provide an authentication identity and this may or may not be understood by the directory.

If you have clear separation between SASL and directory processing,
authentication details can be hidden from the directory.  The SASL
subsystem can be produce an authorization identity which the access
control subsystem can (directly or indirectly) use.

>In the case of simple bind, the directory must understand it as it is responsible for authentication. 

Well, I think it can be argued that the bind name need not refer
to an entry normally visible as part of the directory.  For example,
a server is quite free to map the bind name to some identity in an
external and then ask that external system to verify the credentials.

>In the case of Digest-MD5 there would be no need to understand it as authentication is handled 'outside' the directory.

Well, then again, a server is free to map the username to a DN
and access information at that DN in order to complete authentication.

>In the case of EXTERNAL, no identity is provided.

>For simple bind, the authorisation identity would be the same as the authentication identity.

Yes, but the server is free to represent the authorization identity
in another form if so chooses.  Maybe it prefers authzids.  Maybe
it prefers short user names.

>For EXTERNAL, the authorisation identity should be the certificate subject.

Not necessarily.  The server could, for instance, use an alternative
subject name.  Or the certificate serial number.

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

Maybe the server uses usernames directly in its access control system.
No DN form needed.  But if the server needed a DN, it certainly can
map the username to a DN using whatever algorithm suits it.

>If you agree with this,

I think not.

>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

No.  The authzid is for proxy authorization, not for indicating which
identity should be derived from the authentication identity.

>and that it be provided unless the client has out-of-band knowledge that the server will derive it.

The client should assume the server is capable of deriving a
suitable authorization identity in the appropriate form from the
authentication identity associated with its credentials.  Requiring
the normal clients (those not doing proxy authorization) to know more
than its credentials is unnecessary and counter to intent of
username/password mechanisms.

If the client knows instead a DN and password, then it should a
mechanism intended for DN/password authentication (such as
Simple bind over TLS).

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

Sorry, but I think that has a significant impact upon the security
of the mechanism.

>So, how can an authentication identity be useful if it is not a DN?

There is actually no requirement to implement authentication
and authorization based upon DNs.  A server could just implement
the DIGEST-MD5, not support proxy authorization at all, and use
simple user names in making access control decisions.

Kurt