Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Subject: GSSAPI context being destroyed when ticket cache renewed
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1753

Hello,

In helping a user on the openldap-software list track down why
replication (SASL/GSSAPI based) wasn't working correctly on his servers,
we found that the problem was the way in which MIT Kerberos handles
ticket refreshes.  Basically, the way the replication work is we have a
master and a replica.  The replica makes a persistent bind to the master
with SASL/GSSAPI.  On my servers using Heimdal kerberos, this works
fine, and can last for days.  However, on his servers using MIT
Kerberos, once the ticket cache was refreshed (we both use k5start by
Russ Allbery to do this), the GSSAPI context was destroyed, meaning that
traffic could no longer be encrypted between the master and the replica.
 Replication would stop, and the master and replicas would both get into
odd states after that.

Another user reported having the same problems with MIT kerberos:

--On Thursday, August 31, 2006 9:41 PM +0100 simon@sxw.org.uk wrote:

> 
> If you're using MIT Kerberos, I strongly suspect that the problem you're
> seeing is due to the behaviour of its GSSAPI library. With MIT's
> implementation a gssapi context is only valid for the lifetime of the
> initiator's credential. So, when your clients credentials expire, the
> security context also expires, and the client and server both start
> failing to decrypt each others packets. We first noticed this problem
> because slapd would crash when the decryption failure occurred - this
> problem no longer exists - but MIT Kerberos's behaviour has not changed.
> 
> Just renewing your credentials won't help, as the new credentials will
> only be used when establishing a new security context, which only happens
> when a new connection is opened.


It would be great to have this fixed!

--Quanah