appl/simple/client/sim_client.c uses internal APIs

[Russ Allbery]

Nico Williams <nico at 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 (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>