Ticket History #4222: GSSAPI context being destroyed when ticket cache renewed

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:



It would be great to have this fixed!

--Quanah

--On Friday, September 01, 2006 12:55 AM -0400 Sam Hartman via RT
<rt-comment@krbdev.mit.edu> wrote:


Well, this is very different than how Heimdal's behavior operates, and
quite frankly I prefer what Heimdal does. I see no reason to make an
*already* established & encrypted connection break just because the context
has ended.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Quanah Gibson-Mount via RT <rt-comment@krbdev.mit.edu> writes:



This makes me wonder what in GSS-API is looking at the ticket cache. I
would have thought that once the GSS-API context was established and
authentication was finished, there wouldn't be further need to look at the
Kerberos ticket cache, but apparently that's not correct?

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>

--On Wednesday, September 06, 2006 5:45 PM -0400 Jeffrey Altman via RT
<rt-comment@krbdev.mit.edu> wrote:


Hm, after going back through the thread, I can't tell specifically if it is
actually the refresh or the expiration that caused the problem, because the
user set it to a 5 minute ticket with a 4 minute refresh to demonstrate the
issue.

I myself do not use MIT kerberos for my OpenLDAP servers, so reproducing
this in my environment would take a bit of work. I'm currently lacking the
internal development environment where I'd usually test such things. :/

I can get in contact with the user who reported the issue, and see what
additional data they can gather, if you like.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

As the person quoted right at the beginning, I should probably
contribute my findings here.

I don't believe that ticket refresh is an issue. I can quite happily
refresh, destroy, or replace my Kerberos credentials from under a
running GSSAPI context, without causing that context to break.

The issue (if there is an issue) is that Heimdal and MIT's behaviour
differ when the initiator's credentials do actually expire. Heimdal
allows the context to continue to be used for wrapping operations
past expiry - MIT expires the context, and calls to wrap() or unwrap
() fail. This difference in behaviour is an issue when using SASL
applications with security layers, as the only way to renew the
context is to reconnect to the server. In addition, many applications
have inadequate error handling around their security layer
implementations.

I suspect that the current MIT behaviour is correct. Whilst there's
no explicit language in RFC2743, it suggests that the length of time
for which the context will be valid depends on credential lifetime.

Simon.

Quanah Gibson-Mount via RT <rt-comment@krbdev.mit.edu> writes:


There is at least *some* error inside Cyrus SASL. The behavior that we're
seeing (in a different context than the one Quanah originally raised) is
that Cyrus SASL will go into a tight loop inside the library logging
messages about expired contexts without ever returning to the application.
That's clearly broken. I just haven't been able to find where the
brokenness is yet (mostly because I haven't had a chance to look in
depth).

Whether there's also a separate error in Kerberos is a different question.
It's looking to me like there's actually (arguable) incorrect behavior in
Heimdal, in that once a Kerberos ticket expires, I think a strong argument
can be made that the products of that ticket, such as the session key used
to provide confidentiality, are no longer valid either.

I don't know what that would mean for, say, a version of ssh that did
integrity protection using GSSAPI, though. Having your login session go
away because your original ticket expired might be technically correct but
sounds rather bad.

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>