Re: Synchronize LDAP with DCE ?

[Booker Bense <bbense@networking.stanford.edu>]

On Tue, 29 Jun 1999, Kurt D. Zeilenga wrote:

> At 07:15 AM 6/29/99 -0700, Booker Bense wrote:
> >On Fri, 25 Jun 1999, Kurt D. Zeilenga wrote:
> >> Note: overloading userPassword with the kerberos may not actual be wise.
> >- IMHO, this is a really bad idea. One of the really nice advantages
> >of the current krbName approach is that it effectively gives you a 
> >convient "group" or role mechanism. i.e. an ldap DN can have many 
> >krbNames. Also, there are potential uses for krbName beyond kerberos
> >authentication. 
> 
> I concur.
> 
> >- Overloading UserPassword with SASL mechanisms doesn't make 
> >a whole lot of sense to me.
> 
> We're not overloading userPassword with SASL mechanisms.  We
> are encrypting userPassword.  SASL is orthogonal to the encryption
> of the userPassword value as stored in the directory.

- Okay, I guess I misunderstood the intent of the first message. 
I thought you were encoding the type of authentication to use
inside the UserPassword field. If you're just encoding encryption
I think that's probably a reasonable idea. 


> 
> For security reasons, a server should not maintain knowledge
> of cleartext passwords.  I would hope no SASL mechanism which
> required such knowledge.
> 

- Well, there are certainly some authentication schemes that require
cleartext passwords. I'm thinking of things like RADIUS and the
various CHAP schemes used by PPP. The solve the cleartext over the 
wire problem, but they do require a cleartext password. 
SASL doesn't address these per se, but it doesn't forbid them
either... 

> >Doing this kind of embedding makes ACL's even more difficult.
> 
> userPassword (encrypted or not) should be protected.  This
> protection may be based upon authentication method, SASL mechanism,
> and/or wether or not the wire in encrypted.

- Certainly, My objection was to crunching authentication data into
a single field. Each SASL method is most likely going to require 
it's own unique set of ldap fields. Some of these will need to 
be private and some will need to be publically readable. 

> 
> >In this one case ( unix pwds ) I guess
> >it makes some sense, but as a general principal, I think it's a 
> >REALLY BAD IDEA. 
> 
> I disagree.   Storing and providing cleartext passwords is
> dangerous.  SASL can be used to provide secure authentication
> but such does not reduce the need to store and provide an
> encrypted userPassword values.  cleartext passwords are evil
> and should be avoided.  (I highly recommend --disable-cleartext).

- I couldn't agree more. Again I misinterpreted the initial 
message. 

> 
> As far as ACL goes, the use of SASL bind does NOT imply
> secure authentication nor transport.  And simple bind does
> NOT imply insecure authentication and transport.   The
> server's ACL mechanism should support simple who clauses:
> 	auth=[secure|insecure]
> 	trans=[secure|insecure]
> 
> as well as detail who clauses:
> 	authtype=[simple|kerberos|sasl]
> 	saslmech=[digest-md5|skey|kerberos|...]
> 	transproto=[tcp|ssl|ipsec|...]
> 

- SASL is a means for figuring out how to authenticate, as an 
acl flag it is rather meaningless. I think a more useful 
categorization would just be 'authmech', regardless of how
you arrived at using that method.  


> This would allow:
> 	access attr=userPassword
> 		by auth=insecure none	# disallow insecure auth
> 		by trans=insecure compare	# only auth if insecure trans
> 		by trans=secure self write	# self write if trans is secure
> 		by * none			# default none
> 

- One minor nit: The "kerberos" method that OpenLdap currently uses
is far from ideal. It does not use the full capablities of
kerberos authentication (i.e. no mutual authentication). I really
wish it were called something else.... 

- Booker C. Bense