Re: The usability of service ticket lifetimes

On Tue, Aug 21, 2012 at 3:40 PM, Jeffrey Altman
<[email protected]> wrote:
> The Kerberos community has years of experience with enforcement of
> expiration times on application protocols such as those protected by
> GSS-API and the conclusion has been that expiration enforcement on
> connections is a bad idea because of the usability problems that are caused.

I am and have been of two minds about this.

I'm not happy with apps that allow connections to stay up forever
without further efforts to handle revocation.  And we have no standard
revocation protocol.  Oof.

But at the same time expiring connections when the tickets used to
authenticate expire has been disastrous for usability.  All sorts of
things go wrong within clock skew of ticket expiration.  Two types of
problems arise:

 - bugs around clock skew of ticket expiration, of which there have
been too many, sadly

 - application protocols that can't re-authenticate without reconnecting.

Of the latter IMAP has been used as an example before.  But IMAP
clients can typically recover state quickly enough that reconnection
should just be a hiccup (as long as there are no transfers that
require so long that the connection always expires first).  The
filesystem protocols can handle re-authentication.  LDAP is pretty
much stateless (but don't expire a connection in the middle of a write
operation!).   ...

The former are all just depressing.  We had such a bug in the Solaris
NFS/RPC stack where every RPC resulted in a new security context when
within clock skew of ticket expiration due to a client-side bug.  I'm
quite sure there have been others.

What to do?

Some possibilities:

 - expire contexts sometime *after* ticket expiration -- unlikely to
make us happy in general, but at least this should steer clear of the
bugs I mentioned above

 - add a protocol for checking the status of a client principal (but
this won't work with asymmetric x-realm trusts)

 - add a revocation protocol (but how to scale to large networks?!)

 - ???

Of these I prefer the first, but I think we could/should add the
second (the service would talk to the client princ's realm using the
client's ticket as a second ticket for the TGS-REQ and get an answer
indicating whether the client is still live) (but there are privacy
issues involved).

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg