revocation feature in Kerberos

[Nico Williams]

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
--