[Date Prev][Date Next]
Re: errant SASL/GSSAPI setup?
--On Thursday, September 21, 2006 10:45 AM +0100 Simon Wilkinson
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
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
I agree with this last statement. I'm not sure I agree with the rest of
it, since then you expect behavior of things like SSH+GSSAPI to be
different than things like Krb5 logins, where the connection stays
encrypted regardless of expiration of the initial ticket.
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html