how to "ban" clients?

[Nico Williams]

On Tue, Jul 26, 2011 at 6:59 AM,  <ghudson at mit.edu> wrote:
> It's a reasonable desire to want to flip a switch and make a
> particular user instantly unable to affect your environment.  That's
> the kind of thing you should get from a centrally managed
> authentication system, right?  Unfortunately, there are three holes
> big enough to drive a truck through:
>
>  1. The user can keep requesting service tickets until the user's TGT
>     expires.

Right, this one can be fixed in the KDC (TGS), and should be.  The
other two holes are not an excuse to not fix this one because if one
wishes to go fix all three holes one might want to start with the easy
one first.

>  2. The user can keep using service tickets until they expire.

Right.  Nothing much can be done about this other than: a) set max
service ticket lifetimes short enough that this hole can be tolerated,
or b) implement a revocation protocol.  (b) would be nice, but hard.

>  3. The user can keep using active sessions until the session is
>     invalidated somehow (interrupted connection, restarted client or
>     server).

This is the hardest problem of all.  Short ticket lifetimes don't help
because expiring sessions with their tickets means re-keying or
re-connecting often and that's a pain (particularly in protocols that
don't have re-keying), and then there's local access where tickets are
completely irrelevant.

Plugging this hole requires a revocation protocol.  I don't mean
OCSP-like -- the TGS effectively is Kerberos' OCSP equivalent (or,
more correctly, OCSP is PKIX's Kerberos equivalent :).  I mean a
protocol by which services participating in a realm can get notified
of principal revocation so they can act accordingly (whatever that
might be).  Cross-realm relationships make a revocation protocol...
interesting.

It'd be nice to have a standard revocation protocol for Kerberos...

Nico
--