Kerberos

Kerberos is a network-based authentication and access control system designed to support secure access over hostile networks. Kerberos was developed at MIT as part of the Athena project. The Kerberos system was originally intended for Unix-based systems, but it has since been ported to other environments. Microsoft provides a version of Kerberos for Windows networks.

As you have probably figured out by now, the short answer to the question of secure communication on hostile networks is encryption. The long answer is providing a means for protecting the security of the encryption keys. Kerberos offers a methodical process for distributing keys to the communicating hosts and verifying the credentials of a client requesting access to a service.

The Kerberos system uses a server called the Key Distribution Center (KDC) to manage the key distribution process. The Kerberos authentication process results from a relationship of three entities:

  • The client A computer requesting access to a server

  • The server A computer offering a service on the network

  • The KDC A computer designated to provide keys for network communication

The Kerberos authentication process is shown in Figure 20.9. Note that this process presupposes that the KDC already has a shared secret key it can use to communicate with the client and a shared secret key it can use to communicate with the server. These keys are used to encrypt a new session key, which the client and server will use to communicate with each other. The separate keys used by the KDC to encrypt data for the client and server are called long-term keys. The long-term key is typically derived from a secret shared by the KDC and the other computer. Commonly, the client long-term key is derived from a hash of the user's logon password, which is known to both the client and the KDC.

Figure 20.9. The Kerberos authentication process.

graphics/20fig09.gif

The process is as follows. As you read through this process, keep in mind that Kerberos uses conventional (symmetric) encryption rather than public key (asymmetric) encryption. In other words, the same key is used at both ends of each exchange:

  1. The client wants to access a service on Server A. The client sends the KDC a request for access to the service on Server A. (In some cases, the client has already undergone an authentication process and received a separate session key for encrypting communication with the ticket granting service on the KDC.)

  2. The KDC performs the following steps:

    1. The KDC generates a session key that will be used to encrypt communication between the client and Server A.

    2. The KDC creates a session ticket. The session ticket includes a copy of the session key generated in step 2a. The ticket also contains time stamp information and information about the client that is requesting access, such as client security settings.

    3. The KDC encrypts the session ticket using Server A's long-term key.

    4. The KDC bundles the encrypted session ticket, a copy of the session key, and other response parameters for the client and encrypts the whole package using the client's key. The response is then sent to the client.

  3. The client receives the response from the KDC and decrypts it. The client obtains the session key necessary for communicating with Server A. Also included in the package is the session ticket, which is encrypted with the server's long-term key. The client cannot read the session ticket, but it knows it must send the ticket to the server in order to be authenticated. The client creates an authenticator (a string of authentication parameters) and encrypts it with the session key.

  4. The client sends Server A an access request. The request includes the session ticket (encrypted with the server's long-term key) and the authenticator (encrypted with the session key). The authenticator includes the user's name, network address, time stamp information, and so forth.

  5. Server A receives the request. Server A uses its long-term key to decrypt the session ticket (see step 2c). Server A extracts the session key from the session ticket and uses the session key to decrypt the authenticator. Server A verifies that the information in the authenticator matches the information included in the session ticket. If so, access to the service is granted.

  6. As an optional final step, if the client wants to verify the credentials of Server A, Server A encrypts an authenticator with the session key and returns this authenticator to the client.

The Kerberos system is gradually becoming more popular as a means of providing a unified logon system for a network. Kerberos 4 used DES encryption, which, as this hour has already noted, is considered insecure by many encryption experts. Kerberos 5 (described in RFC 1510) supports other encryption types.

By the Way

If you've ever read a description of Kerberos, you probably know the standard description of where Kerberos got its name. In Greek mythology, Kerberos (also called Cerberus) is a three-headed hound that guards the gates of the underworld. The story now is that the three heads are the three elements of the Kerberos authentication process (the client, the server, and the KDC). The original intent for the name, however, is a little murkier. In his book Network Security Essentials (Prentice Hall), William Stallings points out that the Kerberos system was originally intended to guard the gates of the network with the three heads of authentication, accounting, and audit, but the latter two heads (accounting and audit) were never implemented. The security community apparently found it easier to realign the metaphor than to rename the protocol for an equivalent one-headed canine, such as Lassie or Buck the Alaskan sledge dog.




Sams Teach Yourself TCP/IP in 24 Hours
Sams Teach Yourself TCP/IP in 24 Hours (4th Edition)
ISBN: 0672329964
EAN: 2147483647
Year: 2003
Pages: 259
Authors: Joe Casad

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net