KDC failover

[Jeffrey Hutzelman]

On Tuesday, August 30, 2005 23:59:16 -0400 Jeff Aitken <jaitken at aitken.com> 
wrote:

> Assuming I've got that part right, here's the part that's got me
> confused.  In step #2, the AS generates a session key that will be
> used by the client during all future communication with the TGS;
> i.e., this is the key with which the client will encrypt future
> service ticket requests.  However, if the KDC that granted the TGT
> to the client fails, and the client sends a service ticket request
> to a different KDC, how does that second KDC validate the client?
> Unless I'm missing something, the second KDC doesn't have a copy of
> the session key that the client uses to encrypt the request, so he
> shouldn't be able to decrypt it successfully.

The TGT is just like any other ticket; it contains information encrypted in 
the service's secret key, including a session key.  The TGS, then, is a 
single service potentially distributed over multiple machines (KDC's). 
Each machine providing that service has a copy of the service key, and thus 
can decrypt the ticket, which is provided by the client with every request.

Except for a short-lived replay cache, the KDC itself is essentially 
stateless.  It doesn't remember anything about tickets it has issued.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA