In general Kerberos doesn't need a revocation system because ticket lifetimes should be short enough.
Within a realm it's often the case that other methods are used for revocation (e.g., lock the _account_, which will generally replicate with less latency than tickets will expire). Across realms is where things get interesting. A TGS would have to track the x-realm ticket vending it has done so that it could selectively propagate revocation notifications to those realms that ought to see them. Otherwise the system can't scale. In practice cross-realm TGTs tend to be shorter lived than local TGTs, and for this reason. A not-before timestamp in tickets might be useful, but not sufficient. A revocation system would have to involve an actual service sourcing and propagating revocation notifications to all those services that might need them, which in turn requires KDCs to keep track of all extant (as yet not expired) tickets vended. IMO it's worth exploring, but how worthwhile this is will depend on how common it is for people to run with a) very long-lived local TGTs and no other revocation scheme in place, and/or b) very long-lived cross-realm TGTs. Assuming the worst, then it's worthwhile, of course. In a way such a system would scale better than revocation does for PKI, where CRLs regularly go unchecked, and where OCSP responses have Kerberos ticket-like lifetimes. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
