Nico Williams <n...@cryptonector.com> writes: > Which is why, for a new mechanism, I would much prefer that it support > Kerberos naming. Certainly I don't ever want to see a mechanism use > x.500 style naming again.
Primarily what I'd want in a new mechanism is for it to be a protocol for Kerberos authentication. (Or some other underlying authentication system that we all use instead, although that would be off-topic for this group.) In other words, not generic. I understand why GSSAPI was made generic, but that's not what I want, and I think the security world is starting to realize that being able to negotiate every security property and mechanism is more of a bug than a feature. Right now, it is possible to get into the truly absurd situation where to authenticate a client to a server you use: * HTTP authentication, to negotiate * SPNEGO, to negotiate * GSASPI, to negotiate * Kerberos, to do the actual authentication Something similar happens with SASL. This is three layers of negotiation too many. Even if you can hide or eliminate all of the round trips, you're introducing a lot of conceptual complexity, and while the developer doesn't need to know about any of it if all goes well, all often doesn't go well in the real world and then you have to figure out at what layer everything broke. I understand the need for *a* negotiation layer. I think the error was in accepting additional negotiation layers below that, as opposed to getting out of the generic mode as quickly as possible and start working directly with the true protocol. Essentially everything that I don't like about GSSAPI is a direct consequence of the fact that it's a generic authentication protocol that in theory (although essentially never in practice outside of toys and science experiments) could negotiate a mechanism other than Kerberos. Supporting that generality forces the addition of irreducible complexity to the API. (There is the other problem that all of the effort, hardware support, and optimization work is going into TLS now, and it feels like a huge waste of energy to try to compete with TLS in the secure transport business. But that's a whole different can of worms since TLS is very wedded to X.509 certificates and there are a bunch of very good reasons to not want to use X.509 certificates for client authentication in a lot of situations.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos