On Tue, Jul 26, 2011 at 6:59 AM, <ghud...@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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos