RE: Authentication Methods for LDAP - last call

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

On Thu, 20 Aug 1998, Paul Leach wrote:
> 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.

I was well aware of that problem, but I suspect that cross-company ACLs
and such are not going to be common case for quite a while.

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

This might suggest that using DNs in an ACL is poor architecture and it
would be better to use some sort of globally unique identifier which is
less subject to change.

> This is one of the reasons that we don't use DNs as user's names.

Fair answer.

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

To demonstrate that tieing a password to a username is not a requirement
for an authentication verifier database that's safe from global dictionary
attacks. 

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

Kerberos has a different architecture from other mechanisms.  It presumes
there's a trusted-third party authentication server which is presumably in
a locked room with carefully managed remote access.  Proper management of
Kerberos means there isn't an authentication database on the more complex
application servers that are more likely to have a security hole.  Of
course, this is part of the reason Kerberos is so hard to deploy.

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

Compliant TLS implementations can't be exported from the U.S. (except to
financial institutions).  The Danvers IETF made a decision that the IETF
would never bless 40-bit key encryption as standards complaint -- that's
why DSS_DHE_3DES is the MTI in TLS.

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

But mandatory-to-implement means mandatory to implement.  If the code
isn't present in an implementation, that implementation is incompliant.

> Among other things, it's the only current standard way to get
> communications privacy for LDAP.

Incorrect.  TLS is not standards track yet.  The only currently standard
way to get communications privacy for LDAP is with the Kerberos_V4 and
GSSAPI SASL mechanisms.

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

Since there isn't a 100% satisfactory mandatory-to-implement mechanism,
the MTI should be the smallest and simplist mechanism permitted so it
places the least burden on implementors.

		- Chris