On Tuesday, August 30, 2005 23:59:16 -0400 Jeff Aitken <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
