RE: Authentication Methods for LDAP - last call

[Chris Newman <Chris.Newman@INNOSOFT.COM>]

I propose a lunch meeting on Tuesday -- meet 11:30 by the IETF
registration desk.  We'll see if there isn't a way to create a unified
front on the authentication issue from the apps area.  Without a unified
apps area, there is no chance of getting any new security proposal on the
standards track.  I suspect this will also be discussed at the apparea
meeting.

On Wed, 19 Aug 1998, Paul Leach wrote:
> As will all the ACLs on which the user's DN is present.

ACLs can be fixed by a brute-force query-replace on the directory.
Password verifiers can't.

> Compared to that, the fact that changing departments means they have to
> change their password (to the same thing as before) is pretty minor.

Do you know how frequently people change departments?  Do you really want
to force a company which does a merge and changes the cooporate name to
line up _all_ the users to get new passwords assigned?

> While Chris presents this as a problem, it is a side effect of the ability
> to safely use the same password on multiple servers, and of not having the
> same password have the same verifier for different users.

Yet SCRAM manages to have better password security than HTTP digest
without this negative impact.  Even /etc/passwd has the property you
describe without the drawback.

> Also, as soon as the attacker overhears one SCRAM challenge/response they
> can impersonate the client if they have stolen the client's verifier.

True, but look at the current practice with /etc/passwd verifiers. 
Stealing an /etc/passwd entry doesn't automatically gain the ability to
impersonate the user.  But eavesdropping on an authentication gets the
password.

HTTP digest and CRAM-MD5 remove the eavesdropping problem, but at the
expense of making the server database plaintext-equivalent -- thus less
secure than /etc/passwd current practice.  SCRAM is not less secure than
/etc/passwd current practice, so there is no downside to upgrading to
SCRAM from /etc/passwd.

> I am also willing to so cooperate if the powers-that-be can cause this to
> happen for LDAP, IMAP, ACAP, and HTTP.

It may be too late to do anything with IMAP -- there's going to be a big
fight over that one.  There will be a lot of CRAM-MD5 deployed, some TLS
and rare deployments of either Kerberos_V4 or GSSAPI+KerberosV5.  And
nobody wants to reset it at Proposed status yet again, nor retroactively
declare compliant implementations incompliant.

ACAP has to have something simple since thin clients was a major design
goal.  TLS and Kerberos have no chance.  If a suitable SASL mechanism is
standards track, I'd be willing to lobby for a recycle at proposed status
with a new mandatory-minimum mechanism.

> However, if we all agree we're going to dump CRAM-MD5,

I intend to use CRAM-MD5 heavily until there's something better on the
standards track.  I plan to be reading/sending email at the IETF using
CRAM-MD5.  It's so much better than unencrypted clear text that I plan to
heavily promote its use until there's something even better that's easy to
use & deploy.

Anyone want free CRAM-MD5 source code? 

> then why can't LDAP go forward with TLS

So you don't mind if the LDAP implementations you ship overseas are
non-compliant with the standard?  You don't mind doubling or tripling the
size of a minimal LDAP client? 

> or Kerberos as the mandatory-to-implement?

Kerberos has to be disabled by default since one can't assume there's a
Kerberos server at every site.  So what's enabled by default?
Unencrypted clear text?

		- Chris