KDC failover

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

KDC failover

Jeff Aitken
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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KDC failover

Jeffrey Hutzelman


On Tuesday, August 30, 2005 23:59:16 -0400 Jeff Aitken <[hidden email]>
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) <[hidden email]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos