[39199] in Kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Feb 24 19:33:16 2023
From: Sam Hartman <hartmans@suchdamage.org>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, kerberos@mit.edu
In-Reply-To: <202302242257.31OMvNSg005422@hedwig.cmf.nrl.navy.mil>
Date: Fri, 24 Feb 2023 23:23:39 +0000
Message-ID: <0100018685bd4637-737d6155-2773-4849-b7f1-7c00a4e20982-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>>>>> "Ken" == Ken Hornstein via Kerberos <kerberos@mit.edu> writes:
Ken> I can't argue your preference, and I'll be the first to admit
Ken> that "simpler" can be subjective (although I would argue one
Ken> metric, "lines of code", the krb5 API would win). But let me
Ken> point out a few things:
Ken> - I alluded to this on the kitten list (and I know you replied
Ken> there but I didn't get to reply to it yet), but the issue of
Ken> multiple round trips is a concern. You point out that even
Ken> with SPNEGO you should have a single round trip most of the
Ken> time and that's a fair point, but this puts you in a tough spot
Ken> with the usage of GSS; you have to assume your GSS mechanism is
Ken> a single-trip and violate the API OR complicate your protocol
Ken> and implementation design and presume an unspecified number of
Ken> round trips. At least with the krb5 API you can definitively
Ken> design the protocol (and implementation) for a single round
Ken> trip.
As an alternative to the krb5 api, stick in the krb5 mechanism oid.
You can definitively design your protocol and implementation for a
single round trip by doing that.
You can have more code in common with applications that do support
multi-round-trip negotiations, while still getting your half or one
round trip.
--Sam
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
