Comment by Nextgrid
3 years ago
> Kerberos relies on line of sight to the TGS
Isn't this the same with any SSO provider? The SSO provider must be reachable by the end-user's browser during any authentication operation.
(in case of KB it must be reachable by the target services too, but in a server-to-server environment it's less of an issue)
> Golden Ticket
Isn't this exactly the same to let's say a session cookie of a web-based IdP?
The IdP could apply policies on its backend that bind the cookie to a given IP address, user-agent or other indicators, but can't this also be done for Kerberos tickets using a server-side middleware on every service you wish to access (since KB is internal-only, it shouldn't be that big of a deal)?
> Isn't this the same with any SSO provider?
Yes, but OAuth has one major upside: HTTPS only.
No one wants to create site-to-site VPN networks to flow Kerberos.
Isn't Kerberos explicitly designed to run over untrusted networks and not require any additional transport encryption?
You could argue that the common implementations are large piles of legacy C with questionable memory safety that could open them to exploitation by malicious actors, but that's an implementation detail rather than the protocol itself - and I believe there's at least one (mostly?) memory-safe implementation in Java called Apache Kerby.