[33680] in Kerberos
Re: how to "ban" clients?
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Jul 27 13:19:12 2011
MIME-Version: 1.0
In-Reply-To: <201107261159.p6QBxiNh015029@outgoing.mit.edu>
Date: Wed, 27 Jul 2011 12:19:04 -0500
Message-ID: <CAK3OfOgS_WDmZ-7SbmDs-dFYZ2WH0CKqR5dYyXvaWx_E5RVHPg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: ghudson@mit.edu
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Jul 26, 2011 at 6:59 AM, <ghudson@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. Theother two holes are not an excuse to not fix this one because if onewishes to go fix all three holes one might want to start with the easyone first.
> 2. The user can keep using service tickets until they expire.
Right. Nothing much can be done about this other than: a) set maxservice 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 helpbecause expiring sessions with their tickets means re-keying orre-connecting often and that's a pain (particularly in protocols thatdon't have re-keying), and then there's local access where tickets arecompletely irrelevant.
Plugging this hole requires a revocation protocol. I don't meanOCSP-like -- the TGS effectively is Kerberos' OCSP equivalent (or,more correctly, OCSP is PKIX's Kerberos equivalent :). I mean aprotocol by which services participating in a realm can get notifiedof principal revocation so they can act accordingly (whatever thatmight 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.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos
