[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Issues with current authmeth draft.
First, I doubt that Digest-MD5 with a LDAP DN (either as a authentication
id or as an authorization id) would often be using a DN provided directly
by a user. I would expect its use to be more likely in one of these
scenarios:
1) An application is configured with a bind DN to use. For this purpose, I
think it would be reasonable if some standard or directory vendor supplied
tool generated the proper normalized DN required for Digest-MD5. This
might be a wrapper around a Generate Digest-MD5 UserName extended request.
2) An application authenticates to LDAP by first doing a search for
(&(mail=xxxx)(objectclass=person)) and then issuing an LDAP bind request
with the returned DN and the user entered password. For this purpose, a
standard algorithm, the above extended operation, or an operational
attribute, could be used.
See additional comments marked <JAM>.
I'll have to refresh my memory on the stringprep part. If that turns out
to require defining a DN normalization algorithm, or defining supporting
extending operations, it might be more appropriate to address this type of
item in a separate RFC.
John McMeeking
"Kurt D.
Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS
<Kurt@OpenLDAP.or cc: "Ramsay, Ron" <Ron.Ramsay@ca.com>, ietf-ldapbis@OpenLDAP.org, "Mark
g> Ennis" <mark.ennis@adacel.com>
Subject: RE: Issues with current authmeth draft.
05/12/2003 09:52
AM
At 09:52 AM 5/12/2003, Kurt D. Zeilenga wrote:
>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.
There are few problems here.
First DIGEST-MD5 security considerations encourage server implementors
to store the A1 hash, not the clear text password. For DIGEST-MD5 to
work as intended, the client MUST provide the authentication identity
is the form which the server used in generating the A1 hash. There
is no canonical DN textual string representation.
Secondly, when DIGEST-MD5 is revised, the client and the server will
be required to "stringprep" the username according to an algorithm
specified in the DIGEST-MD5. There will be some LDAPDNs which will
not pass this stringprep and others which would be mangled. One would
have to define an algorithm for encoding LDAPDNs into DIGEST-MD5
usernames and then require servers decode these for subsequent
processing.
Third, this would make LDAP's use of DIGEST-MD5 inconsistent with
the general use of DIGEST-MD5, yielding it impossible for a
multi-protocol application to consistently use the mechanism.
<JAM>
Technical problems aside (not to trivialize them), I don't see where a
predefined "LDAP DN" realm introduces any such problems. This realm would
only be used by application that are designed to authenticate using a LDAP
DN, but want the additional password protection. The multi-protocol
application can use the appropriate realms.
</JAM>
>One way to do that might be to define a standard realm name
>that LDAP servers support, for example "RFC2253 LDAP DN".
This would defeat the purpose of realms in DIGEST-MD5.
<JAM>
I see this exectly the opposite way. The purpose realm is to allow the
application to chose which relam it uses and provide a hint to the user
what username would be appropriate. I do not intend that an LDAP server
would support only this "LDAP DN" realm.
</JAM>
>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,
That I would agree with. The purpose of SASL authorization identity
strings are to support identity assumption (proxy authorization).
>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.
I think we put too much in "LDAP DNs are natural" line. They aren't.
Users shouldn't have to know their DN.
<JAM>
I agree that users shouldn't know what their DN is, and for the
applications I deal with that use simple binds, the user doesn't know their
DN. However, it is natural for applications to use DNs.
</JAM>
Kurt