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

RE: LDAPDN and AuthMeth/DIGEST-MD5

I put forth that AuthMeth should be returned to the
WG until such time that it details a mechanism to
securely (no clear text password exchange) authenticate
clients desiring to use traditional LDAP DN based
authorization identities over a insecure transport
protocol (ie: TCP).

I recommend that the new bind method (non-SASL) be
drafted which adapts the algorithm suggested DIGEST-MD5
to support LDAP DN authorization identities.

At 05:31 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.Org]
>> Sent: Thursday, November 18, 1999 3:45 PM
>> 
>> The AuthMeth draft does not specify a canonical DN form
>> for use with the DIGEST-MD5 algorithm.   Without such, the
>> server must dynamically determine response-value based upon
>> user provided DN and cleartext password stored for with this
>> DN.
>
>That's because there isn't one. It won't work with one.

>The form of user
>name in Digest is determined by a system's implementation of Digest, not by
>the application protocols that use it.
>The Digest user/password data base is
>intended to be cross-application and system wide, even organization wide, so
>that users don't have to remember different passwords for every service or
>server. If ACAP, IMAP, POP3 and other protocols that use SASL mechanisms
>such as Digest and use the same implementation on a system all tried to
>mandate their own special forms for user names, like you're trying to have
>LDAP do, there would be conflict and chaos.

I am attempting to make two independent points:

	1) AuthMeth, as defined, does not provide a secure
	bind method/mechanism for use with traditional DN based
	authorization identities.  It should.

	2) SASL does not care how the authorization identity is
	encapsulated within application protocol.  Encapulating
	the authorization identity ("kdz") in an AuthzId/uAuthzId
	("u: kdz") offers no benefit over encapsulating it in a
	DN ("uAuthzId=kdz").  However, the AuthMeth introduces a
	second on-the-wire representation and this will have a
	significant impact upon the LDAP information model.
	It should not.

>I'll repeat -- the AuthMeth draft improperly (IMO) mandates layering
>violations.

I concur.  I believe we should resolve these layering issues
as well.