Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

[Greg Hudson]

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.