On 08/23/2016 10:52 PM, Russ Allbery wrote: > I think modern replay caches may no longer have this collision issue?
At least the MIT krb5 one does not; the authenticator ciphertext (which has a random confounder) is hashed to create a secondary ID. But current replay cache implementations still have other issues, including performance. More importantly, even a hypothetical perfect replay cache implementation provides imperfect protection for a protocol as weak as Negotiate. If a passive attacker can replay a ticket and authenticator in a new channel and have it work, then an active attacker can simply suppress the original channel and use the ticket and authenticator in their own. This attack has higher prerequisites and is less subtle, but it's still a terrible weakness. (In better protocols, a good replay cache implementation can protect against whole-session replays when no acceptor subkey is used. But that protection is very hard to achieve for clustered servers.) TLDR: only use Negotiate auth over HTTPS. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
