The application can choose whatever level of protection it deems necessary. The level of security chosen for a particular transaction depends upon the security policy being implemented by the application.

To verify the identities of the principals in a transaction, the client transmits the ticket to the function server. The ticket is sent in cleartext (cleartext is readable by anyone who chooses to look at the message). Parts of it are encrypted, but this encryption doesn’t thwart replay. An attacker could intercept it and reuse it. So, additional information accompanies the message to prove it originated at the principal to whom the ticket was issued. This information, called an authenticator, is encrypted in the session key, and includes a timestamp. The timestamp proves that the message was generated recently and is not a replay. Encrypting the authenticator in the session key proves that a party possessing the session key generated it. Because no one except the requesting principal and the server know the session key (it never travels over the network in the clear), this guarantees the identity of the client.

The integrity of the messages exchanged between principals can be guaranteed using the session key. This approach provides detection both of replay attacks and message stream modification attacks, by generating and transmitting a collision-proof checksum called a hash or digest of the client’s message, keyed with the session key. Checksums are discussed later in this chapter.

Privacy and integrity of the messages exchanged between principals can be secured by using the session key passed in the ticket and contained in the credentials to encrypt the data to be passed.

Authentication exchanges require read-only access to the Kerberos database. Sometimes the entries in the database must be modified, however, such as when adding new principals or changing a principal’s key. Modification of entries is done using a protocol between a client and a third Kerberos server, the Kerberos Administration Server. The administration protocol is not described here. Another protocol concerns maintaining multiple copies of the Kerberos database, but it’s an implementation detail and can vary to support different database technologies.

What Kerberos Doesn’t Do

Kerberos doesn’t solve denial of service attacks. These protocols have places in which an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks, some of which can appear to be common failure modes for the system, usually is best left to the human administrators and users.

Principals must keep their secret keys secret. If an intruder somehow steals a principal’s key, the villain can masquerade as that principal or impersonate any server to the legitimate principal.

Kerberos doesn’t solve password-guessing attacks. If a user chooses a poor password, an attacker can successfully mount an off-line dictionary attack. The attacker attempts to decrypt repeatedly, employing successive entries from a dictionary, messages encrypted under a key derived from the user’s password.

Kerberos is also vulnerable to clock synchronization attacks. Each host on the network must have a clock “loosely synchronized” to the time of the other hosts. This synchronization serves to reduce the bookkeeping needs of application servers when they perform replay detection. The degree of “looseness” can be configured per server. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers.

Principal identifiers should not be recycled. A typical mode of access control uses Access Control Lists to grant permissions to particular principals. An Access Control List is attached to any object that requires restricted access. The list should consist only of principal identifiers, although group identifiers are usually allowed. When a user wants to make use of the object, the operating system checks the Access Control List. If the user is listed as an authorized principal, access is granted. If a stale list entry remains for a deleted principal and the principal identifier is reused, the new principal inherits rights specified in the stale entry. Not reusing principal identifiers erases the danger of inadvertent access. Kerberos does not at this time coordinate or manage Access Control Lists. This entire problem is referred to as object reuse. Any system that wants to be government security certified must control object reuse and prevent it from occurring.