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

Re: errant SASL/GSSAPI setup?

On 31 Aug 2006, at 22:59, Quanah Gibson-Mount wrote:

Yep, MIT Kerberos is exactly what I was beginning to expect as well, which is why I asked about the Kerberos libraries being used. That's what it looks like is being used from Allan's libraries he provided as wel.

As mentioned on this list numerous times, do *not* use MIT kerberos with OpenLDAP. Bad things happen. Use Heimdal Kerberos.

I've been thinking further about this. Whilst not wanting to get drawn into an MIT Kerberos vs Heimdal debate, I think that in this case Heimdal's behaviour is in error.

The lifetime of a GSSAPI context is derived from the minimum of the requested lifetime, the lifetime of the initiator credentials, and the lifetime of the acceptor credentials. Cyrus doesn't request a minimum lifetime, and Kerberos acceptors don't have a lifetime (they come from the keytab), so the lifetime becomes equal to the lifetime of the initiator credentials.

It's fairly clear that allowing encryption options to occur within a context whose lifetime has expired is an error. Unfortunately, SASL- GSSAPI has no concept of rekeying an existing connection, so the only option upon context expiry is to tear down and build a new connection.

Whilst this isn't the correct forum for discussing the details of GSSAPI security contexts, or of the limitations of the current SASL- GSSAPI mechansim, there is a general OpenLDAP issue here. OpenLDAP needs to be able to handle a session for which security layer operations start failing, and to be able to deal with (on the 'client' side) re-establishing connections where this occurs