revocation feature in Kerberos

[Chris Hecker]

Unless things have changed, the KDC doesn't check for account lock if the
tgt is valid.  There's a thread from a couple years back where I asked
about this and then patched it, but I haven't submitted patches for the
current revision.  I need to do this at some point.  Or maybe it got fixed?

Chris
 On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <elric at imrryr.org> wrote:

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