The details of the Kerberos authentication exchange are simple, robust, and elegant — although not necessarily intuitive. The Kerberos principal asserts its identity by sending a clear text string to the AS. The AS provides Kerberos with credentials for that principal in answer to that request. However, before sending these credentials to the requesting principal, the AS encrypts them with a secret that is shared between the principal and Kerberos. This shared secret is the principal’s Kerberos password, which is held in encrypted form in the key distribution center’s data base. Once on the principal’s workstation, these credentials are decrypted with a password that the user provides to the Kerberos client. If the principal can decrypt these credentials provided by the AS, the principal can use them. If the principal cannot decrypt these credentials provided by the AS, the principal cannot successfully use them. Thus, the initial authentication of a principal happens on the client workstation — not on the Kerberos security server.

This design has two very important features. First, because the principal asserts its identity using a clear test string and the AS encrypts the principal’s credentials before it sends them back to the principal, authentication requires that no passwords ever be sent over the network — in clear text or encrypted. A wiretapper looking at the Kerberos initialization transaction would only see two messages, both of which are useless to the attacker:

•  A clear text string going from the principal to the KDC, saying “Hello, my name is George.”

•  An incomprehensible (encrypted) text string from the KDC to the principal.

The ticket that the AS sends in response to the client’s assertion of identity does not contain the client’s encrypted password, but the ticket itself is encrypted with it. Therefore, the client workstation can decrypt it using the password that the user types. Consequently, the user’s password only resides on the workstation for the very short period that it takes to decrypt the initial credentials.

Second, because the Kerberos client uses a password that it obtains from the user on his or her own workstation to decrypt the credentials from the AS, another user at another workstation cannot impersonate the legitimate one. Credentials are useless unless they can be decrypted, and the only way to decrypt them is to know the principal’s password.

Kerberos credentials are authenticators called tickets. The authenticator that is exchanged between the principal and the AS in the Kerberos initialization sequence is called a ticket granting ticket (TGT). The TGT is so named because it is used to obtain tickets for various services the principal may wish to access. The TGT simply provides proof in subsequent requests for services without the user having to reauthenticate (e.g., type in the password again). This initial Kerberos exchange is summarized in Exhibit 2.

Exhibit 2.  The Initial Kerberos Exchange

At the conclusion of this initial exchange, the client workstation holds a TGT for the client principal. From this point on, these Kerberos credentials are cached on the user’s workstation. TGTs are used to obtain additional credentials specifically for each server application that the client principal wants to use. These service-specific credentials are called application service tickets, and they are obtained from the aforementioned Kerberos TGS.

Finally, these application service tickets are used by the client principal to authenticate itself to a server principal when it wants to use the Kerberos-authenticated service that a particular server principal is offering. Once activated, the client program transparently handles all other transactions with Kerberos and the application server.

Client principals authenticate themselves to their servers with service tickets that they obtain from the Kerberos TGS on behalf of their user, based on the TGT that was obtained by the user when they initialized Kerberos. This process is summarized in Exhibit 3.

Exhibit 3.  Obtaining an Application Service Ticket from Kerberos

Except for having to run kinit to obtain the initial TGT, enter the Kerberos password, and start the desired application client, Kerberos is transparent from the user’s point of view. It is possible to embed the functions of kinit (getting the TGT from Kerberos) in the workstation’s login sequence such that everything except the entry of the user’s password is transparent. In fact, a smart card or authentication token can be integrated with both Kerberos and the client workstation. In such a scenario, all users have to do is insert their tokens into their workstations. The tight integration of these pieces would allow the authentication sequence and the desired application to be activated automatically. Coupled with good security management of the workstation and the KDC, these basic features provide simple and robust security.

Client principals — be they the client side of applications or such native operating system utilities as UNIX login or telnet — must explicitly call for Kerberos services. In the public domain versions of Kerberos, applications use Kerberos services by calling Kerberos library functions. Some commercial implementations of Kerberos version 5 incorporate the generic security services applications programming interface (GSSAPI) as its standard application programming interface. Digital Equipment Corp. put forth this interface as a standard for security services. The GSSAPI is being considered by the Common Authentication Technology Working Group of the Internet Engineering Task Force as a standard for the Internet community. As outlined in the example of how the Kerberos protocol works, a client would use a sequence of GSSAPI calls to authenticate itself to an application server. Such a sequence of calls using the GSSAPI might look like this:

    gss_acquire_cred

    Obtain Kerberos credentials (i.e., a token, called a ticket).

    gss_init_sec_context

    Initialize the client’s security context loop here, wait for success; then pass
    the Kerberos token (ticket) to the named server and start to consume appli
    cation services.

When incorporated into an existing production environment, Kerberos is not transparent. Each client or application server that wants to use Kerberos services must have calls to those services included in its code. As with any other security-related coding, this “kerberization” must be done based on sound applications design and discipline to ensure that it is done properly.