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

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

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.

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