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

[Chris Hecker]

It has been a long time since I made this evaluation so I don’t remember
the details, but I definitely do all sorts of stuff with ccaches and
keytabs and profiles and threads and static linking and controlling memory
allocations and controlling sockets and file usage and whatnot, it seemed
like GSSAPI would have been a nightmare.  Also, the design of krb5 is
pretty clear, it is lowlevel, but everything is right there, it doesn’t try
to hide much, which I value.

Anyway, if others prefer GSSAPI that’s fine with me, I just wanted speak up
and say there are some of us who like calling krb5 and kadm.

Chris


On Fri, Feb 24, 2023 at 12:43 Nico Williams <nico at cryptonector.com> wrote:

> On Fri, Feb 24, 2023 at 01:50:58PM -0500, Ken Hornstein via Kerberos wrote:
> > >I have said this before on the list and it’s not a very popular thing to
> > >say, but I program to the krb5 public API, and it is a nice and clean
> and
> > >performant and simple and portable and flexible API, and GSSAPI looks
> like
> > >none of those things, it looks like a mess to use (just from looking at
> it
> > >for my needs, I have never programmed with it).  So, I hope there isn’t
> > >some movement to deprecate the lowlevel public krb5 API, because it is
> very
> > >useful for me at least.
>
> If you're just trying to set up a GSS context between a client and a
> server, then GSS is really simple, and much simpler than the krb5 API.
>
> If you have to deal with where credentials are (what ccaches, etc.) or
> acquiring them, then historically you couldn't really do that with GSS,
> bit now with the new gss_acquire_cred_from() and gss_store_cred_into()
> functions you can.
>
> > Dude, you are NOT the only one who feels that way, and I can't even
> > BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
> > no getting around it.  The krb5 API is about 100x simpler (there are
> > more functions, true, but most of the time you only need a handful
> > of them).  I've used both; there's just no comparison.  I understand
> > why the GSSAPI was created and the point of it and I use it when I
> > feel it is appropriate; I understand why it is specified in protocol
> > standards.  But in the service of making it "generic" it ended up being
> > very complicated.  And if you want to have your protocol only require a
> > single round trip, you're stuck either calling the krb5 API directly OR
> > assuming that your GSSAPI mechanism will complete in a single round trip
> > (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
> > which in my mind kind of negates the "g" in GSSAPI.
>
> The krb5 API is a mess too.  And API compatibility between Heimdal and
> MIT isn't complete.
>
> With GSS though, with the new gss_acquire_cred_from() and
> gss_store_cred_into(), I find there's very little need for krb5 APIs.
>
> For example, in a PR to Heimdal I've a GSS-based equivalent of kinit
> that has practically the same functionality as the Heimdal kinit
> command.  The only thing it doesn't have is the ability to let the KDC
> drive prompting, though I think I could do something about that too by
> encoding the necessary information into minor status codes.
>
> > However, one thing is worth mentioning: in my experience the GSSAPI
> > is portable.  The details of the krb5 API are basically tied to the
> > particular Kerberos implementation you're using, and that means you're
> > stuck either with a lot of compatibility code OR you have to compile
> > your preferred Kerberos implementation for your target platform, which
> > presents it's own issues.  If I want a truly portable application then I
> > do use the GSSAPI.
>
> Basically.
>
> Nico
> --
>