revocation feature in Kerberos

[Roland C. Dowdeswell]

On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>

> In general Kerberos doesn't need a revocation system because ticket
> lifetimes should be short enough.

You can get many of the benefits of a revocation system by simply
vending service tickets with a shorter lifetime than the TGT used
to obtain them.  If you, e.g. vend service tickets with a 15 minute
lifetime, then the client will need to contact the KDC once every
15 minutes to continue to connect to a service.  The KDC, of course,
will validate that the client's account has not been locked at this
point.

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

Right and by using different lifetimes for service tickets as their
TGT, you can break apart the ``check that the user knows their
passwd'' check from the ``check that the account is still valid''
check.

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

Simply issue 15 minute xrealm TGTs.  Sorted.

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

There is a trade-off here.  Using very short service and xrealm
tickets puts the burden on the client to obtain new credentials
frequently whereas a revocation list places the burden on the server
to accept a feed of revocations.  Each has its pros and cons.  One
main pro of using short non-TGT ticket lifetimes is that it is
already possible without writing new code.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/