Re: errant SASL/GSSAPI setup?

[Simon Wilkinson <simon@sxw.org.uk>]

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

Cheers,

Simon.