[4547] in Kerberos
Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Thu Feb 2 05:57:06 1995
Date: Wed, 1 Feb 1995 08:57:09 -0800
From: Clifford Neuman <bcn@ISI.EDU>
To: Danny.Nessett@eng.sun.com
Cc: dpg@ocsg.com, wray@tuxedo.enet.dec.com, kerberos@MIT.EDU
Date: Wed, 1 Feb 1995 08:14:35 -0800
From: Danny.Nessett@eng.sun.com (Dan Nessett)
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.
Please note that the Kerberos spec DOES NOT say that replay detection
may require monotonically increasing timestamps. It says that
timestamps seen within the allowable window must be remembered and
checked against. Since the verifier determines the size of that
window, the size of the required replay cache can be traded off
against the window size (allowable clock skew). Implementations that
choose to require a monotonically increasing clock are in error.
However, an implementation that adjusted the size of the window based
on knowledge of the last timestamp seen from a particular host, would
be fine.
~ Cliff
