RE: LDAPDN and AuthMeth/DIGEST-MD5

["Paul Leach (Exchange)" <paulle@Exchange.Microsoft.com>]

> -----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 believe the AuthMeth draft should specify a canonical
> DN form for use with the DIGEST-MD5 and similar mechanisms.
> In fact, it may be appropriate to require use of this form
> within AuthzIDs (though I suggest we remove AuthzIDs
> altogether, but that another thread).
> 
> The AuthMeth draft should also clarify as whether or not the
> DIGEST-MD5 username (and/or authzid) string provided by
> client is string encoding of a DN, a string encoding of an
> AuthMeth authzId, or a string encoding of a AuthMeth uAuthzId
> userid value.  
> 
> I should also note that AuthMeth draft defined keywords
> are easily confused with DIGEST-MD5 keywords (authzid
> vs authzId).  I suggest that AuthMeth rename its authzId
> keyword.
> 
> In addition, The AuthMeth document does not describe if or
> how applications may advance features of DIGEST-MD5, such
> as integrity protection and confidentiality protection.
> The draft should explicitly note that these features are not
> covered under this specification.

It is not necessary for an application protocol to specify how to use them;
the Digest spec says how they are to be requested and used.

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

Paul