RE: Authentication Methods for LDAP - last call

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Some comments - usual style

> -----Original Message-----
> From:	Chris Newman [SMTP:Chris.Newman@innosoft.com]
> Sent:	Friday, 21 August 1998 5:43
> To:	Paul Leach
> Cc:	IETF LDAP Extensions WG
> Subject:	RE: Authentication Methods for LDAP - last call
> 
> 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.
	[Alan Lloyd]  
	I think that such a condition will exist while there is no
uniform distributed information infrastructure within and between
organisations. Distributed directories - X.500 with its DIT management
and prescriptive ACI (domain based) and mutual authentication is a major
attraction to those organisations trying to consolidate their
information infrastructures into an object oriented paradigm. None of
these (distributed) features exist in LDAP. As said - one cannot get
consistent (distributed) ACI and consistent authentication - efficiently
- until one deals with a distributed model and all the things that go
with it.

	The debates on authentication and access controls IMHO are just
symptomatic of LDAPs real weakness - no distributed system architecture
and no information management framework. The features in X.500 that
address these auth/aci ssues are there because there is a distributed
architecture to build them on.


> > 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.
	[Alan Lloyd]  
	DNs can contain UIDs and  DNs are also used for application
names, organisational assets and roles, etc. They need to be meaningful
- not hexadecimal. 
	Also I dont hold with the view that a directory service should
be built like a lump of concrete. DS's can be dynamic repositiories -
its a question of how they are commercially engineered and what
performance characteristics they have. ie. We can switch our DIB -
(database) online with no disruption to users - so we can on the fly
change a complete organisations directory information environment in
milliseconds.


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