The Limitations of the Kerberos Protocol --- Flaws deriving from the Project Athena environment. * Kerberos prior to version 5 was a user-to-server protocol. It could not be used as a host-to-host or user-to-user protocol. * On multi-user machines, session keys are stored in files which can be compromised (used without permission), if access control to the machine is subverted. If I gain root access, I can use somebody else's session key (if it's still available/current) * Keys cannot be stored on /tmp, if it is a remote file system. In that case, they are blatantly sent out over the net (BAD!) * Tickets are bound to IP addresses. What happens with multi-homed machines? What about mobility? Protocol Flaws Replay attacks Supposedly averted by authenticators. They have a very short lifetime (typically 5 minutes). However, it is fairly easy to snoop an authenticator and reuse it within its lifetime. The only solution would be authenticator caching, to allow for replays. That hasn't been implemented easily yet. For TCP, it's very difficult, since servers are normally spawned by the main listener. Only threading would work. For UDP, it would present problems with application-level retransmissions. If the application could reconstruct authenticators for each retransmission, the problem might be obviated. Time Service Kerberos assumes that there exists an underlying authenticated time service that can be used. This is not true however, not to mention that even authenticated time servers could be subverted, off wire (by using a fake radio transmitter, for instance). Instead, challenge/response sounds like a better approach, proving (using a nonce) that each party in fact possesses the session key. UDP would still be hard though (would need to retain state per use). Passwords It's relatively easy to exploit user weaknesses in choosing passwords to make educated guesses. Passwords alone are not a good idea to determine a client's key. Diffie/Hellman could be significantly better. Login spoofing The same problem applies elsewhere as well. However, a good solution for other cases (e.g.,. One Time Passwords) cannot be applied to Kerberos, since an initial request is always encrypted by Kc. Inter-session chosen plaintext attacks Message structure should be revised to prevent known-plaintext attacks. Session keys They shouldn't be multi-session keys. They expose the system to cryptanalysis. Ticket scope Ticket forwarding imposes problems, since it assumes equal levels of trust among all sites participating in the forwarding operation. Furthermore, multi-realm authentication can have problems, especially in routing, since there is not global realm name service. Hardware Design * To perform all key operations (and prevent keys from appearing in hosts' main memories) a Kerberos-aware secure cryptographic box could be used. This should not transmit keys in any way. I should only perform cryptographic operations. * A keystore, a secure storage facility, could be used to maintain key databases, without understanding the protocol. Certain portions of the Kerberos Protocol do not belong there, namely, message encoding (something like ASN.1 or BER should be used instead) and encryption mechanisms (let them be pluggable - the protocol should be correct for any encryption mechanism). Proposed changes: * challenge/response instead of time-based authentication * standard message encoding * don't use passwords at the login. Use a one-way function of the passwords given a random number instead (requires some sort of handheld device to compute that) * separate the encryption layer. * use multi-session keys to provide true session keys * support special-purpose hardware for cryptographic operations and secure storage * do not distribute tickets for users - authenticate initial exchange * support optional extensions, like Diffie/Hellman. An extremely interesting paper!