[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Issues with current authmeth draft.
With respect to DIGEST-MD5:
1) If only the authentication mechanism is used (not data integrity or
confidentiality), it provides a bind mechanism that protects the password
without the need to establish a secure connection. Also, LDAP DNs are a
natural choice for a user name when authenticating to a LDAP directory.
>From that perspective, I would like DIGEST-MD5 to allow the user name to be
a bind DN. One way to do that might be to define a standard realm name
that LDAP servers support, for example "RFC2253 LDAP DN". This would
provide a standard way for clients to take advantage of DIGEST-MD5 for
password protection not offered by simple bind. The mapping from
authentication id to authorization id is trivial.
2) In the general case of using password based authentication to LDAP, with
a "user registry" that may, or may not, be the directory, the user name can
be most anything and the authentication id can be thought of as "<username>
in <authentication realm>". For servers that have an access control
mechanism, the server must have some means of mapping the authentication id
to an authorization id. And that is left to the server. I'm fine with
that.
If we look at authentication id with other mechanisms:
GSSAPI: The authentication id is based on a Kerberos principal name
(jsmith@mycompany.com). Using the general form I described above:
"<kerberos-principal> in <all Kerberos realms>".
EXTERNAL: Some folks tend to think of the authentication id as the
certificate subject DN, which is something LDAP folks are comfortable with.
But as I understand it, the subject DN really should be used in association
with the issuer DN. So the authentication id is more properly something
like "<subject-dn> in <certificates issued by issuer-DN>", which isn't a DN
at all.
simple bind: could be expressed as "<bind-dn> in <RFC2253 LDAP DN>"
Looked at this way, I'd say RFC2829 over-emphasizes authorization id, and
neglects the use that of LDAP DN as a natural choice for user names when
authenticating to a LDAP directory. I suspect it would be rare for a
client to know what authorization id to specify, and it is likely that a
server would require the user name to be the same id the server would
generate internally.
To summarize: I'd like authmeth to define a realm name for use with
Digest-MD5 that corresponds to LDAP DNs known to this server. Authzid is
okay, but perhaps could be better put into context.
John McMeeking
"Ramsay, Ron"
<Ron.Ramsay@ca.com> To: "Mark Ennis" <mark.ennis@adacel.com>, "Kurt D. Zeilenga"
Sent by: <Kurt@OpenLDAP.org>
owner-ietf-ldapbis@O cc: <ietf-ldapbis@OpenLDAP.org>
penLDAP.org Subject: RE: Issues with current authmeth draft.
05/12/2003 03:08 AM
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
>
>
>