RFC 1510

This document gives an overview and specification of version 5 of the protocol for the Kerberos network authentication system. It is available from the following:

ftp://ftp.isi.edu/in-notes/rfc1510.txt

Much of the information in this chapter is based on RFC 1510, and some portions are directly extracted from the RFC.

Goals of Kerberos

The design of Kerberos has goals in three areas: authentication, authorization, and accounting. In addition, any function that benefits from the secure distribution of encryption keys will benefit.

There is much discussion in the security industry of how particular systems fit into the government-trusted host classification system. Kerberos by itself does not fit into the trust classifications because it does not offer a full security environment. It can, however, be used as a component when building a secure network. Kerberos provides an authentication mechanism and encryption tools that can be used to implement a secure networking environment.

Authentication

Any user can make a claim to an ID. The authentication process tests this claim. During basic authentication, the user is asked to provide a password. During enhanced authentication, the user is asked to use a piece of hardware (a token) assigned to the legitimate owner of that ID. Alternatively, the user can be asked to provide biometric measurements (thumbprints, voiceprints, or retinal scans) to authenticate the claim to that ID.

Kerberos’ goal is to remove authentication from the insecure workstation to a centralized authentication server. This authentication server can be physically secured, and can be controlled to ensure its reliability. This ensures that all users within a Kerberos realm have been authenticated to the same standard or policy.

Authorization

After a user has been authenticated, the application or network service can administrate authorization. It looks at the requested resource or application function and verifies that the owner of the ID has permission to use the resource or perform the application function.

Kerberos’ goal is to provide a trusted authentication of the ID on which a system can base its authorizations.

Accounting and Auditing

The goal of accounting is to support quotas charged against the client (to limit consumption) and/or charges based on consumption. In addition, accounting audits users’ activities to ensure that responsibility for an action can be traced to the initiator of the action. Auditing, for example, can trace the originator of an invoice back to the individual who entered it into the system.

Security of the accounting and auditing system is important. If an intruder is able to modify accounting and auditing information, it is no longer possible to ensure that a user is responsible for his/her actions.

The goal of Kerberos is to permit attachment of an integrated, secure, reliable accounting system.

How Authentication Works

Kerberos performs authentication as a trusted third-party authentication service using shared secret key cryptography.

The authentication process proceeds as follows:

1.  A client sends a request to the authentication server, requesting “credentials” for a given application server (see fig. 9.2 [Message 1]).
These credentials can be directly for an application server or for a Ticket Granting Server.

2.  The authentication server responds with these credentials, encrypted in the client’s key (see fig. 9.2 [Message 2]).
The credentials consist of the following:

•  A “ticket” for the server.

•  A temporary encryption key (called a session key).

3.  If the ticket is for a Ticket Granting Server, the client then requests a ticket for the application server from the Ticket Granting Server (see fig. 9.2 [Message 3]).

4.  The Ticket Granting Server replies with a ticket for the application server (see fig. 9.2 [Message 4]).

5.  The client transmits the ticket (which contains the client’s identity and a copy of the session key, all encrypted in the server’s key) to the application server (see fig. 9.2 [Message 5]).

6.  The session key, now shared by the client and application server, is used to authenticate the client, and can be used to authenticate the server (see fig. 9.2 [Message 6]).
It also can be used to encrypt further communication between the two parties or to exchange a separate subsession key to encrypt further communication.

Figure 9.2  Kerberos authentication protocol.

An implementation consists of one or more authentication servers running on physically secure hosts. Each authentication server maintains a database of principals (that is, users and servers) and their secret keys. Code libraries on the server provide encryption and implement the Kerberos protocol. Before a typical network can add authentication to its transactions, it adds calls to the Kerberos library, which results in the transmission of the necessary messages to achieve authentication.

A client can use two methods for asking a Kerberos server for credentials:

•  Client sends a cleartext request for a ticket for the desired function server to the function server. The reply is sent encrypted in the client’s secret key. Usually, this request is for a Ticket Granting Ticket that can be used later with the Ticket Granting Server.

•  Client sends a request to the Ticket Granting Server in the same manner as when contacting any other application server that requires Kerberos credentials. The reply is encrypted in the session key from the Ticket Granting Ticket.

After credentials are obtained, they can be used to establish the level of security the application requests:

•  Verify the identity of the principals in a transaction

•  Ensure the integrity of messages exchanged between them

•  Preserve privacy of the messages