LinkedIn Google+


Kerberos provides a means of verifying the identities of principals (e.g. a workstation user or a network server) on an open (unprotected) network.

This is accomplished without relying on assertions by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. Kerberos performs authentication under these conditions as a trusted third party authentication service by using conventional shared secret key cryptography.

The basic Kerberos authentication process is as follows:

  1. A client sends a request to the Authentication Server (AS) for credentials for a given Service Server or Kerberized Service (SS).
  2. The AS responds with these credentials, encrypted in the client’s key. The credentials consist of a ticket for the server and a temporary encryption key, often called a session key.
  3. The client transmits the ticket, which contains the client’s identity and a copy of the session key all encrypted in the server’s key, to the server.
  4. The session key, now shared by the client and server, is used to authenticate the client and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication.

Note that many applications use Kerberos’ functions only upon the initiation of a stream-based network connection. Unless an application performs encryption or integrity protection for the data stream, the identity verification applies only to the initiation of the connection, and it does not guarantee that subsequent messages on the connection originate from the same principal.

In order to avoid clients to enter a password every single time a SS is required to be accessed, the Ticket Granting Server (TGS) is introduced into the scene. The TGS issues a Ticket Granting Ticket (TGT) to client which is in turn used by clients to authenticate itself onto the SS.

The AS and TGS must run on a physical secure host and play the role of a Key Distribution Center (KDC). They maintain and have access to a database of principals (Kerberos principals) and their secret keys. An example is Microsoft Active Directory.

Eventually tickets are used to verify the identities of the principals in a transaction. However, not all content of tickets are encrypted. Additionally that encryption would not prevent an attacker to reuse those tickets if intercepted. Therefore additional information, the so-called authenticator, needs to be sent to prove that the message originated with the principal (client) to whom the ticket was issued. The authenticator is encrypted with the session key and includes a timestamp. The timestamp proves that the message was recently generated and is not a reused. Encrypting the authenticator in the session key proves that it was generated by a party possessing the session key. Since no one except the client and the SS know the session key (it is never sent over the network in the clear), this guarantees the identity of the client.

The integrity of messages exchanged between principals (client and SS) can also be guaranteed by using the session key. It is accomplished by generating and transmitting a collision-proof checksum (i.e. hash or digest function) of the client’s message keyed with the session key. Likewise privacy and integrity of the messages exchanged between principals can be secured by encrypting the data to be passed by using the session key contained in the ticket or the sub-session key found in the authenticator.


Following figure depicts the Kerberos messages exchanged between client, AS, TGS and SS according to Kerberos V5 Network Authentication Protocol as described in RFC 4120.

 Kerberos Authentication Protocol

Following phases (sequence of steps) take place over the time:

  • Client logon and authentication
  • Client service authentication
  • Client service request

Client Logon and Authentication


Client Service Authentication


Client Service Request



Artículo anterior


Artículo siguiente


Sin Comentarios


Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *