how to "ban" clients?

[ghudson@MIT.EDU]

Let's try again without the analogies.

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.

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

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

You're proposing to fix (1), which is the only one of the three which
can be addressed on the KDC.  This comes at either a performance cost
(looking up the client every time, if it's a local principal) or a
complexity cost (adding a configuration variable, and making the TGS
validation code paths conditional on whether or not we've looked up
the client).  Certainly, addressing (1) would limit the scope of the
things a bad actor could do after account closure, but not completely,
and only if the bad actor didn't anticipate the account closure by
requesting a bunch of service tickets.

>From an implementor's perspective, it's sometimes better to have a
simpler system with three weaknesses than a more complicated system
with two.  An attacker doesn't care about the number of weaknesses as
long as it's positive.  I can understand the appeal of doing whatever
you can because not all bad actors are perfect automatons with
unlimited foresight, but it's not compelling to me in this case.

To actually get rapid-reaction account closure, you need to implement
a temporary blacklist in the servers--and in your case, possibly also
in the clients.  I know, that's a huge headache for an application
developer to have to worry about.  But I don't think there's a
comprehensive substitute at the Kerberos level.

(Trivia: we used to sort of address (3) by refusing to unwrap messages
in the GSSAPI krb5 mech after a user's tickets expired.  That at least
puts a time bound on how long the user can affect services, for
applications using GSSAPI wrap and unwrap.  We had to turn this off
because it was too disruptive to existing applications, which were
generally not written by security people.  Also, there are a lot of
applications like ssh which don't use GSSAPI wrap and unwrap, so it
wasn't really solving the problem.)