As long as you rely on a third party, „Trent“, as the article above mentions, he becomes the equivalent of a CA meaning you still have a centralized system in the same way as with a PKI infrastructure. The main point of Kerberos is that it works on the basis of tickets to allow nodes communicating over a non-secure network. Meaning you can have short-lived and strongly secure communication sessions over a „non-secure“ network without worrying about eavesdropping and reply attacks. PKI-doesn’t do that as it’s not a protocol for session authenticating. PKI is a framework used for managing public-key encryption. In that regard, it’s unfair to compare them. It would be much better to compare Kerberos with mTLS as both are protocols for authentication and secure communication. You can also compare Kerberos with the OAuth2 assertion framework defined in rfc7521 The way OAuh2 assertions are used, Kerberos has a clear advantage as most Identity providers don‘t use the OAuth2 private key jwt assertion which gives similar integrity guarantees as Kerberos. This is what exposes the clear advantage of Kerberos as you can, if implementing it correctly, Provide the same level of integrity during communication.
With „OAuth2 private key jwt assertion“ there is the challenge of initially providing the private key to the Identity server and rotating that key at regular intervals. Most systems do not provide a good solution for rotation. PKI, therefore, ends up being considered a black art within secure software development. However, Kerberos also have the exact same challenge. The solution that Kerberos provides for solving this is…(holding for dramatic pause)
You guessed it, it’s PKI, and it still rocks!!
https://en.m.wikipedia.org/wiki/Kerberos_(protocol)#cite_note-rfc4556-1
