Kerberos Operation

Finally, having acquired the concepts described in the preceding paragraphs, it is possible to discuss how Kerberos operates. We’ll do this by listing and describing each of the packets which go between the client and KDC and between client and application server during authentication. At this point, it is important to underline that an application server never communicates directly with the Key Distribution Center: the service tickets, even if packeted by TGS, reach the service only through the client wishing to access them. The messages we will discuss are listed below (see also the figure below):

AS_REQ is the initial user authentication request (i.e. made with kinit) This message is directed to the KDC component known as Authentication Server (AS);

AS_REP is the reply of the Authentication Server to the previous request. Basically it contains the TGT (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user);

TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a service ticket. This packet includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key;

TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS;

AP_REQ is the request that the client sends to an application server to access a service. The components are the service ticket obtained from TGS with the previous reply and an authenticator again generated by the client, but this time encrypted using the service session key (generated by TGS);

AP_REP is the reply that the application server gives to the client to prove it really is the server the client is expecting. This packet is not always requested. The client requests the server for it only when mutual authentication is necessary.

Kerberos 5 Protocol Messages

Now each of the previous phases is described in greater detail with reference to Kerberos 5, but pointing out the differences with version 4. Nevertheless, it should be borne in mind that the Kerberos protocol is rather complicated and this document is not intended as a guide for those who wish to know the exact operating details (in any case, these are already written up in RFC1510). The discussion below has been left intentionally abstract, but sufficient for those who examine the KDC logs to understand the various authentication transitions and any problems which occur.

Note: the subsequent paragraphs enclose unencrypted data in round brackets (), and encrypted data in curly brackets {}: ( x, y, z ) means that x, y, z are unencrypted; { x, y, z }K indicates that x, y, z are encrypted all together using the symmetrical key K. It is also important to note that the order in which the components are listed in a packet has nothing to do with the real order found in the actual messages (UDP or TCP). This discussion is very abstract. Should you wish further details, please refer to RFC1510 having a good background on the descriptive protocol ASN.1

1.4.1 Authentication Server Request (AS_REQ)

In this phase, known as the initial authentication request, the client (kinit) asks the KDC (more specifically the AS) for a Ticket Granting Ticket. The request is completely unencrypted and looks like this:

AS_REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )

where: PrincipalClient is the principal associated with the user seeking authentication (e.g. pippo@EXAMPLE.COM); PrincipalService is the principal associated to the service the ticket is being asked for and thus is the string “krbtgt/REALM@REALM” (see note*); IP_list is a list of IP addresses that indicate the host where it is possible to use the ticket which will be issued (see note **); Lifetime is the maximum validity time (requested) for the ticket to be issued.

Note *: it may seem superfluous to add the Principalservice to the initial authentication request since this would be constantly set to the TGS principal i.e. krbtgt/REALM@REALM. However, this is not the case, indeed, a user planning to use just one service during a work session, would not use the Single Sign-on, and may ask the AS directly for the ticket for this service, thus skipping the subsequent request to the TGS. From an operational standpoint (MIT 1.3.6) the following command is sufficient:

kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM

Note **: IP_list may also be null. In this case the corresponding ticket can be used by any machine. This resolves the problem of those clients under NAT, since their request would arrive at the service with a source address different from that of the requesting user, but the same as the router making the NAT. Instead, in the case of machines with more than one network card, IP_list should contain the IP addresses of all the cards: in fact it would be difficult to predict beforehand with which connection the server which provides the service would be contacted.

1.4.2 Authentication Server Reply (AS_REP)

When the previous request arrives, the AS checks whether PrincipalClient and PrincipalService exist in the KDC database: if at least one of the two does not exist an error message is sent to the client, otherwise the Authentication Server processes the reply as follows:

It randomly creates a session key which will be the secret shared between the client and the TGS. Let’s say SKTGS;

It creates the Ticket Granting Ticket putting inside it the requesting user’s principal, the service principal (it is generally krbtgt/REALM@REALM, but read the note* for the previous paragraph), the IP address list (these first three pieces of information are copied as they arrive by the AS_REQ packet), date and time (of the KDC) in timestamp format, lifetime (see note*) and lastly the session key. SKTGS; the Ticket Granting Ticket thus appears as follows:

It generates and sends the reply containing: the ticket created previously, encrypted using the secret key for the service (let’s call it KTGS); the service principal, timestamp, lifetime and session key all encrypted using the secret key for the user requesting the service (let’s call it KUser). In summary:

It may seem that this message contains redundant information (PrincipalService, timestamp, lifetime and session key). But this is not the case: since the information present in the TGT is encrypted using the secret key for the server, it cannot be read by the client and needs to be repeated. At this point, when the client receives the reply message, it will ask the user to enter the password. The salt is concatenated with the password and then the string2key function is applied: with the resulting key an attempt is made to decrypt the part of the message encrypted by the KDC using the secret key of the user stored in the database. If the user is really who he/she says, and has thus entered the correct password, the decrypting operation will be successful and thus the session key can be extracted and with the TGT (which remains encrypted) stored in the user’s credential cache.

Note *: the actual lifetime, i.e. which is put in the ticket is the lowest of the following values: the lifetime requested by the client, the one contained in the user’s principal and that in the service principal. Actually in terms of implementation another limit can be set from the configuration of the KDC and applied to any ticket.

1.4.3 Ticket Granting Server Request (TGS_REQ)

At this point, the user who has already proved to be who he/she says (thus in his/her credential cache there is a TGT and session key SKTGS and wants to access the service but does not yet have a suitable ticket, sends a request (TGS_REQ) to the Ticket Granting Service constructing it as follows:

Create an authenticator with the user principal, client machine timestamp and encrypt everything with the session key shared with the TGS, i.e.:

Authenticator = { PrincipalClient , Timestamp }SKTGS

Create a request packet containing: the service principal for which the ticket is needed and lifetime uncrypted; the Ticket Granting Ticket which is already encrypted with the key of the TGS; and the authenticator just created. In summary:

TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }KTGS

1.4.4 Ticket Granting Server Reply (TGS_REP)

When the previous request arrives, the TGS first verifies that the principal of the requested service (PrincipalService) exists in the KDC database: If it exists, it opens the TGT using the key for krbtgt/REAM@REALM and extracts the session key (SKTGS) which it uses to decrypt the authenticator. For the service ticket to be issued it checks that the following conditions have a positive outcome:

the TGT has not expired;

The PrincipalClient present in the authenticator matches the one present in the TGT;

The authenticator is not present in the replay cache and has not expired;

If IP_list is not null it checks that the source IP address of the request packet (TGS_REQ) is one of those contained in the list;

The previously checked conditions prove that the TGT really belongs to the user who made the request and therefore the TGS starts to process the reply as follows:

It randomly creates a session key which will be the secret shared between the client and the service. Let’s say SKService;

It creates the service ticket, putting inside the requesting user’s principal, the service principal, the list of IP addresses, the date and time (of the KDC) in timestamp format, the lifetime (as the minimum between the lifetime of the TGT and that associated with the service principal) and lastly the session key SKService. Known as TService the new ticket is:

It sends the reply message containing: the previously created ticket, encrypted using the service secret key (let’s call it KService); the service principal, timestamp, lifetime and new session key all encrypted using the session key extracted from TGT. In summary:

When the client receives the reply, having in the credential cache the session key SKTGS, it can decrypt the part of the message containing the other session key and memorise it together with the service ticket TService which, however, remains encrypted.

1.4.5 Application Request (AP_REQ)

The client, having the credentials to access the service (i.e. the ticket and related session key), can ask the application server for access to the resource via an AP_REQ message. It should be borne in mind that, unlike the previous messages where the KDC was involved, the AP_REQ is not standard, but varies depending on the application. Thus, the application programmer has the job of establishing the strategy with which the client will use its credentials to prove its identity to the server. However, we can consider the following strategy by way of example:

The client creates an authenticator containing the user principal and timestamp and encrypts everything with the session key SKService that it shares with the application server, i.e.:

Authenticator = { PrincipalClient , Timestamp }SKService

It creates a request packet containing the service ticket TService which is encrypted with its secret key and the authenticator just created. In summary:

AP_REQ = Authenticator { TService }KService

When the previous request arrives, the application server opens the ticket using the secret key for the requested service and extracts the session key SKService which it uses to decrypt the authenticator. To establish that the requesting user is authentic and thus grant access to the service, the server verifies the following conditions:

the ticket has not expired;

The PrincipalClient present in the authenticator matches the one present in the ticket;

The authenticator is not present in the reply cache and has not expired;

If IP_list (extracted from the ticket) is not null it checks that the source IP address of the request packet (AP_REQ) is one of those contained in the list;

Note: the previous strategy is very similar to the one used by the Ticket Granting Server to check the authenticity of the user requesting a service ticket. But this should not be surprising, since we have already explained that the TGS can be considered as an application server whose service is to provide tickets to those who prove their identity with a TGT.

1.4.7 Pre-Authentication

As seen in the description of the Authentication Server Reply (AS_REP), before distributing a ticket the KDC simply checks that the principal of the requesting user and service provider exist in the database. Then, particularly if it involves a request for a TGT, it is even easier, because krbtgt/REALM@REALM certainly exists and thus it is sufficient to know that a user’s principal exists to be able to obtain a TGT with a simple initial authentication request. Obviously, this TGT, if the request comes from an illegitimate user, cannot be used because they do not know the password and cannot obtain the session key for creating a valid authenticator. However, this ticket, obtained in such a easy way can undergo a brute-force attack in an attempt to guess the long-term key for the service the ticket is intended for. Obviously, guessing the secret of a service is not any easy thing even with current processing powers, however, with Kerberos 5, a pre-authentication concept has been introduced to reinforce security. Thus if the KDC policies (configurable) request pre-authentication for an initial client request, the Authentication Server replies with an error packet indicating the need to pre-authenticate. The client, in light of the error, asks the user to enter the password and resubmit the request but this time adding the timestamp encrypted with the user long term key, which, as we know, is obtained by applying the string2key to the unencrypted password after having added the salt, if there is one. This time, the KDC, since it knows the secret key of the user, attempts to decrypt the timestamp present in the request and if it is successful and the timestamp is in line, i.e. included within the established tolerance, it decides that the requesting user is authentic and the authentication process continues normally.
It is important to note that pre-authentication is a KDC policy and thus the protocol does not necessarily require it. In terms of implementation, MIT Kerberos 5 and Heimdal have pre-authentication disabled by default, while Kerberos within Windows Active Directory and the AFS kaserver (which is a pre-authenticated Kerberos 4) request it.