The Kerberos Protocol Explained

The Kerberos Protocol

Kerberos was designed to provide secure authentication to services over an insecure network. Kerberos uses tickets to authenticate a user and completely avoids sending passwords across the network. The following explanation describes the Kerberos workflow.

In the following example we will follow Barbara Jensen as she attempts to login into the server example.server.uconn.edu (example.server).

Authentication

Before accessing the server, Barbara must request authentication from the Key Distribution Center (KDC). Barbara will use her GNU kerberos client (kinit) to request a Ticket Granting Ticket (TGT). Her request to the KDC will contain the following:

  • Barbara’s NetID
  • The name of the requested service (example.server.uconn.edu)
  • Barbara’s workstations IP address
  • The desired lifetime of the TGT (as set by Barbara’s Kerberos client configuration)

The KDC upon receiving the request will check to make sure that Barbara’s user exists in it’s database. Since Barbara is a valid user, the KDC creates cryptographic keys for the session. The KDC will then send back two messages which contain the following:

  • Barbara’s NetID
  • The TGS ID (the KDC’s Identifier)
  • A Timestamp
  • Barbara’s workstations IP address
  • The lifetime of the TGT (as set by Barbara’s Kerberos client configuration)
  • The Ticket Granting Ticket (TGT)
  • Session Key

This message is encrypted with the private side of the session key. The second message contains the following:

  • The TGS ID (the KDC’s Identifier)
  • Timestamp
  • Session Key

This message is encrypted with the client secret key that is created by hashing the user’s password which was found in the Kerberos database. The client secret key is created through the hash of Barbara’s password and  using the salt bar12345@UCONN.EDU (Barbara’s NetID and Kerberos realm).

When Barbara enters her password into her GNU Kerberos client correctly, it will decrypt the second message, which will obtain Barbara’s half of the session key.

The Ticket Granting Server

Though Barbara has the TGT, her client cannot decrypt it since it is encrypted using the KDC’s secret key. Barbara’s client will now send two requests to the KDC asking for access to example.server.uconn.edu. The requests will contain the following:

  • Ticket Granting Ticket (TGT)
  • Kerberos ID of the requested service

The second message will contain:

  • Authenticator (composed of client ID and timestamp)

The second message will be encrypted using the Barbara’s session key. Upon receiving the requests, the KDC will decrypt them using it’s session key, and compare them. If they match properly, the KDC will send the following two responses containing the following:

  • Service ticket
  • Barbara’s NetID
  • Barbara’s IP Address
  • Validity Period
  • Service Session Key

This message is encrypted using example.server’s secret service key. The second message contains:

  • Service session key encrypted with Barbara’s session key

Service Request

Barbara’s client now has the ability to authenticate itself to Kerberized service. Barbara’s client will send two requests to the service containing the following:

  • Service ticket
  • Barbara’s NetID
  • Barbara’s IP Address
  • Validity Period
  • Service Session Key

This message is encrypted using example.server’s secret key. The second message contains:

  • New Authenticator (composed of client ID and timestamp)

The second message will be encrypted using the Barbara’s session key.

The service will decrypt the ticket using it’s own secret key to retrieve Barbara’s session key. Using the session key, the service decrypts the authenticator and compares Barbara’s NetID from the previous messages. If they match, the service sends the following message to Barbara’s client to confirm the service’s true identity:

  • The timestamp found in the New Authenticator sent to the service

The timestamp is encrypted using Barbara’s session key.

Barbara’s client will decrypt the confirmation message, and will check it timestamp. If it is correct then Barbara’s client can trust the service, and Barbara can begin to use the service.