Kerberos

Ticket Acquisition Flow

• A Key Distribution Center(KDC) Comprises of Authentication Server and Ticket Granting Server.

Working

1. User -> Auth_Server

• A user sends and Unauthenticated message to the Authentication Server with the following details:

[Unencrypted]
Username
ServiceName/ID
User's IP Address
Request lifetime for TGT

2. Auth_Server -> User

• The KDC has a list of tables with the username and their secret keys

Alice : 1c34b32g3df5
Bob : 124vcdf-2;<24

• The Authentication Server checks if the username sent by the User exisits and sends back two message:

• The first one is signed by the User's secret Key

[Encrypted:UserSecretKey]
TGS Name/ID
TimeStamp
LifeTime
<TGSSessionKey>

• The second one, called the TGT encrypted with the TGS's Secret Key

[Encrypted:TGSSecretKey]
Username/ID
TGS Name/ID
TimeStamp
Users IP Address
TGT LifeTime
<TGSSessionKey>

3. User -> TGS

• The User generates their secret key to decrypt the first message.

SecretKey = HASH(password+salt+version)

• The salt is generally [e-mail]

• The hash algorithm is usually String2Key

• The key is then used to decrypt the first message send by the authentication server

• The User has now access to TGS ID and TGSSessionKey

• The User then generates two more messages to send to the Ticket Granting Server

• Frist one is a plain text with the following content

[Unencrypted]
ServiceName/ID
Requested Lifetime for ticket

• Second one is called the user authenticator and is encrypted with the TGS Session Key.

[Encrypted:TGSSessionKey]
Username/ID
TimeStamp

• The above two messages along with the TGT is sent to the TGS

4. TGS -> User

• TGS now has three piece of information:

• The TGT:

[Encrypted:TGSSecretKey]
Username/ID
TGS Name/ID
TimeStamp
Users IP Address
TGT LifeTime
<TGSSessionKey>

• The message:

[Unencrypted]
ServiceName/ID
Requested Lifetime for ticket

• And the User Authenticator

[Encrypted:TGSSessionKey]
Username/ID
TimeStamp

• The TGS also maintains a table with Service and their Secret Key

CRM : 1kjh24h2l35h
Finance : 12l1nkn1lk2l13l2k
Service : ljlk3h64lk4h6l3h6l

• The TGS looks at the unecrypted message and checks if the the ServiceName existis in its table.

• The TGS then decryptes the TGT with TGSSecretKey and gets access to TGSSessionKey

• The TGS then uses the TGSSessionKey to decrypt the User Authenticator

• The TGS then start to validate the things inside the TGT and User Authenticator

• It Compares:

  • Username/ID

  • TimeStamp

  • IP Address

• And checks if the TGT has expired or not

• The TGS maintains a cache which is a list of latest Authenticator messages. It checks if the User Authenticator it just recieved is not already present in the cache to prevent a replay attack.

• The TGS then start creating it's own messages to send back to the User:

• The first message:

[Encrypted:TGSSessionKey]
ServiceName/ID
TimeStamp
Lifetime
<ServiceSessionKey>

• And the Service Ticket:

[Encrypted:ServiceSecretKey]
Username/ID
ServiceName/ID
TimeStamp
User ID Address
Lifetime of Service Ticket
<ServiceSessionKey>

• ServiceSessionKey is a randomly generated symetric key.

• The TGS then sends back these messages back to the User

5. User -> Service

• The User already has the TGSSessionKey. It decrypts the first message gets access to ServiceSessionKey

• The User creates a new authenticator message and encrypt it with the ServiceSessionKey:

[Encrypted:ServiceSessionKey]
Username/ID
Timestamp

• The user then forwards this new Authenticator message with the Service Ticket to the Service.

[Encrypted:ServiceSecretKey]
Username/ID
ServiceName/ID
TimeStamp
User ID Address
Lifetime of Service Ticket
<ServiceSessionKey>

6. Service -> User

• The Service uses it's ServiceSecretKey to decrypt the Service Ticket.

• The Service can now access the ServiceSessionKey .

• The Service the uses the ServiceSessionKey to decypt the User Authenticator.

• The service then perfrom checks by comparing the Username and Timestamp, and that the service ticket is not expired.

• After everything is validated the service then checks it's cache to check if the authenticator it just recivieved is not already in the service's cache. This check provides replay protection.

• The service then creates it's own authenticator message known as service Authenticator and send it back to the user.

[Encrypted:ServiceSessionKey]
ServiceName/ID
Timestamp

7. User

• The user has a copy of ServiceSessionKey and uses it to decrypt the Service Authenticator.

• The User then verifies the ServiceName, and the timestamp.