[4536] in Kerberos
Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Dan Nessett)
Wed Feb 1 11:36:04 1995
Date: Wed, 1 Feb 1995 08:14:35 -0800
From: Danny.Nessett@Eng.Sun.COM (Dan Nessett)
To: dpg@ocsg.com
Cc: wray@tuxedo.enet.dec.com, cat-ietf@MIT.EDU, kerberos@MIT.EDU
> From war04!dennisg@kerby.ocsg.com Tue Jan 31 19:21:32 1995
> To: danny.nessett@Eng
> Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
> Cc: wray@tuxedo.enet.dec.com, cat-ietf@mit.edu
>
>
> > >> RFC-1510 cites the authenticator's timestamp for this purpose;
> > >> while the mechanism spec replicates some of 1510's syntax to
> > >> comprise a self-contained description of token formats, I don't
> > >> think it's necessary to restate all of the semantics here.
> > >
> > >Using timestamps for replay detection does not work in
> > >multi-threaded environments. Messages can be sent or processed on
> > >the receive side in an order different than that in which their
> > >authenticator's are timestamped. This is especially important in
>
> > >transaction applications in which each request may have a ticket
>
> > >in it.
> >
>
> > I think that's an implementation problem. If you're
> > using timestamps in a threaded environment, then your
> > timestamp generator has to simply ensure that it never
> > issues the same timestamp to two different threads (or to
> > the same thread, come to that). This oughtn't to be too
> > hard to do.
>
> >
>
>
> Kerberos message time stamps are composed of two parts:
> the current time-of-day and "microseconds." These are
> two components used to detect replays. The MIT Kerberos
> library function krb5_us_timeofday() returns
> time-of-day and microseconds, it is a wrapper for
> gettimeofday(). The krb5_us_timeofday() function
> contains a static data structure. If two successive
> calls to gettimeofday() return the same value set then
> the code increments the microseconds. Therefore, no two
> calls to krb5_us_timeofday() will return the same value
> set. It would be easy to add mutex thingys to
> krb5_us_timeofday().
>
>
>
> -dpg
>
>
I'm sorry, I don't think you see the problem. It has nothing whatsoever to do
with the granularity of the clock or issuing the same timestamp to two different
threads. It results from concurrency considerations external to GSSAPI or
the underlying security mechanism code.
Perhaps an example will clarify things. Thread A makes a GSSAPI call (say
init_sec_context() or seal()), receiving in return a token or output message
buffer containing protected timestamp information. Thread B does the same thing.
However, due to concurrency between A and B, B actually sends its token/data
first. Thus, if the packets arrive at the destination in the order in which
they were sent, the packet with the youngest timestamp will be processed first.
When the packet sent by A arrives, its timestamp will be "older" than the
last received and be rejected. This sort of reordering can also happen if
A's packet leaves the source machine first, but the packets get reordered by
the network.
Similarly, on the receive side, even if thread A's packet arrives first, it
is possible with multi-threaded servers that B's packet will be processed first,
leading to the same erroneous rejection of A's packet.
Actually, this is not a GSSAPI problem (as I stated in my previous message),
but rather a problem with the underlying mechanism. Consequently, I am copying
this message to the kerberos discussion list and would recommend we move
any further exploration to that list.
Cheers,
Dan
