--On Thursday, September 21, 2006 10:45 AM +0100 Simon Wilkinson <[EMAIL PROTECTED]> wrote:
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
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.
--Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
