[Date Prev][Date Next] [Chronological] [Thread] [Top]

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