How Kerberos Authentication Works

Terminology

The following are some of the terms that will be used while introducing the Kerberos authentication protocol:

• Authentication Server (AS) - a server that handles authentication requests from users

• Service Provider (SP) - a server that hosts service(s) a user wishes to access

• Principal (P) - name of either a user or a server

• Secret Key (K_i) - a key that is associated and known only to a Principal

• Session Key (S_xy) - a shared key used to encrypt/decrypt content between two Principals

• Ticket - a proof of identity of a Principal to access a service. It is an encrypted content that includes the Principal of the user, the Principal of SP the user wishes to access, start date and time, expiry lifetime, and a session key

• Ticket Granting Server (TGS) - a server that issues identity Tickets to users for accessing any Service Provider

Authentication Steps

Let us set some context before we describe the steps involved in Kerberos protocol. The following are the details:

• Alice - is the user with principl A and a secret key K_a

• Bob - is the service provider (SP) with principl B and a secret key K_b

• Mars - is the authentication server (AS) which is where the initial request for authentication is sent. It is responsible for generating a session key and a ticket to be presented to the ticket granting server (TGS)

• Pluto - is the ticket granting server (TGS) with principal P and a secret key K_p

• Star - is the database that is accessible to both Mars and Pluto. All the principals A, B, and P along with their corresponding secret keys K_a, K_b, and K_p are stored here. The secret key for a principal is typically the hash of their password. This way no one has access to the actual passwords

• K_i(x) - is means the secret key K_i is used to encrypt any content x

Step. 1

Alice logs into a workstation to access the service provided by Bob. This action will send an authentication request to Mars.

The authentication request will look like:

[A, B]

where

A is the principal of Alice

B is the principal of Bob

Step. 2

Mars receives the authentication request from Alice.

Mars will check in Star if both A and B are valid. If either A or B or both are invalid, then an error message will be sent back to Alice. Since both A and B will be valid in our situation, Mars will send an authentication response to Alice.

The authentication response will contain 2 parts - an encrypted session key and an encrypted ticket and will look like:

[K_a(B, TS, LF, S_ap), K_p(A, TS, LF, S_ap)]

where

K_a is the secret key of Alice

B is the principal of Bob

TS is the start timestamp from when the ticket is valid

LF is the maximum lifetime of the ticket

S_ap is the session key to be used between Alice and Pluto

K_p is the secret key of Pluto

A is the principal of Alice

NOTE :: The start timestamp TS and maximum ticket lifetime LS are created by Mars and will be passed along in all the subsequent steps

Step. 3

When Alice receives the authentication response from Mars, it will prompt Alice to enter her password. Once the password is provided, a hash of the password is created which will be same as the secret key K_a of Alice so that she can extract the session key S_ap.

To access the service provided by Bob, Alice will need a service ticket from Pluto. In order to get the service ticket, Alice will send a service ticket request to Pluto. The service ticket request contains 3 parts - the principal of the service provide Bob, encrypted identity of Alice, and the encrypted ticket K_p(A, TS, LF, S_ap) that Alice got from Mars in the authentication response in Step. 2 and will look like:

[B, S_ap(A, TS, LF), K_p(A, TS, LF, S_ap)]

where

B is the principal of Bob

S_ap is the session key to be used between Alice and Pluto

A is the principal of Alice

TS is the start timestamp

LF is the maximum ticket lifetime

K_p is the secret key of Pluto

Step. 4

Pluto receives the service ticket request from Alice.

Since Pluto knows its secret key K_p, it can decrypt the ticket K_p(A, TS, LF, S_ap) from the service ticket request to extract the session key S_ap.

Next Pluto will decrypt the encrypted user identity S_ap(A, TS, LF) from the service ticket request to extract the principal A and compare it with the principal from the decrypted ticket. If they dont match Pluto will send an error message back to Alice.

Next Pluto will check if the start timestamp TS plus maximum ticket lifetime LF has not expired (less than the current timestamp). If expired, Pluto will send an error message back to Alice.

At this point the identity of Alice has been verified and Pluto will send a service ticket response to Alice.

The service ticket response will contain 2 parts - an encrypted session key and an encrypted ticket and will look like:

[S_ap(B, TS, S_ab), K_b(A, B, TS, LF, S_ab)]

where

S_ap is the session key used between Alice and Pluto

B is the principal of Bob

S_ab is the session key to be used between Alice and Bob

K_b is the secret key of Bob

A is the principal of Alice

TS is the start timestamp

LF is the maximum ticket lifetime

Step. 5

When the workstation where Alice logged in receives the service ticket response from Pluto, it will decrypt the encrypted session key S_ap(B, TS, S_ab) using the session key S_ap from the service ticket response to extract the session key S_ab to be used between Alice and Bob.

Alice now has the service ticket to access the service provided by Bob.

Alice will now send a service request to Bob. The service request contains 2 parts - encrypted identity of Alice and the encrypted ticket K_b(A, B, TS, LF, S_ab) from the serice request response from Pluto in Step. 4 and will look like:

[S_ab(A, TS, LF), K_b(A, B, TS, LF, S_ab)]

where

S_ab is the session key to be used between Alice and Bob

A is the principal of Alice

TS is the start timestamp

LF is the maximum ticket lifetime

K_b is the secret key of Bob

B is the principal of Bob

Step. 6

Bob reqceives a service request from Alice.

Since Bob knows its secret key K_b, it can decrypt the ticket K_b(A, B, TS, LF, S_ab) from the service request to extract the session key S_ab.

Next Bob will decrypt the user identity S_ab(A, TS, LF) from the service request using the session key S_ab to extract the principal A and compare it with the principal from the decrypted ticket. If they dont match Bob will send an error message back to Alice.

Next, Bob will check if the start timestamp TS plus maximum ticket lifetime LF has not expired (less than the current timestamp). If expired, Bob will send an error message back to Alice.

At this point the identity of Alice has been verified and Bob will send a service response to Alice.

The service response is to prove the identity of Bob and will contain an encrypted identity and will look like:

[S_ab(B, TS)]

where

S_ab is the session key used between Alice and Bob

B is the principal of Bob

TS is the start timestamp

Step. 7

When the workstation where Alice logged in receives the service response from Bob, it will decrypt the encrypted identity S_ab(B, TS) to extract and validate both the principal B of Bob and the start timestamp TS.

At this point Alice has access to the service provided by Bob.