A. The final stage in the Kerberos key exchange is the key used between a client (or server) and the KDC for distributing the session key used to encrypt information between a client and a server.
For this the client and the KDC share a long term key and this long term key is just a hashed version of the client users password.
The password is never sent over the network. When John logs on the Kerberos client on the workstation runs it through the one-way hash algorithm producing a cryptographic key.
This is sent to the KDC and at the KDC it extracts this hash from its record and checks they match. This only happens only on initial logon to the network.
At initial logon the Kerberos client asks the KDC for a session key and ticket it can use for further KDC communication during the logon session, this avoids the need for the hashed password to be constantly generated and checked.
The KDC replies with a copy of the session key it has generated for communication between the client and itself encrypted with the clients long-term key (hashed password). The client can decrypt using its cached long-term key.
The KDC also sends a copy of the session key encrypted with the KDC’s own long-term key which is known as the Ticket-Granting Ticket
(TGT) and the client will send this in future to the KDC for communication in the same way the client-server session ticket worked. Only the KDC can decrypt the TGT as only it has its long-term key what the session key was encrypted with.
The Ticket Granting Ticket is valid only for the logon and discarded on logoff hence its also called a “logon session key”.
In future KDC communication the client would send the normal requests encrypted with its session key shared with the KDC and the KDC's TGT from which it can extract the session key needed to talk to the client. This means the KDC does not have to maintain a list of session keys for each client.