[37614] in Kerberos
Re: "revoking" a TGT?
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Aug 10 12:20:28 2016
Date: Wed, 10 Aug 2016 11:20:02 -0500
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20160810162001.GD27339@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20160810160540.GC27339@localhost>
Cc: Jerry Shipman <jes59@cornell.edu>, "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, Aug 10, 2016 at 11:05:43AM -0500, Nico Williams wrote:
> Even the simplest reliable revocation schemes beyond having TGSes check
> the client principal's record presume a high-performance pub-sub
> protocol and implementation(s).
Reliable multicast type protocols would be nice for this, though a
unicast (TCP-based, no doubt) protocol should be needed as well.
I've tested a C10K tail-f service to 20k concurrent connections on
loopback just fine, and that could be part of a unicast protocol.
Modern async I/O APIs make this easy enough. Such a thing can scale by
fanout too, so it's plenty scalable, though multicast would generally
scale best in many networks.
A revocation pub-sub protocol wouldn't be too difficult to design and
implement. But it is work that would have to be done.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
