Limitations of the Kerberos Protocol S.M. Bellovin, and M. Merritt Summary ------- This paper discusses limitations and weaknesses in the Kerberos Protocol. It categorizes these problems into weaknesses in the protocol design, limitations stemming from assumptions about the environment Kerberos will be used in, and problems that cannot be solved without special-purpose hardware. Some of these problems are already solved in Kerberos 5. For other problems, they suggest improvements to the protocol. Main Points ----------- Environment problems: * Kerberos is designed to be used in an environment where users in front of single-user workstations are communicating with servers. -> It is not a peer-to-peer system, for daemons to authenticate to each other. A key stored on a machine for use by a daemon cannot be stored securely, and may be stolen. -> It has weaknesses when using multi-user machines. Cached keys of a user are accessible to attckers logged in at the same time. -> Minor flaw: where to store cached keys? We don't want them on disk (especially if the disk is a remote file server!), and we can't always guarantee that memory won't be paged out to disk. -> Minor flaw: Kerberos tickets are bound to IP addresses, but some machines have multiple IP addresses. [fixed in V.5] Protocol problems: * Time-stamped authenticators -> The authenticator relies on a timestamp to guard agains reuse. Though the timestamp has a short lifetime (~5 minutes), it is possible for a prepared intruder to mount an attack within this period. Servers can cache authenticators to detect their reuse, but this is very difficult to implement within multi-threaded servers. -> Kerberos relies on roughly synchronized clocks, but many time synchronization protocols are not secure. SOLUTION: the paper proposes using a challenge/response authentication method. After a client initiates a communication, the server would respond with a challenge encrypted with the session key. The client would have to really have the session key in order to respond. COST: extra messages in handshake. Requires retained state to implement challenge/response. * Password guessing attacks -> When a user requests a ticket-granting ticket, the answer is encrypted in a key derived from a password. Anyone who snoops this message can mount a brute-force password-guessing attack on it. SOLUTION: Use exponential key exchange, where client/server exchange numbers that are used to compute a secret key. COSTS: Exchanging large numbers to compute key is expensive (small numbers are not secure). ADDITIONAL SUGGESTION: limit rate of ticket-granting tickets sent to a single source. Another possibility is a protocol based on public/private key cryptography (but P/P key has been rejected for Kerberos). * Spoofing Login -> The use of Kerberos precludes using one-time passwords, or challenge/response dialog with user at log-in time. SOLUTION: alter protocol to allow use of hand-held authenticators. Server sends R (in cleartext) to log-in program, and encrypts session key with key={R}KC. The log-in program displays R to user, who uses handheld to generate {R}KC. The password is never given to the log-in program OBJECTION #1: handheld authenticators are inconvenient OBJECTION #2: If you don't trust workstation w/your password, why do you trust it with your session key, or your data? * Session Keys -> The "session-key" in Kerberos is really a multi-session key. SOLUTION: The paper suggests renaming it to be a multi-session key, and using it to generate a true session-key. This limits the exposure to replay attacks from old sessions, and to discovery of a session key. * Chosen Plaintext attacks/Message Encoding/Encryption layer -> The KRB-PRIV encryption format is susceptible to a chosen plaintext attack. The cipher-block chaining used has the property that the prefix of an encrypted message are encryptions of prefixes. This means it is often possible to get a server (such as a mail server or file server) to encrypt your data for you... -> if a message is ambiguous, and is reusable in multiple contexts, it gives an opportunity for a replay attack. -> the inclusion of encryption protocol details in Kerberos protocol makes it more difficult to validate both the encryption protocol and the Kerberos protocols. SOLUTION: Use random initial vectors, block chaining, and message authentication codes to prevent these attacks. BUT, also separate these solutions into a separate encryption layer, and don't include this as part of the Kerberos protocol. ALSO: The paper suggests an analysis method for protocols: Allow an adversary to have a server encrypt anything the adversary wants. After doing this, the adversary should not be able to generate any encrypted text that was not explicitly encrypted by the server. Problems solvable with special hardware: -> Plaintext key storage is the main problem with using Kerberos on multi-user machines. A special purpose hardware box, attached to workstations, would be able to securely store keys. SOLUTION: An encryption box that speaks the Kerberos protocols could securely store keys. Client keys would still be exposed while the user sends information to the box, but at least exposure is limited. OBJECTION: encryption box is controlled by host computer. If a host is compromised, it can make the box create bogus tickets. However, the host could not get the keys themselves, and presumably, a compromise of the host would only be a temporary compromise.