ArkanoiD wrote:
>I remember when i asked if it is useful to make fwtk proxies capable of
>ident lookups - about 7 years ago i think ;-) i've heared people screaming
>"no, no, identd is insecure and bad, don't use it!"

Oh, no, here we go AGAIN!

>But what's really wrong with identd? It seems to be a good way to distinguish
>users on multiuser hosts.

"What's wrong with it" is that the idea behind identd is so
wretched that it makes people who care about security
design break out into hives, swell up, and die. 15 or however
many years after its introduction, I can be fairly positive
that the arguments against it and for it are pretty much
the same:
Against: It sucks!
For: It doesn't suck as much as nothing!
Against: Yes it does!
For: No it doesn't!
Against: Doesdoesdoesdoesdoes! (Hands over ears)
For: *boink* (thumb in eye)

>Well, doing that via kerberos or ssl certificates
>may be better, but both require some protocol intervention.

Right!! That's the point, in fact. The amount of time wasted
setting up ident might have been sufficient level of effort to
make the necessary protocol interventions.

Remember - this all happened in the early 1990s... At that
time, there still was hope that public key certificates would
not turn out to be the sad joke they are. At that time it
seemed like we'd actually have bidirectional authentication
with certificates - instead of SSL (AKA: "Exchanging
certificates so you can ignore them.") and SSH (AKA: "Using
rocket science public key exchanges to protect your 4
character password.") Many of us saw ident as an
unecessary protocol that was distracting people from
places where effort might be better invested.

We were right, for what it's worth (damn little!) if the
IETF had been an actual, effective standards body, we
might have been able to accomplish the deprecation of
TELNET, FTP, IMAP, etc, etc, or at least versions
of those that did not support what we know now as TLS.
What is excruciating to me is that the fact that these
things are obvious now doesn't change the fact that
they were obvious, then, too.

>So if you
>do trust host users separation (and if it is compromised at root level no
>method is good enough anyways), ident info can be used as well. And it is
>up to you what to do with it.

That's the standard argument in favor of identd. And, if you shuffle
the words around and preserve meaning it boils down to "on the
occasions that it's useful, it'll be useful." The problem is that it's
not - and never has been - useful enough to be useful.

One of the other things a lot of us were afraid of (fortunately) never
came to pass -- and that was the (inevitable) use of ident as a
permissions gate. You know, the old "if ident says that the user
is 'mjr' then grant access to 'mjr's files!" brain damage. Given
the level of stupid out there, a lot of us expected that to happen.
I used to wake up screaming, some nights, because I had this
recurring nightmare in which people started using ident as
a form of authentication. And then there was an RFC for
"s-ident" using a certificate hierarchy. And that (of course) didn't
work, so someone added SecurID tokens and a challenge-response
model to ident and reinvented RADIUS. And, in my dream, I
was running down an endless hallway, being pursued by a
gigantic mass of ugly code being pushed from behind by
Security Dynamics and the IETF and at the end of the hallway
is a locked door with Marshall Rose and as I come running
up yelling for help he utters the horrifying words "MIME ident
over SNMP" and I wake up screaming and clawing at my

After a few years of that, I did what most old-time security
systems designers do: I stopped caring. It's the only defense.

>Is ident still being used by anyone besides irc and smtp?


And you can see how effective identd has been at enabling
system administrators to backtrack spammers and IRC botters.
What do you mean, "it hasn't!" Well, yeah: Exactly.


firewall-wizards mailing list