Suggestion for improved identD
dean at av8.com
Sat May 23 02:03:53 UTC 1998
>>100% deployment. Packets from my IP address should be from me, and
>>packets to my IP address should get to me.
>What about transparent http proxying?
smtp redirecting only works for a particular class of dialin services, such
as online services that also provide mail. It doesn't work in general. In
fact, I know it would break some of my customers, since they want to dialin
via frontier and such places and get to their company smtp machine. (from
the dialin they want to continue sending as user at some.domain.) In other
words, they are purchasing a packet service. Not an "online" service.
As for the problem of identification that identd expected to solve, it's
fundamental brokeness is due to the fact that it depends on the machine
itself to be trustworthy, just like berkeley r-commands, and low numbered
ports. That model hasn't worked for many years. No matter how you slice
it, anything that uses identd is very weak, and easily subverted.
What might be a useful interim solution is to change identd to perform a
verified pgp exchange or similar. Then you know at least that a real person
is associated somehow the machine on the other end. (Only that a certain
user is there, but not that s/he is the one using irc, etc.) This probably
solves 90% of the problem of win95 users dialing in, since they have to at
least give out a friends id, who probably won't remain their friend for
Identd assumes that the application (eg irc) gave you a real (true)
username to begin with, and the program connecting was actually ran by that
user. Which can't be trusted since its communication channel isn't
The real solution is to delete identd, and replace all identd-dependent
programs/protocols with authenticated versions. Of course, that's probably
not going to happen very soon.
Plain Aviation, Inc dean at av8.com
We Make IT Fly! (617)242-3091 x246
More information about the NANOG