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.) ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos