KDC failover

Jeff Aitken jaitken at aitken.com
Tue Aug 30 23:59:16 EDT 2005


Based on a discussion at work today, I'm confused as to how 
kerberos services work in the presence of a failure of one of
the KDCs.  I suspect I'm missing something obvious, but I can't
quite figure it out.

To start with, here's how I understand things to work in general:

1. The client sends a request to the AS requesting a TGT.  The client 
supplies the user principal, TGT principal name, and a random value.

2. The AS responds with the TGT, which has two parts.  The first
part is encrypted with the TGS key and contains, among other things,
a session key that will be used by the client to communicate with 
the TGS.  The second part is encrypted with the client's key and
contains, among other things, that same session key and a copy of
the random value supplied by the client.

3. When the client wants to access a kerberized service, he 
contacts the TGS with a request, which is encrypted with the
session key received in step #2 above.

4. The TGS also generates a two-part response.  The first part 
(the service ticket) is encrypted with the service key, and 
contains a new session key which will be used by the client when
communicating with the service, along with a few other bits,
including the client's IP address.  The second part is encrypted
with the client's key and contains a copy of that new session key.

5. The client contacts the service and supplies the service 
ticket provided in step #4.  Assuming the service is able to
validate the ticket (by using its own key), communication with
the client proceeds normally.


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. 

What am I missing?


--Jeff



More information about the Kerberos mailing list