Benefits of Kerberos

Notice a couple of the security features provided by Kerberos. No passwords are shared between any of the principals. Only the KDC knows the hashed password values for the principals. The KDC additionally encrypts the hashed password database to strengthen security. A different shared session key is used when X communicates with the TGS than when exchanging messages with Y. Similarly, if X were to initiate sessions with other principals, the shared session keys would be random and different. Assuming that the technique used to generate random session keys is sound, it is computationally infeasible for an adversary to guess a session key.

Identities are verified by showing knowledge of a shared secret without divulging the secret itself in the clear over the network. Both X and Y possess the same shared secret distributed by the trusted KDC server. Cryptography and checksums are used to protect the integrity of the tickets. Thus, an attacker cannot attempt to modify a ticket in transit to trick one of the principals into using the wrong session key. Although the improvement beyond standard UNIX or NT login authentication is not that significant with Kerberos, the features it provides for secure communications between principals in a distributed network are substantial.

Complaints and Attacks against Kerberos

One of the chief reasons for analyzing Kerberos in detail is that many of the topics discussed in the remainder of this book require authentication protocol exchanges between two or more entities in a network. Kerberos is really a simple system to learn first. Many more complex cases and environments need to be considered. Knowing problems with distributed protocols can help you avoid costly mistakes. To see how intricate distributed authentication protocols can be, consider some of the following arguments against Kerberos (Bellovin and Merritt, 1991; Kaufmann, Perlman, and Speciner, 1995).

•  Each software component must be modified to work with Kerberos. If you want to use only Kerberos to improve login security for your UNIX or NT box, you are getting more than you need. Kerberos is designed for much broader tasks than this.

•  File systems such as the Andrew File System (AFS) have been built around the Kerberos protocol. However, Kerberos itself does not provide access control or authorization services. Of course, it was never intended to provide this feature.

•  Systems in a Kerberos network require synchronized time clocks. Secure distributed time services are thus a prerequisite for Kerberos to operate properly.

•  You should be able to easily see how a Kerberos user principal can enter a password to authenticate to the KDC. Kerberos was designed to provide trusted third-party authentication for other principals, such as software servers and workstations. For these inanimate principals to prove their identity to the KDC, the principal’s password must be stored on disk in the /etc/srvtab file. This file could be compromised if the system is attacked.

•  On multiuser systems, principals’ tickets are stored in a temporary directory that can be read by any user. This information could be useful to a hacker for offline password cracking.

•  Kerberos relies on the User Datagram Protocol (UDP), which is often blocked at the firewall. As such, it is difficult to run Kerberos between sites protected by a firewall.

•  Kerberos V4 binds tickets to a single network address for a workstation or server. Thus, a system with multiple network adapters will have problems using tickets.

A few problems with the protocols described in the preceding list also affect Kerberos V4. The most often lamented feature is the login protocol.

Remember from previous comments that klogin will send an initial request to the KDC containing the principal’s name and some other values. If the principal name is valid, the KDC sends a reply encrypted with the secret of the principal. Because the initial request information is transmitted in the clear, and the Kerberos code is freely available, an adversary who knows the names of principals can send this initial request and obtain the encrypted reply. This reply then can be used as input for an offline password cracking attempt. If the decrypted reply contains the string krbtgt, the attacker has uncovered the principal’s password. Someone using a network sniffer also can capture the entire initial request packet containing the principal name and current time to further validate decryption. Principal names also can be obtained through techniques such as social engineering, network sniffing, or electronic mail. Once again, the system is only as strong as the reusable passwords chosen by users.

Kerberos V4 also suffers from a bug that allows one to perform offline password cracking even if the name of a principal is not known (l0pht 1997). If the KDC receives an improper UDP packet, it will return an error containing the name of the last principal to request a TGT along with the realm name. To acquire a list of principal names just repeatedly query the server with incorrect UDP packets and store the resulting messages. These names can be used to attack the system as described previously.

If the AS is not configured to limit online password guessing attempts, you can try password cracking interactively. Should this approach fail due to limits on failed login attempts, the attacker can always turn the hack into a denial-of-service attack by sequentially locking out all principals.

Some characteristics of Kerberos have not been discussed in detail. For example, Kerberos servers in different realms can establish trust relationships and perform cross authentication services. Because the cooperating KDCs cannot dynamically enter a password as a user might, cross-realm authentication relies on the stored secret problem already identified.

Another problem with Kerberos lies in the authenticator. Bellovin and Merritt (1991) describe how an attacker might be able to use an authenticator in a replay attack. Also, any successful attempts to alter the allowable time skew between nodes opens up possibilities for authenticator replay attacks. Previously expired authenticators could be used again.