[lug] open port

[rise]

On Thu, 28 Mar 2002, Riggs, Rob wrote:

> I understand your rant. But I do disagree. IDENT is a relic of a
> more naive time. Now, when anyone on a workstation has admin rights
> (my Linux box, the Win95 box down the hall, etc.) IDENT cannot be
> trusted for anything.  Furthermore, IDENT came about at a time when
> most people used timesharing systems (1984).

Yep, trusting or requiring ident is a recipe for disaster.  These days
ident is for the benefit of the identd operator, not the ident client.
I think ident could have a minor resurgence as the time-sharing
systems of the past become today's network-sharing systems (freenets,
anyone?).  Once again we have a single point of control (per node)
with an only partially trusted user-base.

> And it *was* mean to be an authentication protocol. Heck, prior to
> 1413, it was called the Authentication Service Protocol[1][2]. And
> the original author did intend it to be used as such!  This is why
> it is still labeled "auth" in /etc/services and called the AUTH
> protocol by many.

Yes, for _weak_ values of authentication[0].  Then people clued in,
changed the name and RFC, cleaned up some of the problem areas...  and
discovered that well-meaning idiots had made if basically impossible
to fix.  I'm not saying sites should provide ident or, $DEITY help us,
depend on ident - I'm pointing out that it can be useful when not
misused.  That probably means "useless 90% of the time given current
competency levels", but I'd rather not have ident obsoleted or
anything.

> But my point was that it's useless for even basic identification,

Not necessarily true: I've been designing a public Wireless Access
Point for installation in my home that will probably provide encrypted
ident tokens for the NAT'd connections coming out of the IPSEC
tunnels.  In that case I can deal with an abuse situation that's not
immediately noticed without keeping traffic records forever or at all
(which I ethical problems with and which are a legal tangle).

> especially for email, since most SMTP conversations are between
> daemons, and not user to server. It's completely unnecessary between
> border MTAs. The "Received" header is a far more useful tool for
> LART activation.

Agreed wholeheartedly.  I suspect this was meant by a good-intentioned
but naive soul for the situation where a local-network workstation is
talking to a local-network MTA and has since been implemented widely
by luserish admins and developers who should be forced into an
unnatural[1] closeness with MS Exchange.

[0] I.e. untrustworthy identification == authentication.  Bad idea.
[1] and unnaturally painful.

-- 
Jonathan Conway						      rise at knavery.net
history is paling & my surge protection failed, & so I FRIED
						- Concrete Blonde, "Fried"