The Key Distribution Center

In the Key Distribution Center (KDC) there are actually three different functions which are performed. There is an Authentication Server (AS), a Ticket Granting Server (TGS) and the KDC Database which holds shared secret information about each principal in the Kerberos realm. Since these functions are incorporated into the KDC, and are also linked by the services provided to the principals, they usually reside on the same machine.

The Key Distribution Center Database

When a principal is created a shared secret is created that only the KDC and the created principal know about. This shared secret is used to encrypt communications between the principal and the KDC. This shared secret is never transmitted in plain text. The KDC

database contains all of the principals in the realm and their associated secret keys. There is no requirement that this database reside on the same physical machine that KDC is on but it is considered good practice to store the information on the same system.

Functions of the Key Distribution Center

The two primary functions of the KDC are:

򐂰 Granting a Ticket Granting Ticket

򐂰 Granting a Service Ticket

After reading this section you will be able to understand the full communication protocol that is followed when two principals want to communicate with each other as well as the security involved in the interactions.

Receiving a Ticket Granting Ticket

When a principal logs on to either his computer or a kerberized application for the first time either that day or since a previous ticket he has received has expired an interaction takes place between the client and the Authentication Server.

In this interaction the principal sends a request (AS_REQ) to the AS based on their identity and who they want to talk to, in this case it is a principal and the TGS. This information is transmitted in plain text, the AS then based on the identity of the principal builds a Ticket Granting Ticket (TGT), and replies to the principal encrypting the ticket using the shared secret of the principal who requested it. This response is known as the AS_REP. There is no encryption between the principal and the AS initially because the authentication server must first discover the identity of the principal to determine the shared secret. Once the identity is known to the AS it responds with a TGT that has been encrypted using the principal’s shared secret. This was a downfall of Kerberos Version 4 as the ticket could be captured and then an offline brute force attack could be performed to find the principal’s secret key.

Kerberos 5 introduces a method called pre-authentication which we will see later in this chapter. The request and reply between the AS is detailed in Figure 4-2. The encrypted ticket can be decrypted by the authentic principal and used to obtain services on the network such as the telnet example described in the kerberized box above. Even though the principal can decrypt the TGT given to him by the AS there is still another level of encryption beneath this level. This extra level of encryption is performed using the shared secret of the AS and the Ticket Granting Server (TGS). We will see why there is this extra encryption in the following section.

Kerberized: This is the term given to services which use Kerberos for authentication.

Chapter 4. Kerberos Network Authentication 41 Figure 4-2 Receiving a TGT (AS_REQ and AS_REP)

As well as passing back the TGT the AS creates a session key so that the principal can communicate with the TGS.

Receiving a Service Ticket

When a principal wants to access a service this TGT is given to the Ticket Granting Server, in addition the principal name of the service that the principal wants to access. This request is known as a TGS_REQ. The TGS takes the TGT and decrypts it using the TGS’s shared secret key with the AS, this is done to make sure that the ticket is valid, the session key also becomes available after this decryption. Along with the principal name of the service an authenticator is also sent. An authenticator is a piece of information, usually a timestamp, which is encrypted using the session key. The TGS can decrypt this authenticator because of decrypting the TGT and retrieving its half of the session key. The TGS can then check to see if the ticket is valid. It does this by testing to see if the ticket has expired, or if the ticket has been post dated. If the TGT did not have these two levels of encryption then it would be possible for a malicious user to indefinitely extend the life of a ticket. We talk about how Kerberos has built in security to combat situations like these, later on in this chapter.

The TGS then issues the principal a Service Ticket (ST). This reply from the TGS is known as a TGS_REP. The ST allows the principal to access the requested service assuming the principal has proved its identity to the service and that the principal is authorized to use that service. The TGS_REP containing the service ticket is encrypted using the session key created for communication between the principal and the TGS. This is outlined in Figure 4-3.

1.^AS_REQ

The client initiates a connection to the AS, requesting a TGT. This request contains the client identity and the identity of the server.

2

Client

2. AS_REP

The AS_REQ is compared with existing principals to retrieve the shared secret key. A normal response is a ticket-granting ticket and a session key, which will be used for further communication with the KDC. All are encrypted with the client's secret key.

Figure 4-3 Receiving a Service Ticket(TGS_REQ and TGS_REP)

After the ST has been received and decrypted the principal can initiate communications with a service.

Communicating with a kerberized service

The principal now has in its possession a service ticket and a session key. The service ticket allows the principal to talk to the service and the session key is used to encrypt

communications and verify the identity of the principal(Figure 4-4).

A AP_REQ now takes place. The principal sends to the service computer, the service name, along with the service ticket and an authenticator. The service ticket like the TGT is encrypted using the shared secret between the AS and the service. The service decrypts this ticket to obtain information about the principal requesting the service and to retrieve the session key that can be used to verify communications with the principal. When the service has the session key it can the decrypt the authenticator. If the authenticator decrypts correctly then the service knows its talking to a valid principal of the service. A AP_REP is then initiated from the service to the principal. This response is an authenticator generated by the service.

This authenticator could be fabricated though by replaying the original AP_REQ authenticator sent to the service. To combat this after the authenticator has been decrypted it is returned with the principal name of the service included, this is also done to verify the identity of the service principal to the client principal.

3.

When the client wants to initiate a connection with a service, the client first requests a service ticket from the ticket-granting server. This request consists of the service name, the TGT, and an authenticator proving the identity of John.

4.

The TGS responds with a service ticket for the requested service and a session key. This response is encrypted with the session key received earlier with the TGT.

Chapter 4. Kerberos Network Authentication 43 Figure 4-4 Accessing the service (AP_REQ and AP_REP)

The Kerberos protocol uses the same procedure for all communications.