[ On Sun, March 16, 1997 at 18:14:49 (-0500), der Mouse wrote: ]
> Subject: Re: tcp-wrappers, tcpd, and NetBSD
>
> >> [...] a (real) pidentd [...]
> > Pardon my ignorance, but what is pidentd?
> 
> The name of one common implementation of the RFC1413 protocol (or at
> least something close to it).  The name gets used generically to
> describe any RFC1413 daemon.

Some more details:

     ("Peter's Ident Daemon" or is it "Portable Ident Daemon"?)

                Peter Eriksson <pen@lysator.liu.se>

It's in the public domain, and in fact it's the identd that's included
in the NetBSD source tree.  (Unfortunately there's still no
corresponding libident also in the tree.)
 
> The answer cannot be trusted by the asker - but then, it shouldn't be.
> It should be treated as an opaque token to be pushed back to the site
> that generated it if-and-when a complaint is made.

Yes, exactly!  This isn't a simple mechanism for authenticaion -- it's a
method for adding further trace details to log files.  Details that can
be critical information for the administrator who's system *provided*
the information in the first place.

> As for what the point is, well, if your site is attacked from mine, and
> you complain to me, presumably you would prefer that I take some
> action.  If you don't tell me what my pidentd returned for the
> connection in question, as I remarked earlier, about all I can do is
> wish you luck; our system is far too big for me to do anything useful
> with anything less than at least a half dozen connects when all I have
> to go on is timestamps (more if you aren't NTP-synced) - but if you can
> hand me back that token, I can use it to guide my search for more
> evidence and can likely do something useful with as little as a single
> complaint.

This can be a matter of policy for smaller systems too.  There's little
or nothing of value on my system, but it could be used as a hop-thru
site by crackers if it were to be compromised somehow.  I trust myself,
and thus of course root on my systems since that's me too, but I do have
some "foreign" users on my systems who I might not trust 100%.  Ident
data has in fact been of great benefit in the past to identify a session
that turned out to be the result of a compromised password of one of
these users (before the days of SSH ;-).

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>