>> ...huh?  Mine includes a struct timeval, which is actually somewhat
>> stronger than a simple sequence number.
> No, a struct timeval is _not_ stronger than a sequence number.  Any
> time `reasonably' close to the present will be believable when
> presented to you, unless you have very thorough knowledge of the
> exact times of activities on the local and remote machines and of the
> exact clock skew between the two machines. (And the latency between
> them, and... and... and... and...)

And how is that any less true of sequence numbers?

> With timevals from different machines, `match' is a very loose term.
> While sequence numbers, because always incrementing, cannot be
> replayed

I still can't see how sequence numbers would allow me to catch anything
timevals don't.  Can you outline a specific example?

> (and prediction would still require them to know your DES key, unlike
> TCP sequence guessing attacks), timestamps _are_ repeatable.

(En passant, it's not DES that I use for my encrypted tokens.)  I can't
see how timestamps are repeatable unless the attacker can also cause
clockwarps on my machine.  Still, it'd be easy enough to add sequence
numbers; if you come up with that example I asked about above, I'll add
them.

> No, the risk here is not of a malicious foreign admin, per se.  The
> risk is that the foreign admin could himself be duped by someone able
> to inject packets between you.

That's the same as a malicious foreign admin from my point of view; all
either one means is that I have to consider the possibility that the
cookie being handed back to me is from a connection other than the one
the abuse report claims it goes with.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B