RE: Authentication Methods for LDAP - last call

[Paul Leach <paulle@microsoft.com>]

> -----Original Message-----
> From: Chris Newman [mailto:Chris.Newman@innosoft.com]
> Sent: Thursday, August 20, 1998 10:28 AM
> 
> 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.

You've missed a slight problem of scale in the real world.
The user's DN is on ACLs could be on 100s of directory servers in just one
organization, and could be on ACLs in 1000s of organizations' directories
world-wide. And in integrated environments, they could be on the ACLs on
files on possibly 10,000 file servers, just in one organization. Result: a
brute-force query-replace is not feasible.

It's like saying that brute force can defeat any encryption algorithm (given
enough time) -- true but not relevant.

And how do you change a user's DN in scripts that munge ACLs?

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

Yes. We have real data from real companies that we've used in the design of
the NT DS.

  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?

This is one of the reasons that we don't use DNs as user's names. The other
reason is because DNs weren't really meant to be typed, and user's are
resistent to typing them. We use rfc-822 names as the users' security
principal name, because Internet mail has trained them to understand and
type them. These names are usually identical to their email address, which
does not change very often (because it is in the heads of people, on paper,
and in unstructured text, which can't be changed by a brute force query.)
The advantage of that is that users' login names _do not_ change when they
change departments.

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

A "negative impact" shared with Kereberos, whose verifier is also only
useful as long as the user name stays the same.

  Even /etc/passwd has the property you
> describe without the drawback.

But /etc/password is not an authentication protocol. Why are you bringing up
a total red herring?

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

In theory, it is less secure only with respect to exactly one thing -- theft
of the verifier database, and even then assuming that the verifier database
isn't locally encrypted. I.e., not in reality.

Kerberos verifiers are also plaintext equivalent. Are you saying that
Kereberos is less secure than /etc/password?

I have to say that you're totally blowing smoke on this one.

 [snip]

> 
> Anyone want free CRAM-MD5 source code? 

Anyone want free Digest source?

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

TLS can be exported. We do. Even at exportable encryption strength,
authentication is strong.

  You don't mind doubling or 
> tripling the
> size of a minimal LDAP client?

Mandatory-to-implement (MTI) is not mandatory-to-use . There exist public
domain or GNU implementations of TLS. And TLS will be implemented even if it
isn't MTI. Among other things, it's the only current standard way to get
communications privacy for LDAP.
 
> 
> > 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?

MTI is not mandatory-to-use.

The LDAP authentication spec allows _any_ SASL mechanism to be used.
CRAM-MD5 is a SASL mechanism. Hence, it can be used. The issue is only which
one(s) are mandatory-to-implement.

Paul