RE: Issues with current authmeth draft.

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I don't believe you can mandate simple/TLS! At the time RFC 2829 was debated, a large number on the WG wanted this. They did not get their way because of the complexity of the solution. It was argued that a password-based method would be better. I think they believed it would still be DN/password, though. 

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 13 May 2003 10:01
To: Mark Ennis
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Issues with current authmeth draft.


At 04:24 PM 5/12/2003, Mark Ennis wrote:
>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.

Since RFC 2829 is a largely a SASL profile, I wouldn't expect it
to discuss LDAPDNs except in contexts where SASL allows application
profiles to use application specific forms of identities.

However, RFC 2829 is fairly clear when it states (very early):
   An authentication identity is the name presented in a credential.

   There are many forms of authentication credentials -- the form used
   depends upon the particular authentication mechanism negotiated by
   the parties.  For example: X.509 certificates, Kerberos tickets,     
   simple identity and password pairs.  Note that an authentication     
   mechanism may constrain the form of authentication identities used   
   with it.

In DIGEST-MD5 clearly constrains the form of the authentication
identity to a simple identity string, a user name.

>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.

I am suggesting that RFC 2829 recommends implementation of
simple bind over TLS to support DN/password credentials.
But it requires implementation of DIGEST-MD5 to support
username/password credentials.

However, regardless of this, it should be clear that stuffing
LDAPDNs into usernames is not a path to interoperability nor
security.  Matching issues alone should be enough to kill that
idea.  We cannot morph DIGEST-MD5 into something its not, that
breaks mechanism commonality between application protocols.
We needed to use each mechanism in a manner consistent with
its specification.

Going forward, it would be much better to clarify that simple
+TLS is to be used for DN/password credentials and DIGEST-MD5
(or PLAIN+TLS) be used for username/password credentials.

I note that due to the specification and interoperability problems
with DIGEST-MD5 (not just with LDAP), I would not be opposed to
changing the mandatory-to-implement authentication mechanism
from DIGEST-MD5 to simple+TLS.

Kurt

PS: I was once suggested in an I-D how one could stuff DNs
into DIGEST-MD5 credentials, it got no where.  See LDAPEXT
archives.