Comment by nullindividual
3 years ago
Kerberos relies on line of sight to the TGS. In the '90s and '00s, this was common place. As of COVID, less so.
Kerberos is also difficult to administer and secure (Golden Ticket?). Kerberos also requires the target service be a member of the Kerberos Realm (or otherwise trusted) which again means line of sight between the service and TGS or Realm to Realm.
And then we get into the whole ticket size issue.
Kerberos is not a good candidate for web-based AuthN.
> 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.