[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Kerberos 5 Support for OpenLDAP-release



On Fri, 17 Sep 1999, Ben Collins wrote:

> On Fri, Sep 17, 1999 at 11:14:20AM -0400, Jeffrey Mahoney wrote:
> > 
> > 
> > 	Hello -
> > 
> > 	A few days ago, I started searching for Kerberos 5 support (or any
> > hints of development) for OpenLDAP.
> > 
> > 	I didn't find anything, so I wrote it myself.
> > 
> > 	What's the code review process, etc for code integration into the
> > OpenLDAP project?
> > 
> > 	Basically, my code is an API translation from krb4 calls to krb5 calls.
> > 
> > 	I've added an LDAP_AUTH_KRB5 authentication type, as well as an
> > ldap_krb5_bind{,_s} call for TGT-based binds.

- Not to rain on anybody's parade, but the K4 based auth from Umich
that this is based on has some pretty bad flaws. It doesn't do mutual
authentication so it is vunerable to replay attacks. It's certainly
better than password in the clear,but it's not full kerberos
authentication. IMHO, the correct way to do this is use the SASL 
code to do kerberos authentication. If SASL was well integrated
into the OpenLdap core, you'd have a straightforward way to use
whatever authentication and security scheme you wanted. 

> > 
> > 	Kerberos password authentication is supported, but overridden if the
> > "userpassword" field is non-null.
> > 
> > 	I've posted my changes on the web at http://www.csh.rit.edu/~jeffm/ldap
> 
> Great! I've been meaning to work on this myself. Questions, is this against the
> openldap 2 devel source, or the 1.2.x source? I ask, because it really needs to
> be against the devel tree. Another question, does this support the Krb5 DES
> encrypted sessions? If not, do you know if thats possible?
> 

- To get encrypted sessions, you'll need to work within the protocol
and the LDAP V3 way to do that is to use SASL. Trying to extend the 
Umich K4 stuff to do encryption would requiring rewriting lot's of 
ldap code. The way umich does K4 makes it very difficult to do 
encryption, they just treat the kerberos service ticket like a 
rather long password. There's no hooks back into the I/O channel. 

- I've been meaning to take a closer look at all this stuff for 
a long time, but too many other things have popped to the top of 
the stack. 

- Booker C. Bense