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

Re: Issues with current authmeth draft.

Kurt,

All the introductory text in RFC2829 and [authmeth] indicate that the reason for introducing and, in [authmeth] case, requiring DIGEST-MD5 is for security considerations relating to protecting passwords from eavesdropping. The only mention of non-LDAPDN authentication identities in the early parts of these documents are in reference to using these non-LDAPDN identities as authorization identities for backward compatibility with non-LDAP authentication mechanisms. You are suggesting DIGEST-MD5 and other SASL mechanisms were introduced for other than reasons related to security considerations and yet all the text in the documents introducing these mechanisms into LDAP indicate the reasons are security related and for backwards-compatibility only.

- Mark.

Kurt D. Zeilenga wrote: 
At 08:31 AM 5/12/2003, John McMeeking wrote:

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.



YES!  DIGEST-MD5 is intended to be used where the user's credential
is a short user name and a password.


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.



Then the application should use a mechanism intended for use
with DNs, like simple bind over TLS.


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.



Requires the directory to be searchable and, to some degree, readable
by anonymous users.  Very bad.


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.



Or just to say that simple bind with TLS, not DIGEST-MD5, is
applicable to applications attempting to authenticate with
credentials consisting of an LDAP DN and password.