[charlieok]

Kerberos fits your description ("protocols designed for enterprise desktops") exactly. The hardest thing I've found about running it across a hostile internet is dealing with NAT issues. The (latest version of the) protocol itself is pretty decent from a security perspective.

Then again, the original version of it, when it was designed for enterprise desktops, would not be particularly effective.

[marshray]

Actually, Kerberos was designed at MIT for the explicit scenario of an untrusted network: "I'm OK, you're OK, the network is hostile".

It may work acceptably for VPN-like applications, but how does it work for actual internet applications? E.g., how do you enroll new clients into the authentication realm over the internet?

[charlieok]

Yes, it was designed for an untrusted network. But, there are good reasons why older versions of the protocol are not trustworthy today, which go beyond the increase in computer power relative to the key space [1].

The problem with enrollment is more or less the same as the problem with enrollment using any other crypto trust scheme. In the most secure situation, you'll want to start the process in person.

In practice, with kerberos you have to trust the KDCs holding your keys. With asymmetric systems, you have to trust the CAs who have signed the keys of the parties you are communicating with.

I agree that it isn't a good solution for what we might call "web scale" applications. It is a reasonable way to do password authentication, but federated authentication would require establishing cross-realm trust between identity providers and relying parties.

[1] http://web.mit.edu/kerberos/krb4-end-of-life.html