Now we’ll breakdown each step of the process to give you a better understanding of what’s going on behind the scenes:
1. Login#
The user enters their username and password. The Kerberos-enabled client will then transform that password into a client secret key.
2. Client Requests for Ticket Granting Server#
The client then sends a plaintext message to the authentication server containing:
- the entered username
- the name of the requested service
- the network address of the user
- how long they’re requesting access for
3. Server Verifies the Username#
The username is checked against verified usernames stored in the KDC. If the username is familiar, the program will proceed.
4. Ticket Granting Ticket Returned to the Client#
The authentication server sends back two encrypted messages to the client:
Message A
can be decrypted with the client secret key created in step 1. It contains the TGS name, a timestamp, ticket lifetime, and a newly granted Ticket Granting Server Session key.
Message B
is the Ticket Granting Ticket and can only be decrypted by the TGS secret key held. This contains your username, the TGS name, a timestamp, your network address, ticket lifetime, and the same TGS Session key.
5. Client Obtains the TGS session key#
The client now decrypts message A
using the client secret key, giving the client access to the TGS Session key. Message B
is stored locally in its encrypted state.
6. Client Requests Service Access From Server#
The client now sends back two messages:
Message C
is an unencrypted message containing the name of the requested service, the lifetime, and the still encrypted message B
.
Message D
is an authenticator encrypted with the TGS Session key and contains your name and a timestamp
7. Server Verifies the service#
The TGS then checks that the requests service exists in the KDC. If it does, the program proceeds.
8. Server Obtains TGS Session Key#
The server now pulls the still encrypted message B
sent in message C
. Message B
(the TGT) is then decrypted using the server’s TGS secret key, giving the server the TGS session key.
Using this TGS Session key the server can now decrypt message D
.
Now the server has the timestamp and name from both message B
and message D
(the authenticator message). The server makes sure the names and timestamps are the same to prevent fraudulent messages. It also checks the timestamp against the lifetime of the ticket to ensure it has not timed out.
9. Server Generates Service Session Key#
The server then generates a random service session key and two more messages.
Message E
is encrypted with the service secret key and contains your name, the requested service name, a timestamp, your network address, the ticket lifetime, and the service session key.
Message F
is encrypted with the TGS session key held by both client and server. This message contains all of the same information from message E
except your username and network address.
10. Client Obtains Service Session Key#
Using the TGS session key cached from step 5, the client decrypts message F
to obtain the service session key.
The client now sends two more messages, this time to the service:
Message G
is another authenticator message, this time encrypted with the service session key. It contains your name and timestamp.
Message H
is a copy of message E
, which is still encrypted with the service secret key.
12. Service Decrypts Message G#
The service then decrypted message H
with its service secret key to obtain the service session key from within. Using this key, the service decrypts message G
.
13. Service Verifies the Request#
The service then verifies the request by comparing the usernames, timestamps, and lifetimes from messages G
and H
.
14. Service is Authenticated to the Client#
The service then sends message I
encrypted with the service session key held by both service and client. Message I
is an authenticator containing the ID of the service and a timestamp.
15. Client Verifies the Service#
Then, the client decrypts message I
using the service session key cached from step 10. The client then checks the ID and timestamps contained within. If both match the expected results, the service is deemed safe.
16. Client and Service Communicate Freely#
Confident that both client and service are mutually authenticated, Kerberos allows the client to communicate with the service.