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

Simo Sorce simo at redhat.com
Mon Feb 27 18:25:08 EST 2023


On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote:
> 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.

Sorry Russ,
I do not know about toys or science experiments, but I have been using
GSSAPI in real HTTP applications to do either NTLM or Krb5 just fine.
And before that in SMB applications (although Samba is more complicated
because of its history).

It is true that is very easy to make applications that work only with
one mechanism, but that's not because it is hard to make application
work with multiple ones. It is mostly due to the fact that application
writers tend to use only one mechanism, and as soon as they can make it
work with their application they call it done and ship it.

Classically the 1 roundtrip vs multiple roundtrips makes all multiple
rountrips mechanism break when the developer used only krb5 as the
mechanism for their application. I think that is fine, the beauty of
code is that it can be changed and fixed as needed.

Incidentally if the GSSAPI had not been too picky about security (I
know ... I know) and had provide a one roundtrip, password based
mechanism, that could establish a secure channel, we would probably
have had a lot more success with GSSAPI, but I digress..

This comes back to the fact GSSAPI tends to be a "better" API than krb5
APIs, not a simpler one. The lack of documentation on *how* to use
GSSAPI and well explained examples is part of the problem, as well as
the older GSSAPI (before the extensions) basically not being complete
on the client side.

In any case my problem with krb5 APIs is that people get that stuff
even more wrong than with GSSAPI.

The way I see it krb5 is a simple sharp edge of an API while GSSAPI is
like the blob, you never quite get the best shape but it has no sharp
edges either and tends to slowly absorb mechanisms if you let it :)

I choose the latter because it ends up being safer than the former, and
at least in the Open Source world, there are a lot more coding hands
than krb5 experts... and I suspect that is true in any other world, so
perhaps that should be the default choice regardless.

The truth is that non-security-savvy developers (the majority) would
just like a generic API, that always work, is simple, is always secure,
and stay out of the way (and has no dependencies, and can be easily
open coded, and...).

Until that holy grail is found I assume we'll always have arguments
about what is better or simpler or ..., and nobody will ever win one,
because what is better depends on the situation and the protocol and
the ecosystem, and the use case and the point of view...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc






More information about the Kerberos mailing list