GSSAPI - context lifetime

[Nicolas Williams]

On Thu, May 29, 2008 at 02:23:09PM -0700, Russ Allbery wrote:
> "Machin, Glenn D" <GMachin at sandia.gov> writes:
> 
> > I apologize if this is not the right forum for this question.
> >
> > The gss_wrap and seal routines are dependent on the context endtime. The
> > context endtime is derived from the service ticket lifetime. For a
> > gssftp session if multiple data transfers exceed the ticket lifetime the
> > gssftp session fails.
> >
> > Can someone tell me why the context is tied to ticket lifetime?
> 
> Because all products of a Kerberos authentication should be tied to a
> ticket lifetime.  Otherwise, the ticket lifetime isn't meaningfully
> enforced; someone who obtains a ticket at some point could authenticate to
> a service and simply stay authenticated, and there would be no good way of
> rejecting their later operations.

You'd think.  And I agree.

But this actually cause problems for SASL/GSSAPI (and probably, come to
think of it, SASL/GS2) applications.  This includes IMAP, a very popular
protocol whose clients don't always make re-connecting totally
transparent.

Specifically:

 - SASL has no way to re-do authentication, nor even to send an error
   message saying "your context has expired," nor do SASL apps tend to
   have a way to resume a broken session.

 - To be pedantic security contexts expire not only when the tickets do,
   but when the keys have been used too much or too long.  But for some
   enctypes "too much" isn't all that much, which can lead to context
   expiration prior to ticket expiration, which means you can't just get
   very long-lived tickets to work-around the SASL issue unless you're
   getting AES tickets (which by now is probably no big deal).

   Of course, issuing long-lived service tickets is a bad idea since
   there's no revocation protocol.

Nico
--