Kerberos is an underrated and underused authorization protocol.
(Last time I used it) V5 was reasonably safe to use on the open Internet. It integrates well with MacOS, Linux, BSD and other Unix auth systems and also with SSH.
I never really understood why we don't see more of it in "Cloud" models, especially given how decoupled a Kerberos Principal is from the underlying Unix UID.
Rather than using SSH keys everywhere and thus having to manage .authorized_keys files all over an estate, the users can `kinit` in a terminal (even on a stock MacOS) and they're away. The credentials are managed centrally. It has service/user and delegation properties similar to oAuth and friends.
I've not looked at it with a modern and critical cryptographic eye but, for example, there is (configurable) support for not giving out the initial set of tickets (which is encrypted with the user's password) until the client has proven it knows the user's password.
Many browsers (especially on the MS platform, but definitely also Firefox on all platforms as well) can be configured to use the tickets for HTTP authentication (like BASIC or DIGEST, but using a different scheme) at configured domains. Lots of web servers and web apps are easily configurable to put the correct things in the correct environment variables or HTTP headers so integration with random web services is straightforward.
Once you've got SSH and Browsing covered with a single credential, you're well on your way to a really versatile SSO scheme.
>Kerberos is an underrated and underused authorization protocol.
Are you kidding? Every Active Directory deployment uses Kerberos; in the enterprise context, it's probably the most used authentication protocol around.
Kerberos doesn't really scale to the Web at this time. It could, but it would be much better if we could just improve the WebPKI and make a true hierarchical PKI that mirrors the DNS. The latter can be done either by having registries and registrars operate name-constrained (possibly by convention) CAs, or by adopting DANE (DNSSEC Authenticated Network Entities).
What part of Kerberos is currently the scaling limit?
One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Kerberos realms also closely resemble DNS names and discovery can be tied into SRV records and well-known-names.
Kerberos tries really hard to do authentication and rely on other, existing systems for the other bits. If your resolver supports DNNSEC then it'll check your Kerberos-related DNS records as well.
On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Corporations and other entities typically use Active Directory on local domain that's not otherwise used on The Internet. SSH keys are trusted on a per-key basis, so I don't see a great need for it to be tied into the Web/SSL CA systems because trust is established in other ways and it's almost always with an entity that you already know or have a relationship with.
Of course, there's a case for delegation, etc within an organisation, but that's a different problem to delegation in global DNS.
I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
> What part of Kerberos is currently the scaling limit?
Cross-realm trust setup.
> One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Well, no, you could use the WebPKI for SSH, it's just that you wouldn't want to: it's too dangerous. The WebPKI isn't really a PKI as PKIs were intended to be.
What I would say is that we really need to fix the WebPKI problem.
> Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Quite true. This is a key strength of Kerberos.
The trend I'm observing in corporate networks though is towards HTTP for everything, and there, Kerberos just doesn't fit in the way it does in GSS applications. In HTTP the way to use Kerberos is as a bearer token system.
> On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation.
Well, not so much in corporate networks, and certainly I don't need hierarchical authorization on the web so much, though in fact many sites like to use each other for authentication and authorization. E.g., CIs let you authenticate with GitHub/GitLab/... credentials via HTTP redirect-based mechanisms.
This isn't so much about hierarchy as about federation. But that federation is predicated on WebPKI, which isn't-but-should-be-damnit hierarchical.
> I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
Oh boy, tell me about it. I've been involved in half a dozen mergers and acquisitions... Even today, too many systems do "realm-chopping", which re-creates the collision problems that you solve by adopting Kerberos or alike.
> So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
Back to scaling, the problem is that cross-realm trust setup is utterly manual and unsafe. In order to scale to the Web using DNS hierarchy it needs to be made automatic, probably using DNSSEC/DANE, or a proper PKI run by the DNS registries and registrars (besides DNSSEC, which is a PKI, of course).
Of course, if we had a proper PKI, we wouldn't really need Kerberos anyways. The two things, PKI and Needham-Schröder protocols like Kerberos, are duals. But there is a slight semantics different between the two that strongly favors PKI: in PKI any CA can impersonate any entity within its namespace, but one CA cannot MITM protocols like TLS when crossing namespaces (and when using certificates for both, the client and the server), whereas in Kerberos, any KDC in the trust path from client to server can not only impersonate clients in its purview to the server, but also MITM any clients to any servers when that KDC is in the trust path.
Also, constructing a global DNS-based proper Kerberos infrastructure is comparable in difficulty to constructing a global proper PKI. (EDIT: And since we really need a PKI... and the two are duals...)
Lastly, Kerberos has more online infrastructure requirements than PKI, though PKI really needs to be used with short-lived or otherwise fresh certificates in order to avoid the need for online revocation infrastructure. This difference also strongly favors PKI (EDIT: I wrote this favors Kerberos, but I'd meant PKI).
BTW, here's a very simple protocol based on DNSSEC/DANE that looks a lot like TLS 1.3 with the zero rtt option: lookup the server's long-term public ECDH key in DNS (with DNSSEC/DANE), send {client_ephemeral_public_ECDH_key, SNI, E(shared_ECDH_key, client_certificate, validation_chain, signature)} to the server, and expect back {server_ephemeral_public_ECDH_key, MAC(shared_secret, client's message)}. The shared secret in the first message would be based on the client ephemeral and the server's long-term key, while the shared secret in the second would be based on both ephemeral keys and the server's long-term key as well. The client certificate could be signed by a DANE-authenticated CA, and the validation chain could be just the DNSSEC chain. The client certificate could be a key agreement certificate, in which case the signature would be more like a MAC using an agreed key. This might seem familiar to you... it's exactly the same as the good old AUTH_DH/mech_dh from Sun, but with DNSSEC as its publickey database. This scheme has a lot of properties like Kerberos, such as supporting .5 and 1.0 round-trip handshakes!
This is a proposal that we delegate not just domain names, and not just TLS certificates, but authentication for applications themselves to a tree-structured PKIs whose trunks are controlled de jure by world governments.
de jure the sovereign entities that you're labelling "world governments" already control everything, that's sort of the point of being a sovereign entity.
Even to the extent that there are exceptions to the rules they make, they made those exceptions too.
For example, the sovereign entities agreed centuries ago that none of them owns the open oceans but vessels that sail on those oceans shall display the flag of a sovereign entity and the entity thus flagged shall be responsible for that vessel's conduct and operation. This flag state regime proves to be problematic in certain ways in practice.
So what happened? Did some alternate power arise to challenge the sovereign entities in this regard? Nope. The European countries, annoyed by "flags of convenience" on the vessels they saw just arbitrarily instituted a new policy, under the Paris Memorandum Of Understanding. No need to "challenge" any existing rules, as sovereign entities they were entitled to just make up new ones. Vessels entering a European port needed to obey the Paris MOU rules, sometimes getting inspected and if necessary prevented from leaving until they rectified any problems to the port's satisfaction. Was that legal? It was now because sovereign entities had agreed that it was so. The new model was a big success and similar Port State Inspection rules soon followed elsewhere.
u/tptacek has made this argument a lot before. It's a fallacious argument because we can all see that when government X says JUMP, the companies they order either JUMP or EXIT, and when those companies lack an EXIT option, they always JUMP. The reason for this is that no cryptography can beat the rubber hose, and no cryptographic protocol can either.
No PKI, whether loose like WebPKI, rooted like DNSSEC (or as PKI was intended to be), or with multiple roots sharing subtrees (e.g., as DNSSEC would be if, say, Russia decided to require Russians to use Russian roots that happen to sign com and such as they are), can possibly get around the fact that the certification authorities that make it up are subject to the jurisdiction of some government. It's why we all don't want the CN NIC in our trust anchor sets, for example, or only want it if name-constrained.
There is not getting around this. So u/tptacek doesn't trust the DNS root, but so what, why should he trust any WebPKI CA at all, or all of them? Any one of them can be compromised by the end of a gun, and then all who have it in the trust anchors will be compromised too.
Sure, there's CT (certificate transparency), but there is nothing so PKIX-specific to CT that it couldn't be applied to DNSSEC, and anyways, I'm unconvinced that it's enough. There comes a point where certain governments don't even care if they leave evidence of their nasty behavior for all to see -- when push comes to shove, any government with jurisdiction over you can end your happiness and even your life. Oh? The world can see? But what can the world do for, e.g., HK? A big fat not much.
Also, DNSSEC does have one thing PKIX doesn't and can't have: QName minimization. That's where instead of sending the full domainname for any query to the root and all intermediate zones, you only ever ask each zone for its domainname + the next label of the domainname you really want.
Imagine you're a subject of interest to the U.S. government, and they're willing to risk public knowledge of their access to root keys, say, in order to spy on you. And say you're vising some site like antifa.github.io. So you ask . for io, and io for github.io, and github.io for antifa.github.io, and only at the last hop can the LEO/TLA system spying on you decide that yes, they want to MITM you there. So either they have to MITM you everywhere, or they have to MITM you only at zones they can control, and this is a decision they have to make online. That's a big deal. If they decide to MITM you when you asked for io, but you expected this so you had io's public keys, and . tells you different keys, then you've detected the espionage attempt. WebPKI can't do this. By the time some server (or MITM) sees your SNI they've also seen your DNS queries. Even if you're using DoH/DoE (which also gets you similar protection in a DNSSEC world), if the SNI is not encrypted, still, they know what to do. And so on. Let's say you're using DoH/DoE with a resolver the LEO/TLA can't control, then they could simply kick your door in and take your stuff and beat you up. Crypto can make things harder for them, but not infinitely harder. The CCP won't give a damn about leaving evidence in CT logs, for example -- maybe today they do, but when push comes to shove, forget about it.
Your argument is nonsense. There's nothing so special about WebPKI CAs or DNS zone operators. Both -as all entities- are subject to the jurisdiction of some national government in this here world. See my reply to u/tialaramex's reply to you above.
You've written several hundreds words on this thread without apparently reading the 2 lines I wrote to prompt you. Try again. I'm not talking about the WebPKI; your suggestion was far more extreme than having the DNS take over the WebPKI --- which is also not going to happen, but I'm not here to debate that.
Using Kerberos as originally intended, meaning that you exchange AP messages (or GSS-API security context tokens) to authenticate and set up session keys, which you then use for session protection using KRB messages (or GSS-API per-message tokens), then it turns out the vast majority of applications don't even need replay caches. The reason is simple: most application protocols follow up the exchange with data that is not sensitive to replays.
Relatively few application protocols actually use Kerberos as originally intended though. Many SASL apps run over TLS and don't use Kerberos for session protection, for example, in which case you have to make sure that the server certificate PKI is as good as Kerberos (this is not a big deal in corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There are some extensions to do channel binding of Negotiate tokens to TLS, but those are not universally easy to use because of complications to do with reverse proxies and less-than-universal client support.
Anyways the "dialogue" exposition is pretty neat and stands the test of time.
Interesting, this dialogue is from 1988, and since then we’re really re-invented the wheel with JWT, which by my understanding still allows for some forms of MITM and replay attacks, relying heavily on token expiration. Though I suppose the landscape has changed since most connections are now assumed encrypted.
Kerberos as used in HTTP is no different, really, and you get no benefit from having a replay cache in that case (or the vast majority of Kerberos use cases).
Once we're talking HTTP, you really depend on server certificates for security. Attempts to perform "channel binding" or "token binding" in HTTP to alleviate the dependency on server certificates for security have mostly failed due to complexities having to do with reverse proxies and availability of necessary APIs.
Signed JWTs have the benefit of not having to first establish shared secrets with a trusted third party. The relying party need only fetch and cache the JWKs and validate the signatures on incoming JWTs.
SAML, OIDC, and such, sometimes can resemble Kerberos too. Their benefit lies in not needing HTTP clients to have any smarts, whereas "Negotiate" (RFC4559) does. SAML and OIDC accomplish this by relying mainly on redirect chasing by the client, though as a trade-off they get to deal with the problem of open redirectors.
It definitely allows replay attacks. If you manage to get someone's JWT you can impersonate them for a couple of hours before it expires, unless the website has additional identity verification measures like known IP addresses and such. As you say, connections are now all encrypted so the old prank methods of stealing peoples' tokens off university wifi networks won't work anymore. I've definitely seen JWTs show up in logs, though.
"known IP addresses and such" does not work for websites authentication and such. Mobile clients are changing IP all the time as they move between WIFIs and mobile networks.
That's one of the many limitations of kerberos. It's really not intended to work outside of a company intranet.
Uh, u/ahelwer was talking about JWT, not Kerberos.
Kerberos doesn't scale to the Internet as it stands, but used properly it's secure. The problem that u/ahelwer says JWT... Kerberos also has when used in HTTP -- as opposed to other uses of Kerberos that don't have this problem. That problem is that they are used as "bearer tokens" without any "channel binding", so if you use them over HTTP without TLS, you lose to any eavesdroppers, and if you use them over HTTPS using the WebPKI and some CA is being (ab)used to MITM you, then you lose. This isn't specific to JWT (or Kerberos) but generic to all small-b bearer token schemes.
I thought this was talking about JWT not restricting by IP specifically because Kerberos does.
Kerberos has very stringent requirements to onboard and preregister user devices, that works in limited contexts like desktop or server authentication in an intranet. JWT is intended to cover other use cases like web authentication. Their (non) limitations are simply reflections of their use cases.
Yeah a lot of the problems and solutions seem really foreign. Nowadays it seems you could get the same security through:
Connect to auth server over TLS. Exchange password for tickets for all services.
Tickets are signed messages containing (user, service, expiration time).
Connect to service over TLS and present ticket.
(Last time I used it) V5 was reasonably safe to use on the open Internet. It integrates well with MacOS, Linux, BSD and other Unix auth systems and also with SSH.
I never really understood why we don't see more of it in "Cloud" models, especially given how decoupled a Kerberos Principal is from the underlying Unix UID.
Rather than using SSH keys everywhere and thus having to manage .authorized_keys files all over an estate, the users can `kinit` in a terminal (even on a stock MacOS) and they're away. The credentials are managed centrally. It has service/user and delegation properties similar to oAuth and friends.
I've not looked at it with a modern and critical cryptographic eye but, for example, there is (configurable) support for not giving out the initial set of tickets (which is encrypted with the user's password) until the client has proven it knows the user's password.
Many browsers (especially on the MS platform, but definitely also Firefox on all platforms as well) can be configured to use the tickets for HTTP authentication (like BASIC or DIGEST, but using a different scheme) at configured domains. Lots of web servers and web apps are easily configurable to put the correct things in the correct environment variables or HTTP headers so integration with random web services is straightforward.
Once you've got SSH and Browsing covered with a single credential, you're well on your way to a really versatile SSO scheme.
Are you kidding? Every Active Directory deployment uses Kerberos; in the enterprise context, it's probably the most used authentication protocol around.
One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Kerberos realms also closely resemble DNS names and discovery can be tied into SRV records and well-known-names.
Kerberos tries really hard to do authentication and rely on other, existing systems for the other bits. If your resolver supports DNNSEC then it'll check your Kerberos-related DNS records as well.
On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Corporations and other entities typically use Active Directory on local domain that's not otherwise used on The Internet. SSH keys are trusted on a per-key basis, so I don't see a great need for it to be tied into the Web/SSL CA systems because trust is established in other ways and it's almost always with an entity that you already know or have a relationship with.
Of course, there's a case for delegation, etc within an organisation, but that's a different problem to delegation in global DNS.
I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
Cross-realm trust setup.
> One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Well, no, you could use the WebPKI for SSH, it's just that you wouldn't want to: it's too dangerous. The WebPKI isn't really a PKI as PKIs were intended to be.
What I would say is that we really need to fix the WebPKI problem.
> Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Quite true. This is a key strength of Kerberos.
The trend I'm observing in corporate networks though is towards HTTP for everything, and there, Kerberos just doesn't fit in the way it does in GSS applications. In HTTP the way to use Kerberos is as a bearer token system.
> On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation.
Well, not so much in corporate networks, and certainly I don't need hierarchical authorization on the web so much, though in fact many sites like to use each other for authentication and authorization. E.g., CIs let you authenticate with GitHub/GitLab/... credentials via HTTP redirect-based mechanisms.
This isn't so much about hierarchy as about federation. But that federation is predicated on WebPKI, which isn't-but-should-be-damnit hierarchical.
> I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
Oh boy, tell me about it. I've been involved in half a dozen mergers and acquisitions... Even today, too many systems do "realm-chopping", which re-creates the collision problems that you solve by adopting Kerberos or alike.
> So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
Back to scaling, the problem is that cross-realm trust setup is utterly manual and unsafe. In order to scale to the Web using DNS hierarchy it needs to be made automatic, probably using DNSSEC/DANE, or a proper PKI run by the DNS registries and registrars (besides DNSSEC, which is a PKI, of course).
Of course, if we had a proper PKI, we wouldn't really need Kerberos anyways. The two things, PKI and Needham-Schröder protocols like Kerberos, are duals. But there is a slight semantics different between the two that strongly favors PKI: in PKI any CA can impersonate any entity within its namespace, but one CA cannot MITM protocols like TLS when crossing namespaces (and when using certificates for both, the client and the server), whereas in Kerberos, any KDC in the trust path from client to server can not only impersonate clients in its purview to the server, but also MITM any clients to any servers when that KDC is in the trust path.
Also, constructing a global DNS-based proper Kerberos infrastructure is comparable in difficulty to constructing a global proper PKI. (EDIT: And since we really need a PKI... and the two are duals...)
Lastly, Kerberos has more online infrastructure requirements than PKI, though PKI really needs to be used with short-lived or otherwise fresh certificates in order to avoid the need for online revocation infrastructure. This difference also strongly favors PKI (EDIT: I wrote this favors Kerberos, but I'd meant PKI).
BTW, here's a very simple protocol based on DNSSEC/DANE that looks a lot like TLS 1.3 with the zero rtt option: lookup the server's long-term public ECDH key in DNS (with DNSSEC/DANE), send {client_ephemeral_public_ECDH_key, SNI, E(shared_ECDH_key, client_certificate, validation_chain, signature)} to the server, and expect back {server_ephemeral_public_ECDH_key, MAC(shared_secret, client's message)}. The shared secret in the first message would be based on the client ephemeral and the server's long-term key, while the shared secret in the second would be based on both ephemeral keys and the server's long-term key as well. The client certificate could be signed by a DANE-authenticated CA, and the validation chain could be just the DNSSEC chain. The client certificate could be a key agreement certificate, in which case the signature would be more like a MAC using an agreed key. This might seem familiar to you... it's exactly the same as the good old AUTH_DH/mech_dh from Sun, but with DNSSEC as its publickey database. This scheme has a lot of properties like Kerberos, such as supporting .5 and 1.0 round-trip handshakes!
Even to the extent that there are exceptions to the rules they make, they made those exceptions too.
For example, the sovereign entities agreed centuries ago that none of them owns the open oceans but vessels that sail on those oceans shall display the flag of a sovereign entity and the entity thus flagged shall be responsible for that vessel's conduct and operation. This flag state regime proves to be problematic in certain ways in practice.
So what happened? Did some alternate power arise to challenge the sovereign entities in this regard? Nope. The European countries, annoyed by "flags of convenience" on the vessels they saw just arbitrarily instituted a new policy, under the Paris Memorandum Of Understanding. No need to "challenge" any existing rules, as sovereign entities they were entitled to just make up new ones. Vessels entering a European port needed to obey the Paris MOU rules, sometimes getting inspected and if necessary prevented from leaving until they rectified any problems to the port's satisfaction. Was that legal? It was now because sovereign entities had agreed that it was so. The new model was a big success and similar Port State Inspection rules soon followed elsewhere.
No PKI, whether loose like WebPKI, rooted like DNSSEC (or as PKI was intended to be), or with multiple roots sharing subtrees (e.g., as DNSSEC would be if, say, Russia decided to require Russians to use Russian roots that happen to sign com and such as they are), can possibly get around the fact that the certification authorities that make it up are subject to the jurisdiction of some government. It's why we all don't want the CN NIC in our trust anchor sets, for example, or only want it if name-constrained.
There is not getting around this. So u/tptacek doesn't trust the DNS root, but so what, why should he trust any WebPKI CA at all, or all of them? Any one of them can be compromised by the end of a gun, and then all who have it in the trust anchors will be compromised too.
Sure, there's CT (certificate transparency), but there is nothing so PKIX-specific to CT that it couldn't be applied to DNSSEC, and anyways, I'm unconvinced that it's enough. There comes a point where certain governments don't even care if they leave evidence of their nasty behavior for all to see -- when push comes to shove, any government with jurisdiction over you can end your happiness and even your life. Oh? The world can see? But what can the world do for, e.g., HK? A big fat not much.
Imagine you're a subject of interest to the U.S. government, and they're willing to risk public knowledge of their access to root keys, say, in order to spy on you. And say you're vising some site like antifa.github.io. So you ask . for io, and io for github.io, and github.io for antifa.github.io, and only at the last hop can the LEO/TLA system spying on you decide that yes, they want to MITM you there. So either they have to MITM you everywhere, or they have to MITM you only at zones they can control, and this is a decision they have to make online. That's a big deal. If they decide to MITM you when you asked for io, but you expected this so you had io's public keys, and . tells you different keys, then you've detected the espionage attempt. WebPKI can't do this. By the time some server (or MITM) sees your SNI they've also seen your DNS queries. Even if you're using DoH/DoE (which also gets you similar protection in a DNSSEC world), if the SNI is not encrypted, still, they know what to do. And so on. Let's say you're using DoH/DoE with a resolver the LEO/TLA can't control, then they could simply kick your door in and take your stuff and beat you up. Crypto can make things harder for them, but not infinitely harder. The CCP won't give a damn about leaving evidence in CT logs, for example -- maybe today they do, but when push comes to shove, forget about it.
Relatively few application protocols actually use Kerberos as originally intended though. Many SASL apps run over TLS and don't use Kerberos for session protection, for example, in which case you have to make sure that the server certificate PKI is as good as Kerberos (this is not a big deal in corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There are some extensions to do channel binding of Negotiate tokens to TLS, but those are not universally easy to use because of complications to do with reverse proxies and less-than-universal client support.
Anyways the "dialogue" exposition is pretty neat and stands the test of time.
Once we're talking HTTP, you really depend on server certificates for security. Attempts to perform "channel binding" or "token binding" in HTTP to alleviate the dependency on server certificates for security have mostly failed due to complexities having to do with reverse proxies and availability of necessary APIs.
Signed JWTs have the benefit of not having to first establish shared secrets with a trusted third party. The relying party need only fetch and cache the JWKs and validate the signatures on incoming JWTs.
SAML, OIDC, and such, sometimes can resemble Kerberos too. Their benefit lies in not needing HTTP clients to have any smarts, whereas "Negotiate" (RFC4559) does. SAML and OIDC accomplish this by relying mainly on redirect chasing by the client, though as a trade-off they get to deal with the problem of open redirectors.
That's one of the many limitations of kerberos. It's really not intended to work outside of a company intranet.
Kerberos doesn't scale to the Internet as it stands, but used properly it's secure. The problem that u/ahelwer says JWT... Kerberos also has when used in HTTP -- as opposed to other uses of Kerberos that don't have this problem. That problem is that they are used as "bearer tokens" without any "channel binding", so if you use them over HTTP without TLS, you lose to any eavesdroppers, and if you use them over HTTPS using the WebPKI and some CA is being (ab)used to MITM you, then you lose. This isn't specific to JWT (or Kerberos) but generic to all small-b bearer token schemes.
Kerberos has very stringent requirements to onboard and preregister user devices, that works in limited contexts like desktop or server authentication in an intranet. JWT is intended to cover other use cases like web authentication. Their (non) limitations are simply reflections of their use cases.