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

[Nico Williams]

On Fri, Feb 24, 2023 at 05:57:22PM -0500, Ken Hornstein via Kerberos wrote:
> I can't argue your preference, and I'll be the first to admit that
> "simpler" can be subjective (although I would argue one metric, "lines
> of code", the krb5 API would win).  But let me point out a few things:

Of course.  Preferences are personal.

> - I alluded to this on the kitten list (and I know you replied there
>   but I didn't get to reply to it yet), but the issue of multiple round
>   trips is a concern.  You point out that even with SPNEGO you should
>   have a single round trip most of the time and that's a fair point,
>   but this puts you in a tough spot with the usage of GSS; you have to
>   assume your GSS mechanism is a single-trip and violate the API OR
>   complicate your protocol and implementation design and presume an
>   unspecified number of round trips.  At least with the krb5 API you can
>   definitively design the protocol (and implementation) for a single
>   round trip.

If you have a mechanism that could use 3 round trips, GSS can't take
fewer.

SPNEGO (which isn't GSS itself) could have been designed so that the
initiator tries N mechanisms in parallel rather than in sequence.  I
suppose we could probably find a way to shoehorn that in.

> - I don't want to crap over the work Ben did on RFC 7546, but I couldn't
>   help noticing that he skipped over the vital work of extracting out
>   a useful error message out of the GSSAPI; that code alone is always
>   a mess but you'd need it anything you'd use in production.

I grant that gss_display_status() is a terrible API.  It's easy to
cargo-cult a wrapper around it though (and we should standardize one).

> >GSS does have some ugly things, mainly OIDs, but also not having
> >something like a krb5_context.  Regarding not having a krb5_context,
> >I've played with a couple of ways to fix that in Heimdal: either a)
> >enhancing the `OM_uint32 *minor_status` to be a more complex, opaque
> >object, or b) adding configuration key/value parameters to the
> >`cred_store` used in `gss_acquire_cred_from()`.
> 
> I was under the impression the "context_handle" served that purpose,
> although I realize not everything takes that as an argument.  If it
> doesn't serve that purpose then I understand the GSSAPI even less than I
> thought :-/

gss_ctx_id_t is the equivalent of krb5_auth_context, not of
krb5_context.  The word "context" here serves to confuse :(

> I recognize that the issue of krb5 API vs GSS is something that we're
> just never going to agree on.

If ever we do replace Kerberos then you might have no choice but to deal
with GSS or make krb5 APIs support the new thing.  But part of the point
of a new thing is to be simpler for implementors, while implementing a
new and old thing with the same API generally isn't simpler for them.

Nico
--