What happens step by step in phase 2 of Kerberos, the exchange between client and Ticket-Granting Server?

The client sends a TGS-REQ with the wanted service ID, its TGT and a fresh authenticator encrypted with the TGS session key; the TGS opens the TGT with the KDC key, takes the session key out, checks the authenticator, then returns a service ticket (encrypted with the service's key) plus a new service session key (encrypted with the TGS session key).

* Phase 2: the TGT replaces the password; the TGS needs no memory of phase 1. *

1. The client creates an authenticator (user ID + timestamp) encrypted with the TGS session key from phase 1.
2. It sends the TGS-REQ (Ticket Granting Service Request): service ID of the wanted service, desired lifetime, the authenticator and the TGT.
3. The TGS decrypts the TGT with the KDC key.
4. It decrypts the authenticator with the TGS session key found inside the TGT.
5. It verifies everything: user ID in authenticator equals user ID in TGT, TGT still valid, timestamp fresh.
6. It creates a random service session key and packs it with the service ID, a timestamp and the ticket's validity; this package is encrypted with the TGS session key.
7. It creates the service ticket (user ID, service ID, timestamp, the service session key), encrypted with the service secret key from its service database.
8. The client receives both (TGS-REP): it decrypts the package with the TGS session key and caches the service session key; the service ticket it caches still encrypted.

Go deeper:

• RFC 4120, Section 3.3: The Ticket-Granting Service exchange — TGS-REQ and TGS-REP and the checks on the TGT.