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

[Ken Hornstein]

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

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.

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.

--Ken