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

[Nico Williams]

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote:
> 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.)

I'd settle for a new mechanism that can handle Kerberos naming.  I don't
care if there's a KDC or a CA or both or whatever other kind of trusted
third party, and if it has a non-trusted-third-party mode, etc.  Just
the naming is enough for me because that's what I've to be compatible
with.  Specifically: a) user at REALM style naming (user at domain might do,
with case insensitive domains so upcasing is safe), b)
service/hostname[@REALM] style service naming.

Certainly an API for such a mechanism only could be simpler than both,
krb5 and GSS.

If you want an example of what I object to in the krb5 API: everything
to do with krb5_cred and everything to do with krb5_auth_context --
those APIs are rather complicated and require developer understanding of
a myriad options that shouldn't be.

> 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.

At $WORK we've built bridging of all the auth methods for this sort of
reason.  Getting every app to use ${preferred_mechanism} turns out to be
impossible.  Bridging all the authentication infrastructures, OTOH, is
possible.

> 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

For HTTP you can just use Negotiate w/o SPNEGO.  Just because it's
called Negotiate doesn't mean you must use SPNEGO.  Negotiate is a
misnomer.

> Something similar happens with SASL.  This is three layers of negotiation
> too many.  [...]
> 
> 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.

We've recognized that multi-layer negotiation is broken since at least
2004 or earlier, and we've studiously avoided it.  SASL/GS1 and SASL/GS2
specifically forbid use of SPNEGO, and so does SSHv2, for this reason.

I'm not aware of any Internet protocol, or even any proprietary
application, that can end up doing multiple layers of negotiation.

(I'm not counting algorithm negotiation within a mechanism as a distinct
negotiation layer, mind you, because the topic is negotiation of
mechanisms, not of mechanism-specific details.)

> 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.

The Solaris/Illumos mech glue and SPNEGO implementation was in fact
truly generic.  I got ssh/sshd to work with both, mech_krb5 and mech_dh
w/ zero mechanism-specific code in ssh/sshd, and that was more than 15
years ago.  Granted, mech_dh was practically obsolete, but we could have
tried to revive it, and I still think that a variation on mech_dh would
be a good foundation for a replacement for Kerberos.

Specifically my idea is to take JWT, enrich it with a standard
fetch-a-rock protocol for it (like the TGS protocol is for Kerberos),
enrich JWT tokens with client ECDH public keys, enrich the system with a
lookup service for service ECDH public keys (either in the fetch-a-rock
protocol or using DNS a la DANE), enrich JWT w/ Kerberos-style [public]
authz data, and enrich JWT tokens with Kerberos style naming support.

The result should be a) compatible with JWT, b) mech_dh-like in
mechanics, c) compatible with Kerberos style naming and authz data, but
it wouldn't be Kerberos as it is today.  Part of the idea is to make it
much easier to implement.

> (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.)

The only problem I have with x.509 is x.500 naming and the paucity of
support for SAN-based authorization of _clients_.  Otherwise I just
don't mind the use of x.509.  But I might be biased because the biggest
problem many people have with x.509 is ASN.1/DER, but I maintain
Heimdal's ASN.1 compiler and that frees me to worry about other things.

I especially dislike OpenSSH-style certificates.  Their whole approach
being to not use DER (ok) but then for what are effectively "extensions"
and constraints they use text format fields that separate items with
commas.  What the heck!  And not having certificate chains == simpler
only for home networks, but way more complex for corporate networks.

Nico
--