How is the long term key between a client and the KDC distributed?
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
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.
Windows Privacy Tools - http//www.privacywindows.com