-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 28 Mar 2002, der Mouse wrote:

>>> ...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?

You don't _know_ that a given timestamp won't occur in two identd
cookies.  You would know that the same sequence number would not appear
again.  Thus you would have better replay protection than you currently
have.

>> 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?

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.  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.

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

>> (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.

The point is not to add sequence numbers per se.  The _type_ of
authentication being done here is not particularly useful.  Another type
would be better...

>> 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.

No, with forged packets, it _could_ be from the bad connection, and have
been legitimately provided to the remote admin.

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.  And
your belief will be misplaced.

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8o2l5N71lEcOYcw4RAh8fAJoCYzvxdZ6SqS3ew40KGKatjhqG4gCfcS+A
7jnpI2IfEOXrXqq09760MRs=
=WPdb
-----END PGP SIGNATURE-----