> [Running a pidentd is] utterly, absoutely worthless if your user
> community knows the root password.

Yeah.  In that case, so are most attempts to do anything
security-related.

> Almost everyone I know has the root password on their system: you
> just can't do systems work if you don't know the root password.

True.  If machine A logs a pidentd string "foo" from the pidentd on
machine B, the value of this accrues mainly to the sysadmin on machine
B.  When the putative perpetrator has root access to machine B, the
string is worthless - but it is not for machine A to know whether
that's true; all A's sysadmin can do is pass that string along to B's
sysadmin.  Of course, if B's sysadmin _is_ the perpetrator, effective
action will not be forthcoming; in that case, A's admin will have to
take other action, such as telling tcp-wrappers to refuse anything from
machine B, or pushing the matter up to B's connectivity provider.

> One place pidentd is genuinely useful is sites with:

>   * aggressively managed security policy (to defeat breakin as an
>     excuse for denying responsibility for what identd may cause a
>     third party to log),
>   * a population of unprivileged users.

I see pidentd info as a tool for sysadmins to identify which of their
(nonprivileged) users is causing trouble.  Yes, if you have no
nonprivileged users (eg, a single-user personal machine), there is
little point in bothering with a pidentd except to pacify any services
that demand pidentd info, and by all means run one of these
"alternative" servers.  (But again, I don't think that's a decision for
NetBSD to make; that decision should be made by the sysadmin.)

As for the remark about "excuse for denying responsibility", I can't
see how that's applicable.  A sysadmin who fries a user on nothing
stronger than a single pidentd string from a remote site is probably
going overboard; the complaint itself could be forged[%].  And the
sysadmin handling the complaint must be presumed to know how
trustworthy hir own pidentd is and therefore how much weight to give
that particular piece of info.  As a sysadmin I would be, um, less than
convinced if I confronted a user and the user tried to deny it saying
"you must have had root cracked".

[%] Except for pidentds that return encrypted (or at least signed)
    tokens, which are as unforgeable as the underlying algorithm is
    strong.

> Assuming a campus or business environment with IDENT-emabled SMTP
> daemons, identd is an effectiev tool for stopping undergrads on
> timesharing hosts from forging e-mail; and that's about all it *does*
> do.

My pidentd is also a very effective finger-pointer if someone uses my
machine as a staging area to launch an attack on another machine.  I
have no time to wade through every user's data looking for evidence,
but with a finger pointed at one particular user I can do things like
check that user's files for rootkits, check logs for "interesting"
login patterns, etc.

> Identd (and tcp wrappers) are basically useless for security purposes
> in an unrestricted Internet environment.

Useless to whom?  Most of the benefit of a pidentd accrues to the
sysadmin running it.  Ditto for tcp-wrappers - I find it
incomprehensible how you can call tcp-wrappers "useless for security
purposes".  tcp-wrappers logs have proven their value to me as a
sysadmin time and time again.

> I'm sure this is an FAQ, but are the authors of ircd somehow lacking
> in clue?  rfc1413 clearly allows OTHER as an operating system, and
> even enumerates some cases where it's the preferable thing for a
> unix-like system to return.

Sure.  But it's not entirely unreasonable for a piece of software to
enforce additional restrictions based on the pidentd response.  This
particular restriction strikes me as a singularly silly one (I'd say
the answer to your first sentence is "yes"), but if people running IRC
daemons choose to use it (by running, unmodified, software that
enforces that policy), that's their decision.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B