After an employee has logged in and used one service, which tickets and keys does each party hold?
The client holds its secret key, the TGS session key, the service session key, and the TGT and service ticket (both still encrypted); the AS and TGS hold the long-term keys (user, KDC, service); the service holds its secret key, the decrypted service ticket and the service session key.
| Party | Long-term keys | Session keys | Tickets |
|---|---|---|---|
| Client (laptop) | Client secret key | TGS session key, service session key | TGT (sealed with the KDC key), service ticket (sealed with the service key) |
| AS | All users' keys (user database), KDC key | (created the TGS session key) | (issued the TGT) |
| TGS | KDC key, all services' keys (service database) | (saw the TGS session key, created the service session key) | (issued the service ticket) |
| Service | Its own service secret key | Service session key (from the ticket) | The service ticket it received |
Two observations follow. First, the KDC does not need to keep the session keys or tickets it issued: they come back to it inside the tickets, which is why the KDC can be stateless and easily replicated. Second, the client's cache is valuable: TGT plus TGS session key together are enough to obtain service tickets in the user's name, so whoever steals the cache can act as the user until the tickets expire.
Go deeper:
MIT Kerberos documentation: Credential cache — what the client stores and the different cache types.