RE: Authentication Methods for LDAP - last call

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: Chris Newman [mailto:Chris.Newman@INNOSOFT.COM]
> Sent: Tuesday, August 18, 1998 2:31 PM
> To: IETF LDAP Extensions WG
> Subject: RE: Authentication Methods for LDAP - last call
> 
> 
> For the record, I will be unable to attend LDAPEXT WG because I am
> chairing the DRUMS working group which meets at the same 
> time.  I would
> like to register my opposition to changing the authmeth draft 
> to use HTTP
> digest for the following reasons: 
> 
> (1) HTTP digest uses a construct which prevents users from 
> being renamed. 
> While this may be a minor concern in some protocols, in LDAP it is a
> significant concern with DNs because moving a user from one 
> department to
> another could cause that user's password to stop working.

As will all the ACLs on which the user's DN is present.
Compared to that, the fact that changing departments means they have to
change their password (to the same thing as before) is pretty minor.

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.

> 
> (7) RFC 2069 has a major security flaw in the definition of a 
> "realm."  It
> allows me to set up a web server which advertises itself as 
> "AOL.COM" and
> the majority of clients will blindly send the AOL.COM 
> user/password pair
> if the user had already enterred it.

This isn't a problem if the challenge/response protocol is secure.

> HTTP digest and
> CRAM-MD5 both use plaintext equivalent verifiers, meaning if 
> an attacker
> breaks into the server they can automatically impersonate all users to
> other servers in the same "realm."

As does Kerberos, e.g. 

Also, as soon as the attacker overhears one SCRAM challenge/response they
can impersonate the client if they have stolen the client's verifier. So,
SCRAM verifiers aren't really much better than plaintext equivalent in
practice: for all of this type of protocol (Kerberos, Digest, CRAM-MD5,
SCRAM) you MUST protect the verifiers.

> 
> If LDAPEXT goes with CRAM-MD5 now, I would be glad to cooperate on a
> mechanism which combines the best features of HTTP digest and 
> SCRAM.  Once
> the result is standards track, then it would be reasonable to 
> reconsider
> the mandatory-to-implement mechanism.

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

However, if we all agree we're going to dump CRAM-MD5, then why can't LDAP
go forward with TLS or Kerberos as the mandatory-to-implement?

Paul