Kerberos specific process

Kerberos#specific process

AS (Authentication Server) = authentication server
KDC (Key Distribution Center) = key distribution center
TGT (Ticket Granting Ticket) = ticket granting ticket, ticket
TGS (Ticket Granting Server) = ticket authorization server
SS (Service Server) = specific service provider

(Note: This process uses symmetric encryption; this process occurs in a certain Kerberos realm; lowercase letters c, d, e, g are messages sent by the client, and uppercase letters A, B, E, F, H are the messages sent by each server message back.)

First, the user logs in using a program on the client (the user's own machine):

1. The user enters the user ID and password to the client.
2. The client program runs a one-way function (mostly a hash) to convert the password into a secret key, which is the client's (user's) "user's secret key".

Subsequently, the client is authenticated (the client (Client) obtains a ticket granting ticket (TGT) from the authentication server (AS)):

1. The client sends a plaintext message to the AS, applying for the service that the user should enjoy, for example, "User Sunny wants to request a service" (Sunny is the user ID). (Note: the user does not send the "user key" or password to the AS.) The AS can query the application user's password from the local database and convert it into the same "user key" through the same method.
2. AS checks if the user id exists in the local database and returns 2 messages if the user exists:
   • Message A: Client/TGS Session Key (Client/TGS Session Key) (the session key will be used in the communication (session) between the client and TGS in the future), encrypted by "user key"
   • Message B: TGT (TGT includes: "client/TGS session key" in message A, user ID, user URL, TGT validity period), encrypted by "TGS's secret key"
3. Once the client receives message A and message B, the client first tries to decrypt message A with its own "user key". If the password entered by the user does not match the password in the AS database, message A cannot be successfully decrypted. Enter the correct password and pass the generated "user key" to decrypt message A, so as to get the "client/TGS session key". (Note: Client cannot decrypt message B, because B is encrypted with "TGS key"). Having a "client/TGS session key" is enough for a client to authenticate with TGS.

Then, service authorization (client gets a ticket (client-to-server ticket) from TGS):

1. When the client needs to apply for a specific service, it sends the following 2 messages to TGS:
   • Message c: the content of message B (the TGT encrypted by the "TGS key"), and the service ID of the service you want to obtain (note: not the user ID)
   • Message d: Authenticator ( Authenticator includes: user ID, timestamp), encrypted by "client/TGS session key"
2. After receiving message c and message d, TGS first checks whether the required service exists in the KDC database. After finding it, TGS uses its own "TGS key" to decrypt message B (that is, TGT) in message c, thus obtaining The previously generated "Client/TGS Session Key". TGS then uses this session key to decrypt the message d to obtain the Authenticator containing the user ID and timestamp, and verifies the TGT and Authenticator, and returns 2 messages after the verification is passed:
   • Message E: Client-to-server ticket (client-to-server ticket) (the ticket includes: "client/SS session key" (Client/Server Session Key), user ID, user URL, validity period), by providing the encrypted with the service's secret key
   • Message F: Client/SS session key (Client/Server Session Key) (this session key will be used in future communication (session) between client and SS), encrypted by "client/TGS session key"
3. After receiving these messages, the client decrypts message F with the "client/TGS session key" to obtain the "client/SS session key". (Note: The client cannot decrypt message E because E is encrypted with the "server key").

Finally, service request (client gets service from SS):

1. After obtaining the "client/SS session key", the client can use the services provided by the server. The client sends 2 messages to the specified SS:
   • Message e: the message E "client-server ticket" in the previous step, encrypted with the "server key"
   • Message g: new Authenticator (including: user ID, timestamp), encrypted by "client/SS session key"
2. SS uses its own "server key" to decrypt message e to obtain the "client/SS session key" provided by TGS. Then use this session key to decrypt the message g to get the Authenticator , (same as TGS) to verify the ticket and Authenticator, and return a message if the verification is passed (confirmation letter: confirm the identity is true, willing to provide services): message H:
   new timestamp (The new timestamp is: add 1 to the timestamp sent by the client, v5 has canceled this practice), and encrypt it through the "client/SS session key"
3. The client decrypts the message H through the "client/SS session key", gets the new timestamp and verifies whether it is correct. If the verification is passed, the client can trust the SS and send a service request to the SS.
4. SS provides corresponding services to the client.