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

On Thu, 28 Mar 2002, der Mouse wrote:

>>>> [...identd...]
>>> More seriously, I can certainly say that I as a sysadmin would never
>>> consider running a multiuser system connected to the net without an
>>> identd.  [...]
>> identd, even in -C mode does _not_ provide anything resembling
>> security.  As it does not encrypt any form of sequence number,
>
>...huh?  Mine includes a struct timeval, which is actually somewhat
>stronger than a simple sequence number.
>
>It's not _my_ fault if _your_ identd doesn't include timestamps,
>sequence numbers, or whatever else you think is missing.  Nor is it the
>protocol's fault.  When I said "an identd", I didn't necessarily mean
>any particular identd - though I wouldn't run one weaker than mine.

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

>> any user with the ability to inject packets anywhere between client
>> and server can inject a packet with the same source port and ip as
>> _was once used in the past_ by one of your users, and then inject the
>> token _used at that time in the past_ in an ident response.
>
>> And you're now _worse_ off than if you weren't using identd, because
>> a user can still spoof one of your users, but now you mistakenly
>> believe you have a secure system implicating that user.
>
>...except that the timestamp in the token won't match the time at which
>the alleged abuse took place.  This also prevents replay attacks by
>malicious foreign admins.

With timevals from different machines, `match' is a very loose term.
While sequence numbers, because always incrementing, cannot be replayed
(and prediction would still require them to know your DES key, unlike
TCP sequence guessing attacks), timestamps _are_ repeatable.

>Of course, a malicious foreign admin could misreport any other token
>issued at a plausibly similar time.  There's nothing at all that can be
>done about that - but as an admin, I have to view _any_ offsite report
>of abuse with some degree of skepticism; for all I know a priori, the
>alleged abuse never even happened.  The returned token merely guides my
>own search for evidence; it cannot, by itself, be damning.

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.  And identd cookies provide no protection
against this.

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

iD8DBQE8ozK4N71lEcOYcw4RAqpnAKDLxS+Hkqqr7Q0D2Vw9G0lWCKavlwCfQ2/a
Bs2Owa7Fos4WrIPwDUZK53k=
=lLVz
-----END PGP SIGNATURE-----