Subject: RE: Issues with current authmeth draft.

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 12 May 2003 18:08:29 +1000

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:[email-masked]]
Sent: Monday, 12 May 2003 17:25
To: Kurt D. Zeilenga
Cc: [email-masked]
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 
> 
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 16:26:10 -0700

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 ca…

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

---

From: Mark Ennis <[email-masked]>
Date: Tue, 13 May 2003 10:08:25 +1000

> mechanism intended for DN/password authentication (such as

 From an interoperability perspective this has problems as a server is 
only required to implement DIGEST-MD5 and simple authentication, not 
TLS. This theoretical client would then only be able to interwork with 
servers which implement TLS or would be forced to use a less secure 
authentication mechanism (simple bind without TLS). This seems counter 
to the reasons in RFC2829 and [authmeth] for introducing SASL 
mechanisms, in particular, SASL DIGEST-MD5.

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 12 May 2003 18:14:39 -0700

At 05:08 PM 5/12/2003, Mark Ennis wrote:
>This seems counter to the reasons in RFC2829 and [authmeth] for introducing SASL mechanisms, in particular, SASL DIGEST-MD5. 

Well then we should clarify the rationale.

Kurt