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

[Ken Hornstein]

>If you're using SPNEGO then you don't have to concern yourself with
>negotiation.  If you're implementing SSHv2 or SASL it's another story,
>though not much more complicated because you're doing negotiation at a
>layer that already does it and all you have to do is maybe pick a GSS
>mechanism.
>
>RFC 7546 exists.
>
>I've written a fair amount of app code using krb5 and GSS APIs, and I
>strongly prefer GSS code.

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:

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

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

>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 :-/

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

--Ken