Kerberos (protocol)

Kerberos is a distributed authentication service ( network protocol ) for open and insecure computer networks ( including the Internet ), which was developed by Steve Miller and Clifford Neuman based on the Needham - Schroeder authentication protocol (1978). The current latest version is Kerberos 5 is defined in RFC 4120 and uses ASN.1 for encoding.

Kerberos was developed as part of Project Athena at MIT; only the version 4 in the late 1980s was also used outside of MIT. Kerberos provides a stable and uniform authentication in an unsecured TCP / IP network to secure host computers. The authentication assumes a trusted third party ( referred to as a Trusted Third Party ). This third party is a specially protected Kerberos 5 network service. Kerberos support single sign-on, which means a user has to register only once. Following this, he can use all available network services to re-enter their password without another time.

The name is derived from the hellhound Cerberus from Greek mythology that guards the entrance to the underworld.


With Kerberos, there are three parties involved: the client, the server that the client wants to use, and the Kerberos server.

The Kerberos service to authenticate both the server to the client, and the client to the server in order to prevent man-in- the-middle attacks. Also, the Kerberos server itself authenticates itself to the client and the server and verifies their identity themselves.

Kerberos tickets for authentication. To use the Kerberos service, a client must first log in to the Kerberos server. He asks the Kerberos server to a Ticket Granting Ticket (TGT ). For this, the user of the client either a password to enter, or the TGT is obtained directly from the user application. With the TGT, the client is able to request additional tickets for services without having to enter a password again. It is also negotiated a session key for communication between the client and the Kerberos server. It can be used to encrypt the data traffic.

In order to use a service that supports Kerberos, the client requests another ticket. This ticket is then sent by the client to the service, which checks whether it should allow the client to access. Again, a session key is agreed and verified the identity of client, server, and Kerberos server.

The RFC calls for hosts involved a time-alignment of the systems involved, in order to avoid time differences about five minutes. Here offers the use of NTP.

Schematic sequence of the Kerberos authentication

Key to figure:

Scenario: User u want to use service s, he has no TGT. The smaller rectangles (light green, light orange, white) are data packets that are related respectively to the following the star (*) key is encrypted. The abbreviation stands for ST: ticket to use the service see in the large rectangles (server) and in the ellipse (client) are the information that are known to the respective service / client according to the arrows. Kerberos Authentication Server and Ticket Granting Server (TGS ) both have access to the key database of their administration area (realm ), so they both know all client and server key.

A Kerberos server is responsible for a realm, that is, he managed only accounts that belong to his realm. The realm for example, the DNS domain name in capital letters, such as EXAMPLE.COM be. A computer can belong to only one realm. To be able to access services in other realms via Kerberos trust relationships must be established between the different realms. So it is possible that a user can access services from A.EXAMPLE.COM in B.EXAMPLE.COM without having to authenticate again.

In Kerberos4 is supported only as a cipher DES. Kerberos5 is able to negotiate the cipher used and the checksum used.

Users, hosts and services to authenticate with Kerberos using symmetric keys. The key is a name of the Kerberos principal that assigned. For hosts, the principal host / @ (eg host / @ EXAMPLE.COM ), for services / @ (eg imap / @ EXAMPLE.COM ) and for users / @ (eg mueller / admin @ EXAMPLE.COM ). The instance is when a user principal to the type of account. The user mueller / admin @ EXAMPLE.COM is a Kerberos administrator.

Through Kerberos particular attacks can be prevented by passive sniffing, but also complicates spoofing, dictionary, replay, and other attacks.

Kerberos support

In order for a network service can use Kerberos, it is necessary that the service is able to deal with Kerberos tickets. Be installed and configured on the server and client host must each have a Kerberos client. Both the client and the server software must support Kerberos. For Kerberos 5 client, server, and Kerberos server must use a common encryption and checksum.

There are two different types of Kerberos support: either Kerberos is fully supported or the client sends the server the Kerberos principal and password in plain text.

For the Apache HTTP Server, there is the Kerberos module mod_auth_kerb.