[39186] in Kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Feb 24 14:54:27 2023
From: Sam Hartman <hartmans@debian.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Simo Sorce <simo@redhat.com>, kerberos@mit.edu
In-Reply-To: <878rgmn9s1.fsf@oldenburg.str.redhat.com>
Date: Fri, 24 Feb 2023 19:49:33 +0000
Message-ID: <0100018684f943fb-fd5586cf-aa4e-4202-9a7b-47839a11b3e4-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
>>>>> "Florian" == Florian Weimer <fweimer@redhat.com> writes:
Florian> The Perl translation is here:
Florian> <https://metacpan.org/release/IOANR/Authen-Krb5-1.905/source/eg/simple_client>
Florian> It's not an exact tranlation of the C because it creates a
Florian> replay cache:
Yeah, but it doesn't look like it *does* anything with the replay cache.
It looks like rdata_out mis passed as NULL in the call to krb5_mk_priv
from Krb5.xs's mk_priv all the time.
I don't think that a replay cache will ever be used on the client by
that code.
So I think you can simply remove the calls to the APIs that are
internal; they may create an empty replay cache file, but I do not think
that they add anything to the security of the code.
On the server side, you do need a replay cache, and if you call rd_priv
on the client without sequence number support you need a replay cache.
But I'm fairly sure rd_req will do that for you generally.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
