Suggestion for improved identD

Mailman List Mirror (Read Only)
1

Suggestion: PPP access devices intercept identD requests
    and return the authenticated access string.

Reasoning: Modern ``stacks'' used by end-users -- especially
    those on throwaway accounts, fake any identD response.
    This makes tracking those people tougher.

Methods: 1: identD v2, new port, intercepted by access devices
       which support it.

    2: modification to hosts requirement RFCs, making
       access devices responsible for intercepting identD
       requests to their PPP clients.

    3: a security RFC ``suggesting'' 1 or 2

Thoughts appreciated, as are comments, flames, blames, and anything
of some content.

Ehud
gavron@aces.com

p.s. new beta traceroute at ftp.aces.com cd pub/software/traceroute/beta

2

...

There isn't necessarily just a single user on the other end of a PPP
connection.
  
  Perhaps I should have phrased it as "single user network
  connection" and not "PPP". I'm less concerned with the
  PPP as a protocol than as its modern usage to connect the
  dialup user.

Many things will break if the actual user and the user
that PPP intercepted identd asserts do not match.

  Oh?

Providing such information may be a violation of confidentiality if

  Login string. e.g. username.

Because the PPP access device cannot know, unless it also tracks all the
traffic involved, what ports are in fact in use, it would have to give

  If l2 is up, it's up. That's fairly basic...

I believe you misunderstand the purpose of identd. It was intended to

...
  Nope...

Why do you want this data?

  My personal crusade against packet monkeys, spammers, and
  irresponsible admins who support them by pretending that
  the net is free for all to abuse.

  E

3

Reasoning: Modern ``stacks'' used by end-users -- especially
    those on throwaway accounts, fake any identD response.
    This makes tracking those people tougher.

Although it was designed to give the owner of a TCP connection, identd is
only commonly used for SMTP, IRC, and occasionally POP3. The latter 2
protocols are irrelevant; the former is publicly accessable and the
latter requires a password. So we're left with SMTP.

An example SMTP header:

Received: from evilspammer (207-172-189-146.s67.as3.plb.erols.com
[207.172.189.146]) by smtp2.erols.com (8.8.8/8.8.5) with SMTP id XAA19893
for <joe@test.com>; Mon, 18 May 1998 23:34:27 -0400 (EDT)

In common implementations*, "evilspammer" will be the identd reply. Since
it's easily forgable, simply disregard it and go by the IP address (and
hostname, if shown).

* = abnormal Received headers may be harder to interpret but if a site
hasn't upgraded their SMTPd in that long, they're not going to upgrade for
this.

Methods: 1: identD v2, new port, intercepted by access devices
       which support it.
    2: modification to hosts requirement RFCs, making
       access devices responsible for intercepting identD
       requests to their PPP clients.
    3: a security RFC ``suggesting'' 1 or 2

Assuming this change was meant to ease spam tracking, all current SMTP
daemons would have to be modified to use the new protocol and port.

Existing access devices would also need to be patched/upgraded or, if
that wasn't possible, the identd v2 request wouldn't be intercepted and
would still be answered by the client. Then we're back to square one.

Since some hosts would have identd v2 disabled and there would be a large
number of users not running v2 daemons, replies would need to be optional
and no services could depend on them. As such, nobody would bother.

At least on this ISP, there are a number of intensely private users who,
if they noticed, would probably complain. They complained about the
NNTP-Posting-Host header in NNTP until it was removed. I doubt the concerns
of oz.net users are particularly unique and since identd v2 would be
"suggested", many/most ISPs would disable it.

IMO, this would be a decent size headache with little benefit. I'm sure
I'll be corrected if I'm wrong.

p.s. new beta traceroute at ftp.aces.com cd pub/software/traceroute/beta

Thanks.

Cheers,

Troy Davis

4

) Suggestion: PPP access devices intercept identD requests
) and return the authenticated access string.
So, what you're suggesting is that all PPP users will automatically have
ident queries handled for them by their ISP? Thanks, but I think I'd
rather not. There are definitely some sites on the Internet that run their
own proper identd and are connected to the Internet via a dialup PPP
connection. The explosive growth of the Linux operating system, among
other factors, accounts for this truth. I just fail to see how
establishing an upstream-regulated ident request would be beneficial to
anyone in any way--surely you aren't suggesting this be used as opposed to
dialin records for tracking down specific users when they're abusive,
right?

) Reasoning: Modern ``stacks'' used by end-users -- especially
) those on throwaway accounts, fake any identD response.
) This makes tracking those people tougher.
I fail to see how tracking them becomes harder. As I stated above,
tracking based on host name coupled with dialin logs would be far
better--unless every ISP implements this, there will always be some
[ab]user who is able to create their own ident reply, which would weaken
the effectiveness of upstream-controlled ident replies.

5

) An example SMTP header:
)
) Received: from evilspammer (207-172-189-146.s67.as3.plb.erols.com
) [207.172.189.146]) by smtp2.erols.com (8.8.8/8.8.5) with SMTP id XAA19893
) for <joe@test.com>; Mon, 18 May 1998 23:34:27 -0400 (EDT)
)
) In common implementations*, "evilspammer" will be the identd reply. Since
) it's easily forgable, simply disregard it and go by the IP address (and
) hostname, if shown).
Actually, in that example, ther was no ident reply from the remote host.
"evilspammer" is just the name given when the remote host gives his EHLO
or HELO.

Received: from mail.n.ml.org (djr@narnia.mhv.net [199.0.0.118])
    ...

means my mail server identified itself as "mail.n.ml.org," with a real
host name of "narnia.mhv.net" and IP of 199.0.0.118, and an ident reply of
"djr."

6

Suggestion: PPP access devices intercept identD requests
    and return the authenticated access string.

Reasonable idea in -some- network settings.

Methods: 1: identD v2, new port, intercepted by access devices
       which support it.

Bad choice. Time to adoption would kill the idea. We're already on a
second run of the AUTH protocol as it is. :wink:

    2: modification to hosts requirement RFCs, making
       access devices responsible for intercepting identD
       requests to their PPP clients.

    3: a security RFC ``suggesting'' 1 or 2

Both a bad idea. This is not something necessary in most settings; some
people are simply not interested in giving up this information. I'd oppose
any such attempt to make it a host requirement.

Read the auth/ident protocol RFC: the data retrieved using it is
inherently untrustable, and cannot be relied upon to be even remotely
correct. In some circumstances, you may not even be able to determine what
the information means; that identification information may have absolutely
no meaning to you since you have no control over how the network you
retrieved the information from operates.

However, the idea does have merits for closed environments, or for open
environments which desire accountability for their dialup users when
dealing with external abuse or bug reporting.

I would recommend a slightly more sophisticated approach, however: a
semi-configurable identd running on the terminal server, which either:

a) returns the auth'd data, or

b) hands the request off to a server running on another machine, which
   can do interesting things with the information before returning a
   response.

The reason for this is that this idea would need to be adopted by NAS
vendors; frankly, I don't trust them to get the implementation right, and
would rather they just proxy the request to me, along with the necessary
host and internal authentication information, which I can then process in
my own way, and return what -I- consider to be a unique identifier for
that user.

But frankly, a timestamp and an IP address are all the "unique identifier"
you need for tracking down an abuser on any relatively modern network
doing a reasonable level of logging.

7

Actually, in that example, ther was no ident reply from the remote host.
"evilspammer" is just the name given when the remote host gives his EHLO
or HELO.

Received: from mail.n.ml.org (djr@narnia.mhv.net [199.0.0.118])
    ...

means my mail server identified itself as "mail.n.ml.org," with a real
host name of "narnia.mhv.net" and IP of 199.0.0.118, and an ident reply of
"djr."

There are valid reasons for a mail to be sent claiming to be sent from
an address it wasnt actually sent from (this is why there is sendmail
-f). Identd, on the other hand, is wholly worthless. I can't believe
people actually trust it (ie, in wrappers), as it is so trivially
forged.

I think the "proxy ident" idea is the most silly thing I've heard in
ages. Come up with a rotating key-based way to authenticate clients
and we can talk turkey..

8

Troy Davis wrote:

> Reasoning: Modern ``stacks'' used by end-users -- especially
> those on throwaway accounts, fake any identD response.
> This makes tracking those people tougher.

Although it was designed to give the owner of a TCP connection, identd is
only commonly used for SMTP, IRC, and occasionally POP3. The latter 2
protocols are irrelevant; the former is publicly accessable and the
latter requires a password. So we're left with SMTP.

  If I follow the flow of your paragraph correctly, you're listing IRC in
the irrelevant category. While I am not going to attempt to convince you
otherwise, let me describe a fairly common problem we have on our
network.

  StupidUser comes onto DALnet with the address
FakeIdent@pop99.yourisp.com. They cause problems such that we need to
ban them from the network. A young and foolish IRC Operator bans
FakeIdent@*.yourisp.com. Well that doesn't even slow them down, they
just change the ident and reconnect. So now we need to ban
*@pop99.yourisp.com. This stops a certain percentage of users (put
bluntly, the stupid ones). However the smart ones just redial.

  Now we need to ban *@*.yourisp.com because 'yourisp.com' doesn't have
any reliable means of identifying pops by geographical regions, or some
other way for us to limit the ban to avoid preventing access for yourisp
entirely. Not a problem you say? Well you might be right. Depends on
what percentage of your userbase uses IRC. And I do mean IRC and not
just DALnet because chances are that problem user is going to go get
yourisp banned on some more networks before they get bored. There are
some fairly large national providers that have been banned from DALnet
for a long time generating literally hundreds of e-mails to us and phone
calls to them.

  A reliable method of identifying customers would be a huge benefit in
this situation. As I said, I'm not going to try convincing anyone that
IRC is "significant." I'm not even saying that it's worth developing
this type of ident system on a 'net-wide basis. My point is simply to
illustrate the potential value of such a system in one little corner of
the internet. A very conservative estimate would put 200,000 people on
IRC (on various IRC networks) every night. Multiply that by
approximately 4 to get the number of people who use IRC at least once a
week or more. Then consider that the size of our network has increased
12 times in the last two years and we're talking about an awful lot of
yourisp's customers who would benefit directly from us being able to ban
ReliableIdent@*.yourisp.com.

Just a thought,

Doug (who would be happy to put together some more IRC-friendly
recommendations for ISP's that can actually be implemented now if anyone
is genuinely interested :slight_smile:

9

On Wed, May 20, 1998 at 12:25:48AM -0400, Christopher Neill put this into my mailbox:

There are valid reasons for a mail to be sent claiming to be sent from
an address it wasnt actually sent from (this is why there is sendmail
-f). Identd, on the other hand, is wholly worthless. I can't believe
people actually trust it (ie, in wrappers), as it is so trivially
forged.

I think the "proxy ident" idea is the most silly thing I've heard in
ages. Come up with a rotating key-based way to authenticate clients
and we can talk turkey..

I hate to break it to you, but not everyone runs Win95 or a Niftee NT
Box where people can forge ident to be whatever they please. Some of us
actually run REAL multiuser operating systems where the ident can be trusted.

In these cases, the ident value is often the only method we've got for
tracking down a particular user. Otherwise, someone who spams, or otherwise
abuses someone's services could be any one of a hundred users.

When it's properly set up by clueful people and can be trusted, ident is
good for exactly one thing: identification.

While ident may not need to return a string useful to you or I, it is useful
to the ISP in that this string can be used to reliably identify a user (or,
most likely, an abuser). In addition, if the *same* string is returned each
time ident is queried for a particular user, this can be used in a hosts.deny
or other ban. If JoeSpammer@pm65.yourisp.com decides to try and bring down
my mail servers by spamming my users with Make Money Fast, I can add
JoeSpammer@*.yourisp.com to hosts.deny, and my friend Fred@yourisp.com
can still send me e-mail. Same goes for IRC.

I don't want to hear any BS about how 'ident is unreliable' and 'ident
can't be trusted'. If it's been properly set up such that the ISP controls
what is returned rather than the user, or if the protocol is properly
redesigned to guarantee this, it *WILL* be trustworthy. And a particular
ISP can't be trusted to run a proper ident, then they get their entire
network blocked.

Right now, if someone from earthlink.net or aol.com or uu.net starts
abusing my services, I'm pretty much screwed. Do I let the idiot keep
doing it, and hope that the abuse desk gets around to my complaint in
the next week? Or do I ban the entire domain and hope to god that the
number of e-mails asking what happened is under ten thousand this time?
Some way of determining that the user connecting now from
ip5.tnt11.max5.dallas.uu.net is the same person who came on collecting
passwords from ip2.tnt5.max3.sanantonio.uu.net would be REALLY nice.

Note, ident doesn't have to be 100% reliable and trustworthy all of a
sudden. Nobody should ever use it for authentication. But it sure would
be nice if it (or something like it) could be trusted to determine, to
both sides, that UserA who's connecting at 4 PM is the same UserA who
connected at 10 AM. That's all it needs to do.

-dalvenjah

10

I hate to break it to you, but not everyone runs Win95 or a Niftee NT
Box where people can forge ident to be whatever they please. Some of us
actually run REAL multiuser operating systems where the ident can be trusted.

[ ... ]

I don't want to hear any BS about how 'ident is unreliable' and 'ident
can't be trusted'. If it's been properly set up such that the ISP controls
what is returned rather than the user, or if the protocol is properly
redesigned to guarantee this, it *WILL* be trustworthy. And a particular
ISP can't be trusted to run a proper ident, then they get their entire
network blocked.

I hate to point this out, Dal, but what is being asserted is that "the
operator of the ident daemon is not under the same administrative span
of control as I am". _That_ is why we say that it "cannot be
trusted". Trust has a _very specific_ meaning there.

It _might_ be reliable... but then again, it might not. Unless _you_
have a _contract_ with the _guy at the other end_, specifying that
he'll run an authenticated ident server, and guarantee on pain of
indemnity that it's accurate, you can't call it _trustworthy_.

There _is_ a difference between that and _useful_, however.

Cheers,
-- jra

11

On Wed, May 20, 1998 at 11:57:29AM -0400, Jay R. Ashworth put this into my mailbox:

> I hate to break it to you, but not everyone runs Win95 or a Niftee NT
> Box where people can forge ident to be whatever they please. Some of us
> actually run REAL multiuser operating systems where the ident can be trusted.
[ ... ]
> I don't want to hear any BS about how 'ident is unreliable' and 'ident
> can't be trusted'. If it's been properly set up such that the ISP controls
> what is returned rather than the user, or if the protocol is properly
> redesigned to guarantee this, it *WILL* be trustworthy. And a particular
> ISP can't be trusted to run a proper ident, then they get their entire
> network blocked.

I hate to point this out, Dal, but what is being asserted is that "the
operator of the ident daemon is not under the same administrative span
of control as I am". _That_ is why we say that it "cannot be
trusted". Trust has a _very specific_ meaning there.

Okay...I can understand that. However, if the protocol gets redesigned to
allow for a 'domain-wide' ident server (for sake of argument), and I set up
my client to put up a flag when it gets an answer from the domain-wide
server as opposed to the host server, I'm going to put more trust in that
domain-wide server than I would a response from the host directly.

It was also just pointed out to me that the idea of banning someone
based on ident is a matter of authentication, not identification, and
so doesn't really have a place in this discussion. I'm willing to forego
that, and reserve that discussion for a different protocol.

It _might_ be reliable... but then again, it might not. Unless _you_
have a _contract_ with the _guy at the other end_, specifying that
he'll run an authenticated ident server, and guarantee on pain of
indemnity that it's accurate, you can't call it _trustworthy_.

There _is_ a difference between that and _useful_, however.

Agreed. Part of my original idea (which is now my main idea for this
discussion) is that time and time again, I have gotten responses to
complaints about users that 'we need another incident so we can correlate
this with our logs properly'; or even better, 'oops, looks like we weren't
logging yesterday'. If we can come up with some form of ident that makes it
a no-brainer for the ISP to a) set up and b) plug in a string and get the
username (or other identification token) and timestamp so they can give
the user a good talking to or yank their account, I will be happy.

My problem is folks who make sweeping declarations that because one
isn't sure when one can trust ident, it's not useful at all. That's not
the case.

-dalvenjah

12

Not every dialup connection is a single end luser on a win95 box. What
about ISDN connections where there's a whole network of real computers and
different users (on each computer)? How does the NAS decide which
connections to intercept for and which not to? Even if you knew the
username, what good will it do you 1000 miles away? Those providers who
care can fine the user if you tell them the IP and time of day. Those who
don't care won't care if you tell them "I was spammed by
abc123@yournets.net".

13

RADIUS.

Cheers,
-- jra