I've been thinking further about this. Whilst not wanting to getdrawn
into an MIT Kerberos vs Heimdal debate, I think that in thiscase
Heimdal's behaviour is in error.
The lifetime of a GSSAPI context is derived from the minimum of
therequested lifetime, the lifetime of the initiator credentials, andthe
lifetime of the acceptor credentials. Cyrus doesn't request aminimum
lifetime, and Kerberos acceptors don't have a lifetime (theycome from the
keytab), so the lifetime becomes equal to the lifetimeof the initiator
credentials.
It's fairly clear that allowing encryption options to occur within
acontext whose lifetime has expired is an error. Unfortunately,
SASLGSSAPI has no concept of rekeying an existing connection, so the
onlyoption upon context expiry is to tear down and build a new connection.
Whilst this isn't the correct forum for discussing the details ofGSSAPI
security contexts, or of the limitations of the current SASLGSSAPI
mechansim, there is a general OpenLDAP issue here. OpenLDAPneeds to be
able to handle a session for which security layeroperations start
failing, and to be able to deal with (on the'client' side)
re-establishing connections where this occurs