Network Security Defined - Kerberos Sessions

• OpenVMS Resource Center
• TCP/IP Resource Center
• Spam & Virus Resources
• SSH Solutions

The Kerberos protocol is an authentication system for open systems and networks. Kerberos uses a set of encrypted keys and tickets for authentication, making authentication between two systems secure. Standard authentication methods, on the other hand, are not secure because the username and password are generally sent across the network in clear, readable text.

 

A Typical Kerberos Session

The following describes the general sequence of a Kerberos session (see also Figure 6):

1. The Client submits a request to the Kerberos Server to obtain a ticket-granting ticket (TGT). The Kerberos Server consults the Kerberos database (KDB) to get the user’s Kerberos password, and then encrypts it.
2. The Kerberos Server sends the encrypted password in the TGT to the Client. When the Client receives the TGT, it requests the user’s Kerberos password, then encrypts the password and compares it to the password in the TGT. A user is authenticated this way by the Kerberos Server.
3. The Client uses the TGT to apply for application service tickets so that users can access specific applications. Each service ticket proves the Client’s identity to an application server.
4. The Client presents the service ticket to the application server for authentication. The application server decrypts part of this ticket to check its authenticity.
5. If the application server finds that the service ticket is authentic, it applies the access control it previously defined for that client. If the application server cannot decrypt the service ticket, or if the service ticket has expired or is not authentic, the client is not authenticated.

The following sections describe a Kerberos session in more detail.

 

Getting a Ticket-Granting Ticket From the Kerberos Server

The Kerberos Server has a secure database on its machine. A Client must get a ticket-granting ticket (TGT), which cannot be read by the Client, from the Kerberos Server.

The TGT lets a Client submit specific requests to the Kerberos Server for application service tickets that grant access to application servers. A Client must have an application service ticket when it requests a service from an application server.

The following process describes getting a TGT (see also Figure 7):

1. The Client user sends a request to the Kerberos Server. The request packet contains the client's user name.
2. The Kerberos Server looks for the user name in its secure database and extracts the private key for it.
3. The Kerberos Server:
   1. Creates a randomly generated key to be used between the Client and the Kerberos Server. This is called the ticket-granting ticket’s session key.
   2. Creates a TGT that lets the Client obtain application service tickets from the Kerberos Server. The Kerberos Server encrypts this TGT using the private key obtained from the Kerberos database.

      Ticket: {user-name, Kerberos Server name, Client Internet address, session key}private key
      

      Kerberos also includes a timestamp in the TGT.

   3. Forms a packet containing the session key and the encrypted TGT, and encrypts the message from the Client’s private key obtained from the secure database.

      Packet: {session key, encrypted ticket-granting ticket) Client private key
       

   4. Sends the packet containing the user’s encrypted Kerberos password to the Client.

4. The Client uses its private key to decrypt the packet. When the Client receives packet, the procedure prompts the Client for its password. Using the private key, Client encrypts the user’s password and compares it to the encrypted password sent in the TGT. If the passwords match, the user has obtained a valid TGT; if not, the packet is discarded and the user cannot use Kerberos authentication to access any application servers.

 

Getting Application Service Tickets for Network Services from the Kerberos Server

Once a Client has a ticket-granting ticket, it can ask application servers for access to network applications. Every request of this kind requires first obtaining an application service ticket for the particular application server from the Ticket-Granting Service (TGS).

Figure 8 and the following process describe getting an application service ticket to use to access an application server.

The Client:

1. Creates an authenticator to be used between the Client and the Kerberos Server. The Client encrypts the authenticator using the session key that it received previously. The authenticator contains three parts:

   Authenticator: {user name, client Internet address, current time}
   

2. Creates the message to send to the Kerberos Server. The packet contains three parts:

   Packet: {ticket-granting ticket, encrypted authenticator, application server name)
   

3. Sends the packet to the Kerberos Server.

The Kerberos Server receives the packet from the Client.

The Kerberos Server:

1. Decrypts the ticket-granting ticket using its private key to obtain the session key. (The ticket-granting ticket was originally encrypted with this same key.)
2. Decrypts the authenticator using the session key.
3. Compares the:
   • User name in the ticket and authenticator
   • Kerberos Server name in the ticket and its own name
   • Internet address in the ticket, authenticator, and received packet
   • Current time in the authenticator with its own current time to make sure the message is authentic and recent.

After the Kerberos Server verifies the information in the ticket, the Server creates an application service ticket packet for the Client. The Server:

1. Uses the application server name in the message and obtains the application server's private key from the Kerberos database.
2. Creates a new session key and then an application service ticket based on the application server name and the new session key. The Kerberos Server encrypts this ticket with the application server's private key. This ticket is called the application ticket. This tickejt has the same fields as the ticket-granting ticket:

   Application service ticket: {user-name, Application server, name, client Internet address, new session key}Application server private key
   

3. Forms a packet containing the new session key and the encrypted application service ticket; encrypts the message with the session key, which the Client already knows:

   Packet: {new session key, Application ticket} session key
   

4. Sends the packet to the Client.

The Client decrypts the packet using the session key it received previously. From this message it receives the application service ticket that it cannot decrypt and the new session key to use to communicate with the application server.

 

 

Requesting a Service from the Application Server

Once a Client receives a ticket for an application service, the Client can request that service. The Client includes the application service ticket with the request for authentication that it sends to the application server.

The following describes the process for requesting a service from an application server (see also Figure 9).

The Client:

1. Creates an authenticator to use between the client and the application server. The client encrypts the authenticator using the new session key that it received:

   Authenticator: (user name, client Internet address, current timejnew session key
   

2. Creates the packet to send to the application server. The packet contains three parts:

   Packet: {Application ticket, encrypted authenticator, application server name)
   

3. Sends the packet to the application server.

The application server receives the packet from the Client and:

1. Decrypts the application service ticket using its private key. The application service ticket was originally encrypted with this same key. The application server obtains the new session key from the decrypted application service ticket.
2. Decrypts the authenticator using the new session key.
3. Compares the user name, application server name, Internet address, and the current time to make sure the packet is authentic and recent.

When the packet is authenticated, the application server examines its application service table to determine which resources the client can use and just what the client can do with those resources.

 

Summary Of Kerberos Authentication

There are three main steps in the Kerberos process. The Client:

1. Requests a ticket-granting ticket (TGT).
2. Presents the TGT and an authenticator to the Kerberos Server when it request access to an application server. The Kerberos Server grants the Client an application service ticket to access the application server.
3. Presents the application ticket and an authenticator to the application server when it requests access to the server. The server's access control policy either grants or denies access to services.

The Kerberos process uses tickets, authenticators, and messages. These elements provide specific encrypted information about clients and servers. Keys are used to encrypt and decrypt tickets, authenticators, and messages.

Some things to remember about tickets and authenticators:

• A Client must have a ticket-granting ticket and a service ticket to access any application server. The Client gets all tickets from the Kerberos Server.
• The Client cannot read tickets because the Kerberos Server encrypts them with the private key of the application server. Every ticket is associated with a session key.
• Every ticket-granting ticket has a lifetime (usually eight hours) and is reusable during that lifetime.
• Kerberos requires a new authenticator from the Client each time the Client starts a new connection with an application. Authenticators have a short lifetime (generally five minutes).
• The encrypted ticket and authenticator contain the Client's network address. Another user cannot use stolen copies without first changing his system to impersonate the Client’s network address.

Before the authenticator expires, the impersonator would need to: steal the original ticket and authenticator, prevent the original copies of the ticket and authenticator from arriving at the destination server, and modify its network address to match the client’s address.