Authentication with Kerberos

2010-02-26

Kerberos is a protocol that enables secure authentication can be done in an insecure network. It allows clients and servers on a network to authenticate themselves to each other. This means that the server knows that the client user is correct while the client knows that the server is correct. Authentication takes place against a central server, called “Key Distribution Center” (KDC), which consists of two logical components, an “Authentication Server “(AS) and a “Ticket Granting Server” (TGS). Kerberos uses tickets for clients as proof of an approved authentication. When a client wants to use a new service, it sends its ticket instead of performing a new authentication. A KDC has a database of all system users and their passwords.

Authentication with Kerberos is as follows:

The user enters their username and password on their client computer. The client creates a hash of the password, which then becomes the client’s secret key. A hash is a one way encryption as a mathematical pattern creates an unstructured string of text that can not decrypted.

The client sends the user’s username in clear text to the AS. AS retrieves the user’s password from its database and makes a similar hash of the password that the client did. This means that both client and server have the same secret key without even sending the password. AS sends back two messages to the client:

One is a “Client / TGS session key” which is encrypted by the client’s secret key and can be used for future contact with the TGS.

The second is a “Ticket Granting Ticket (TGT), which contains the client’s identity, the network address and the period it is valid. This message is encrypted with a secret key that only the TGS know.

When the client wants to access a service it sends two messages to the TGS:

The first contains the client’s TGT and the identity of the service to connect to.

The second message is showing the authentication. It contains the client’s identity and a time stamp that is encrypted with a “Client / TGS session key”.

The TGS recieves the messages and decrypts the first one with its own private key and produces the client’s “Client / TGS session key”. With that key, the TGS can decrypt the second message. The servern then sends two messages in return:

The first is a “client to server ticket” containing the identity of the client, network address, validity period and a “client / server session key”. This ticket is encrypted with the service’s secret key.

The second message contains a “client / server session key” which is encrypted with a “client / TGS session key”.

The client now has enough information to authenticate to the service and sends two messages to it:

The first is the “client to server ticket”.

The second message contains the client’s identity and a timestamp. The message is encrypted with the “client / server session key”.

The service decrypts “client to server ticket” with its own private key to get the “client / server session key”. The service decrypts the second message. In order to confirm to the client that the service is correct, it sends back a message that contains the client’s timestamp though it has been added with one. The message is encrypted with the “client / server session key”. The client decrypts it and checks if the timestamp changed correctly. If everything went right, the client can start using the service.