>> And how is that any less true of sequence numbers?
> You don't _know_ that a given timestamp won't occur in two identd
> cookies.

Conceded, for what it's worth, and I will be adding sequence numbers to
my identd soon (I still think they're borderline useless, but you've
raised enough doubt for me to add them).  I don't think it's as great a
weakness as you seem to think it is - or, alternatively phrased, I
think that sequence numbers are weaker than you do.

> You would know that the same sequence number would not appear again.
> Thus you would have better replay protection than you currently have.

Only if I get the same cookie returned to me for two different
incidents, which I can already detect approximately as well in
practice.

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

> Sure.  I contact your identd and get a cookie for a user currently
> logged in.  I then inject that cookie into a forged response to an
> identd query generated in response to a forged packet used to attack
> a remote machine.

> You can't really say that that identd cookie isn't real.

Of course not, because it is real.  For a different connection, but
still a perfectly legitimate cookie.

> You know what time _by his clock_ he was attacked.  You know what
> time is in the cookie.  The fact that that same time was in another
> cookie does not show you that that cookie was forged.

But the same time _isn't_ in another cookie, just in another copy of
the same cookie - and the same would be true of serial numbers.  Unless
your scenario description is incomplete.

> If you ever see the same sequence number in two cookies, you at least
> _know_ that one of them is forged.

I'm not worried about forged cookies; that is approximately as
difficult as breaking the crypto I use to sign them.  Only replaying
entire cookies is sufficiently feasible for me to be concerned about
it, and that I can't see any way sequence numbers really help.

As I see it, the scenario goes something like this:

My machine A, my user UA; attacked machine B.  Attacker M, able to
sniff and inject packets between A and B.

UA connects to port PB on B from port PA on A.  M sniffs identd cookie
C containing timestamp T and sequence number S, [PB/B/PA/A/T/S].
Later, M forges another connection from [PB/B] to [PA/A] and injects C
into the identd check from B and proceeds to do something nefarious on
the connection.  B's admin contacts me and gives me C.

How does having S in the cookie help?  In principle, I suppose it is
conceivable that two connections with identical endpoint info occurred
within the same clock tick on an OS that doesn't provide sub-tick
resolution, or that my clock warped and just happened to duplicate a
previous timeval, in which cases it is possible to have two
legitimately issued tokens containing the same info.  The chance is
small enough that I'm not worried about it in practice, but it's what I
will be adding sequence numbers to prevent.

In any case, how does this differ, from my point of view, from B's
admin falsely claiming the attack occurred when it didn't, or when the
attack did occur but came from some other [PB/B/PA/A] connection?

> Fact is, when presented with an identd cookie by a remote admin you
> know and tend to trust, you will tend to believe what the cookie
> says.

Certainly.  It's a tendency I need to be aware of and allow for when
using identd info.

/~\ 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