[2900] in Kerberos
Re: Replay caches
daemon@ATHENA.MIT.EDU (Tony Lill)
Wed Nov 17 12:10:12 1993
To: lunt@ctt.bellcore.com
Cc: Tony.Lill@riipsdev.waterloo.NCR.COM, kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 08 Nov 93 12:40:48 EST."
Date: Tue, 16 Nov 93 18:09:01 -0500
From: Tony Lill <ajlill@riipsdev.waterloo.NCR.COM>
>>>>> On Mon, 8 Nov 1993 12:40:48 -0500, Steve Lunt <lunt@ctt.bellcore.com> said:
Steve> Perhaps for now you could force the client to get another service
Steve> ticket with the TGT (rather than use the one in the ticket cache).
Steve> -- Steve
From my reading of the krb5_mk_req_ext code, at about line 141, it
calls generate_authenticator to create a new authent structure on each
call, so it would seem that where the ticket came from is irrelevent.
Or is this not the same structure passed to krb5_auth_to_rep in
krb5_rd_req_decoded?
My problem is that with more that one identical processes starting at
once (especially on a multiprocessor) multiple processes can be
calling generate_authenticator with the same server/client pair during
the same timeslice, and since the cmp function in rc_dfl.c only
uses client, server, ctime, and cusec to distinguish between requests,
I'm toast.
If no-one objects, and if it hasn't been changed in Beta 3, I'll
modify the replay cache code to handle this situation, and pass the
diffs back.
Tony> ----- Begin Included Message -----
Tony> I just had a spot of bother using sendauth/recvauth and replay caches.
Tony> I'm using Kerberos V, Beta 2, and I have a kerberized program that
Tony> spawns a bunch of processes that all try to connect to this one
Tony> service. What happens is that sometimes two off these processes run
Tony> sendauth close enough together that the server claims that one of the
Tony> requests is a reply.
Tony> Looking at the replay cache, it only checks the server, client, ctime
Tony> and cusec. This means that with the current code, two requests have to
Tony> be somehow spaced by at least the value of a clock tick to avoid this.
Tony> I don't think that this is entirely reasonable.
Tony> A better solution might be to include some other bit on info in the
Tony> data used in the replay cache. Perhaps the sequence number. That way
Tony> in systems like mine this can be avoided.
Tony> For the present, I've just put in a sleep and retry to get around
Tony> this.
