Incrementing the timestamp by one for bilateral authentication also is not without its problems. A better choice would be to use a challenge-response mechanism. When a Kerberos client wants to verify that a Kerberos server holds the session key, the client should ask the server to generate a random challenge or nonce. The server would encrypt the nonce with the session key and send it to the client. The client responds with some function computed on the nonce, encrypts the result, and returns the value to the server to prove knowledge of the session key. Of course, the client and server must agree on the function (which is “increment by one” in Kerberos V4). A general rule of thumb for mutual authentication is that something in a message should differentiate which side it came from (Kaufman, Perlman, and Speciner, 1995). Either each side should use two different keys (one for sending and one for receiving), or each side should perform a different algorithm when responding to a challenge.

In Kerberos, there is no way to adequately determine whether the first reply from the KDC to klogin is genuine. Therefore, at least a denial-of-service attack can be launched against the login workstation by sending “principal not found” from another node. The hacker succeeds when the forged message arrives at the login workstation before the KDC’s response. This is an example of a race condition. With today’s open network protocols, it would be possible to flood the KDC with network packets to slow its response time. An attacker who knows the secret keys of the principal and the TGS can trick both into using a compromised session key by spoofing the login process.

Finally, weaknesses in the random number generator of Kerberos V4 allowed secret keys to be guessed rather easily in some circumstances (Dole, Lodin, and Spafford, 1997). Clearly, creating a secure, distributed authentication system is difficult. The keepers of Kerberos listened to these criticisms and problems and made many changes in Version 5.

Kerberos Version 5

The core of Kerberos was completely rewritten for Version 5. The goals and overall design remained the same. A third-party KDC was used to generate session keys in the manner already described. However, Version 5 relies on greatly enhanced message formats based on Abstract Syntax Notation 1 (ASN.1). A programmer can use ASN.1 to accurately identify the data type and length of all data values used in a message. This capability improves the integrity of data in Kerberos messages as well as allowing for more options in message formats.

Rather than describe all of the advantages and new features of Kerberos Version 5 here, you are advised to visit the Kerberos ftp site at ftp://athena-dist.mit.edu for papers and copies of the Kerberos documentation. Commercial versions of Kerberos can be obtained from Cygnus (www.cygnus.com), Veritas (www.veritas.com), and Cybersafe (www.cybersafe.com) to name a few.

One important difference between Kerberos V4 and V5 is the way login occurs. In Version 5, the user is required to prove knowledge of the password before the first message is sent by klogin to the KDC. Therefore, without network sniffers to grab the KDC replies, an attacker cannot easily carry out a password-guessing attack. No KDC replies will be encrypted with the user’s secret unless a password has been entered. Instead of entering just the principal name as in V4, the user must enter both the principal name and password before klogin sends the authentication request.

Numerous other improvements can be found including enhancements to the authenticators. Most of the criticisms identified previously are addressed in Kerberos Version 5. For example, the Kerberos V5 authenticator can be a complex data structure for a challenge-response dialog as recommended by Bellovin and Merritt (1992). Kerberos V5 also enables a client program to choose to which network address the ticket is bound, in cases in which the client program is running on hosts with multiple network adapters.

Two other interesting features of V5 tickets are the capabilities to perform ticket forwarding and delegation. A ticket is forwarded if it is obtained at one network address but is to be used by the principal at another network address. The ticket essentially can be passed between network nodes until it is consumed on the appropriate machine. Delegation is an option that allows a second principal to be able to use a ticket on the ticket owner’s behalf. Principal X could obtain a ticket by authenticating to the KDC but request that the ticket be usable by principal Y instead. A number of other ticket qualifiers have been added such as predating a ticket so that it becomes valid on a future date.

One final component of Kerberos V5 deserves mention. Included with this release is a set of programming interfaces that vendors can exploit for application-level encryption. The Generic Security Services API (GSSAPI) has been implemented on top of Kerberos V5 and relies on the DES algorithm for security. GSSAPI includes routines that a vendor can call for providing authenticity, privacy, and message integrity in communications. If a vendor’s product is required to provide secure communications across insecure networks, GSSAPI interfaces are available to deliver the necessary security services. The implementation obviously would require the existence of a Kerberos V5 server to satisfy the calls made to the GSSAPI.

X.509

A digital certificate can be thought of as an electronic passport, which is uniquely used to identify entities in a network. Certificates are most commonly associated with system users, although a certificate could be created for software servers just as Kerberos creates principal secrets for these entities. The most common form of digital certificate is the one defined by the X.509 ISO standard. An entire suite of ISO standards is targeted at providing secure, distributed communications in a network. X.509, which is part of the X.500 series of standards, is concerned with the precise format of digital certificates. This section describes how X.509 certificates provide for significant improvements in I&A for networked environments.