Kerberos

From CryptoDox, The Online Encyclopedia on Cryptography and Information Security

Jump to: navigation, search
Kerberos

The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the entrance to Hades. Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.

Kerberos was designed at MIT and is freely available from them. MIT also makes avaible the source-code of Kerberos. Kerberos is also available in many commercial products.

Kerberos has evolved into a strategic security standard that provides secure authentication services to users, applications, and network devices, which eliminates the threats caused by passwords being stored or transmitted across the network. Kerberos also provides data integrity to ensure messages are not tampered with on the network and message privacy (encryption) to ensure messages are not visible to eavesdroppers on the network.

Contents

Kerberos at Work

Kerberos is based on the concept of a trusted third party, called the key distribution center (KDC). The KDC performs verification of users and services. Kerberos is used to autenticate/verify the users and network services. To accomplish this, a trusted Kerberos Server issues tickets to users; which have a limited lifespan and are stored in a user's credential cache. These tickets are replacements of the standard username and password based authentication.

A Kerberos server consists of the following elements:

  • Realm - a user-defined administrative boundary.
  • Key Distribution Center (KDC) - the heart of the Kerberos realm. It provides Kerberos authentication services by issuing encrypted tickets that require secret keys to decode.
  • Principal - a unique name for a user or service stored in a KDC.
  • Tickets - records that help a client authenticate to a server.

A client sends a request for a ticket to the KDC. The KDC creates a ticket-granting ticket (TGT) for the client. It then encrypts it using the KDC key and sends the encrypted TGT back to the client. The client uses the TGT to obtain further service tickets, which provide the proof of the client's identity.

Once the identity of the user requesting for a ticket is confirmed, KDC returns initial credentials for the user, consisting of a TGT and a session key. If a principal needs to access any service located on a particular system, the KDC issues a service ticket for the specific service. A service ticket can be associated with one or more Kerberos-secured services on the same system. The service ticket is usually used by a client application on behalf of the user, to authenticate the user to the Kerberos-secured network service.

The Kerberos-using client application automatically handles the transactions with the KDC. Service tickets and associated session keys are generally cached in the user’s credentials cache file along with the user’s TGT.

The Kerberos Authentication Protocol

The following steps describe how a client and a server authenticate each other using Kerberos.

1: The user sends the following information to the Authentication Service (AS) to obtain credentials: Client (User Name), Server (Application Server), Timestamp, and Nonce.

2: AS issues a temporary session key, which is encrypted with the user’s secret key (a key derived from the user password, which is stored in the KDC), and a TGT encrypted with the TGS’s secret key. The TGT contains the name of the user and a copy of the session key to be used by the user and the Server for any subsequent communication.

3: The user decrypts the session key. The TGT and the session key are stored in the user’s credential cache. The credentials are used to obtain tickets for each network service the principal wants to access.

4: The requesting client application uses the previously obtained TGT in a dialogue with the TGS to obtain a service ticket to access secured services.

5: The TGS returns a new service ticket that the application client can use to authenticate the service.

6: The application client tries to authenticate to the service on the application server using the service ticket obtained from the TGS. The secure application validates the service ticket using the server’s service key present in the key tab file. Using this service key, the server decrypts the authenticator and verifies the identity of the user. It also verifies that the user’s service ticket has not expired.

7: AS can also return the time stamp the client sent encrypted in the session key at the request of the client.

References

External Links