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
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.
There isn't necessarily just a single user on the other end of a PPP connection. Many things will break if the actual user and the user that PPP intercepted identd asserts do not match. Providing such information may be a violation of confidentiality if it gives information about a person or that person's account, especially if the person does not want to give it out. 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 the response for any port, even if not in use. This means anyone can get the ID only by knowing the IP. This will be very VERY easy to abuse by spammers trolling for addresses, under the notion that the ident data generally would match the e-mail address for that domain. I believe you misunderstand the purpose of identd. It was intended to supplement the IP address on a multi-user system to narrow the focus of trust in cases where the system itself was trusted (not longer a valid assumption these days). Why do you want this data? And would you really want the correct userid from a multi-user system or a masqueraded network of multiple machines which the PPP device cannot know? -- Phil Howard | suck4it5@no1where.net stop1763@spammer1.edu stop9it3@s6p5a7m9.com phil | end6ads6@dumb3ads.net suck5it1@anyplace.org blow7me5@anyplace.com at | end0it35@anywhere.com end2ads4@lame0ads.org stop4698@anyplace.com ipal | stop0577@anywhere.edu no92ads1@s5p1a2m7.net a6b8c5d2@spam1mer.net dot | w1x7y9z6@spam8mer.edu die0spam@lame2ads.com crash308@spammer0.org net | end0ads7@dumbads6.org stop6it4@no05ads8.net no9way66@s8p7a9m6.net
...
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
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.
And how do you tell the difference between a single user connection and multi-user connection? They both use PPP. Are you going to make all the Linux users out there have to start negotiating with their ISPs just to allow them to be on?
Many things will break if the actual user and the user that PPP intercepted identd asserts do not match.
Oh?
Yup. IRC bots, for instance. They expect certain specific information to grant authority, and if the PPP server substitutes it, it can't be correct all the time on systems with two or more users since the PPP server won't know which user is on which port (without actually going to that machine to ask ... but then what's the point).
Providing such information may be a violation of confidentiality if
Login string. e.g. username.
Dialup account id? Unfortunately this is usually also the e-mail address by just appending @isp-domain.net and thus giving out tons of addresses to spammers. I won't subject my customers to this.
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...
So if I request an ident on port 15421, is the PPP server going to answer it even though, there is in fact no active port 15421 on that machine? You want PPP servers to track all those SYN and RST?
I believe you misunderstand the purpose of identd. It was intended to ... Nope...
So you do understand that the data wasn't intended to be trusted if you have no trust of the machine (and certainly most of them out there cannot be trusted).
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.
I applaud the goals. I don't think this is a viable mechanism to achieve them. BTW, I blocked access to SMTP other than to my own servers for all my dialup non-LAN customers. I don't like abuse, and won't put up with it, either from my customers, or to them. But this identd idea is not something I will do to my customers. The cure is worse than the disease. The answer is simple. Don't trust identd responses. Just don't ask for that data and then you don't have to worry about it being forged. -- Phil Howard | no7way44@noplace5.org ads2suck@dumbads8.com a4b3c4d5@no0place.org phil | no6spam2@spam3mer.com end3it15@no16ads4.edu stop6it8@dumb9ads.net at | end6it02@s0p9a9m3.edu stop2ads@nowhere8.org end8ads7@spammer1.com ipal | no8way90@no86ads8.net blow3me2@dumb9ads.net w5x2y2z9@spam8mer.com dot | stop1020@spammer5.edu stop7317@no5place.net no4spam7@anyplace.com net | eat55me9@spammer5.org no71ads8@lame9ads.net suck4it6@dumb7ads.org
Phil Howard writes:
There isn't necessarily just a single user on the other end of a PPP connection. Many things will break if the actual user and the user that PPP intercepted identd asserts do not match.
Providing such information may be a violation of confidentiality if it gives information about a person or that person's account, especially if the person does not want to give it out.
Then do the hash thing that I suggested earlier. (I'm not taking credit for the idea btw.. it wasn't mine.)
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 the response for any port, even if not in use. This means anyone can get the ID only by knowing the IP. This will be very VERY easy to abuse by spammers trolling for addresses, under the notion that the ident data generally would match the e-mail address for that domain.
Then do the hash thing.
I believe you misunderstand the purpose of identd. It was intended to supplement the IP address on a multi-user system to narrow the focus of trust in cases where the system itself was trusted (not longer a valid assumption these days).
The system might not be trusted.. but the NAS is. Why bother with ident in any case if most of the dialup users can spoof it? Far far too many applications still send off an ident request and log it.
Why do you want this data? And would you really want the correct userid from a multi-user system or a masqueraded network of multiple machines which the PPP device cannot know?
If you really needed this, then have the NAS configureable so: * You can send a RADIUS/TACACS tag specifying "no ident spoofing" * It doesn't spoof ident on IPS that aren't in the specified IP pools That provides ident support for dialup clients, but passes through ident requests for static clients. You can't get the contact details directly from the hash, but you can use it to deny access to services (eg sendmail, nntp, irc) that run ident checks. Adrian
On Tue, 19 May 1998, Ehud Gavron 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. 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
On Tue, 19 May 1998, Troy Davis wrote: ) 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." -- Daniel Reed <n@ml.org> (ask me for my PGP key) One man's Windows are another man's walls...
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.. -- Christopher M Neill -- Network Operations QualNet - We Make the Internet Work for Your Business.(sm) DID: 216-902-5460, Office: 800-466-0088, Fax: 216-623-3566 http://www.qual.net
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 -- Dalvenjah FoxFire (aka Sven Nielsen) "Never mess with a dragon, for you are Founder, the DALnet IRC Network crunchy, and taste good with ketchup." e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Wed, May 20, 1998 at 08:26:28AM -0700, Dalvenjah FoxFire wrote:
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 -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Wed, May 20, 1998 at 11:57:29AM -0400, Jay R. Ashworth put this into my mailbox:
On Wed, May 20, 1998 at 08:26:28AM -0700, Dalvenjah FoxFire wrote:
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 -- Dalvenjah FoxFire (aka Sven Nielsen) I bet living in a nudist colony takes Founder, the DALnet IRC Network all the fun out of Halloween. e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
Troy Davis wrote:
On Tue, 19 May 1998, Ehud Gavron 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 :) -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of the world's largest Internet *** Relay Chat server with 5,328 simultaneous connections. *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD)
On Tue, 19 May 1998, Ehud Gavron wrote: ) 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. -- Daniel Reed <n@ml.org> (ask me for my PGP key) Artificial Intelligence stands no chance against Natural Stupidity
Ehud Gavron writes:
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.
I've done this for a couple of internet providers in Western Australia. Either by using transparent proxying under Linux (one used a Linux term server..), or a route-map to a *nix box on a Cisco. There are a few privacy issues too - if you want to see who is online, you just send out ident requests to all dialup lines, and the 'real' idents are returned. One Perth ISP fixed this by using a hash of the username. That fixes IRC bans (so they can just ban *!*hash@*isp.com.au ) .. and if someone wants to track a user down, they ring the ISP and hand over the hash. Adrian
On Wed, May 20, 1998 at 10:41:38AM +0800, Adrian Chadd wrote:
Ehud Gavron writes:
Suggestion: PPP access devices intercept identD requests and return the authenticated access string.
I've done this for a couple of internet providers in Western Australia. Either by using transparent proxying under Linux (one used a Linux term server..), or a route-map to a *nix box on a Cisco.
There are a few privacy issues too - if you want to see who is online,
Plus, for some applications it doesn't matter. One of the biggest applications of identd is for IRC, and the IRC model is broken. For example, amethyst.nstc.com, my home PC running Linux, HAS a working identd. But although Efnet IRC servers always recognize it, DALnet servers never do. (Hey, Mr. Nielsen, fix your servers. :) -- Steven J. Sobol - Founding Member, Postmaster/Webmaster, ISP Liaison -- Forum for Responsible & Ethical E-mail (FREE) - Dedicated to education about, and prevention of, Unsolicited Broadcast E-mail (UBE), also known as SPAM. Info: http://www.ybecker.net or Usenet: <6i6eeu$kr9$1@camel18.mindspring.com> mailto: sjsobol@nstc.com, sjsobol@nacs.net, sjsobol@apk.net
On Tue, 19 May 1998, Ehud Gavron wrote:
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. ;-)
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. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 9:55pm up 1 day, 23:26, 4 users, load average: 0.02, 0.11, 0.15
On Tue, 19 May 1998, Ehud Gavron wrote:
Suggestion: PPP access devices intercept identD requests and return the authenticated access string.
Thoughts appreciated, as are comments, flames, blames, and anything of some content.
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". ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Jon Lewis writes:
On Tue, 19 May 1998, Ehud Gavron wrote:
Suggestion: PPP access devices intercept identD requests and return the authenticated access string.
Thoughts appreciated, as are comments, flames, blames, and anything of some content.
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".
Its more of blocking services. When I implemented the forced ident setup, if a user had a static IP, then the ident was passed through. Only if they were a dynamic IP dialup client would the ident be forced. The idea here is not to provide a username. Its to provide a method of identifying a dialup user, in a way that doesn't change with each login. Since most things already query ident, then why not go this path and make ident 'trusted' on dynamic IP NAS connections? Adrian
On Thu, May 21, 1998 at 01:19:41PM +0800, Adrian Chadd wrote:
When I implemented the forced ident setup, if a user had a static IP, then the ident was passed through. Only if they were a dynamic IP dialup client would the ident be forced.
The idea here is not to provide a username. Its to provide a method of identifying a dialup user, in a way that doesn't change with each login. Since most things already query ident, then why not go this path and make ident 'trusted' on dynamic IP NAS connections?
Ok, I almost like this. The only problem I can see is when the dynamic dialup user is still a linux box... but in that case, the administative control _still_ vests in the subscriber. How about: proxy intercept the ident port and return something based on the dialup ID unless a) the port is a static connection or b) the user has specifically requested to do their own identing. Now, it would be nice to be able to tag which idents come from the proxy and which don't... but we're getting into signed-identd territory now. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Thu, 21 May 1998, Jay R. Ashworth wrote:
On Thu, May 21, 1998 at 01:19:41PM +0800, Adrian Chadd wrote:
When I implemented the forced ident setup, if a user had a static IP, then
The idea here is not to provide a username. Its to provide a method of identifying a dialup user, in a way that doesn't change with each login.
Ok, I almost like this.
The only problem I can see is when the dynamic dialup user is still a linux box... but in that case, the administative control _still_ vests
could the ident be intercepted, so that the ident result from the dialler was retagged? tricky... in just the same way that adding SMTP or NNTP headers allows additional tracking but doesn't prevent the originator of news or mail from supplying their own. Paul ---- P Mansfield, Senior SysAdmin PSINet, +44-1223-577577x2611/577611 fax:577600
On Thu, May 21, 1998 at 03:14:57PM +0100, Paul Mansfield wrote:
Ok, I almost like this.
The only problem I can see is when the dynamic dialup user is still a linux box... but in that case, the administative control _still_ vests
could the ident be intercepted, so that the ident result from the dialler was retagged? tricky...
in just the same way that adding SMTP or NNTP headers allows additional tracking but doesn't prevent the originator of news or mail from supplying their own.
Yeah, you could do a full proxy-ident: retrieve the userid from the end-user, and then resend it yourself. But all you'd be tagging it as is: _I_ didn't generate this... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
I've been following the "need a better IDENT" thread for a bit, and have some questions and suggestions. Let's see if we can *really* define what it is we really want, and figure out if IDENT or "son of IDENT" is really the answer. Sorry for the length and the over-pedanticism (is that a word? :-) ), I'm trying to summarize a whole bunch of ideas and messages here, and be really specific about the real problem we're trying to solve. There seem to be two completely different motivations for wanting a "better IDENT": 1. To allow IRC operators (and others) to block access to abusive (or undesired) remote users more selectively than by blocking an entire domain or net-block. The desire here is essentially for a real-time authentication for ad-hoc users from administrative domains over which you have no control, which you may not "trust", and for which the user identification (username/"nick") AND the IP address are selected either by the user (the nick) or by the domain (dynamic IP addresses). This is a *hard* problem. Basically you are trying to not trust anything presented by the connection or the user, and make an authentication decision. As long as the end user can generate new identities at will, you are stuck. They can generate new ones at least as fast as you can block old ones. Unless you force people to go through some registration process that either forces a delay (you can't use your new nick until tomorrow), or some "validation step", you will never win. 2. To allow domain administrators to determine, after-the-fact, who is responsible for or was "in control" of activities coming from a specific IP address or net-block, in an administrative domain that they do not control or have access to, at a given time in the past. The desire here is to be able to identify the human responsible for such mis-behaviors as denial of service, undesired probes and intrusion attempts (or successes!). It is usually considered acceptable if the mechanism gives you some sort of token that you can then present to the owner of the source domain, who can then identify their user by way of RADIUS or other user authentication logs. This is a much easier problem, and is the *exactly* one for which IDENT was designed, as long as the IDENT server is under the control of the administrative domain, and not the end user. In other words, the connection came from and the IDENT server is on a time-sharing machine under some kind of "responsible" control. Trying to address the "not under control of the end user" is the restriction that the "proxy-IDENT" proposals is trying to address. What I don't understand is why you can't just present the IP address, and the time of the mis-behavior to the network owners; they should be able to identify the responsible person from the dial-up authentication (RADIUS or other) logs. Even if there is a complete network behind the dial-up (or ISDN or whatever), there *had* to be an authentication of some sort to establish the connection, or they have bigger problems that will not be solved by a "better IDENT". At worst, they can delegate the problem to whoever authenticated: "Find and solve the problem before we allow any of your connections. If this cuts off several people that's *your* problem. Its your subnet and your account. You are responsible for it. Fix it." This note seems to be desiring function #1, e.g. ad-hoc user authentication:
The moving finger of Adrian Chadd, having written: Adrian> The idea here is not to provide a username. Its to provide a method of Adrian> identifying a dialup user, in a way that doesn't change with each login. Adrian> Since most things already query ident, then why not go this path and make Adrian> ident 'trusted' on dynamic IP NAS connections?
-- Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 Been there, done that, erased the evidence, blackmailed the witnesses...
At 21:01 21/05/98 -0700, Tom Perrine wrote:
I've been following the "need a better IDENT" thread for a bit, and have some questions and suggestions.
Let's see if we can *really* define what it is we really want, and figure out if IDENT or "son of IDENT" is really the answer.
I've been following the thread too and there's another desire we have for something like IDENT which oddly enough we were considering just a few days ago. We "host domains" for clients for whom we do not provide net access and where on some occassions their access provider will block mail sent "from" the domain we host. E.g. dial up user with provided email "joe@isp.com" get's us to run the domain "joe.com" and wants to use the email "me@joe.com" but can't then send his mail through his access provider for whatever reasons. We then want to help out and allow this user to relay through one of our servers but sure as hell don't want to run an open mail relay. The best solution is to have some trigger that joe can initiate/host that let us know we can aloow mails from a given machine at a given time. The starting point for this was a hook into the pop server which means that any machine that successfully picks up mail via pop get's added to a list with a time stamp - and that the mails server will then refer to this list and let any such machine send mail (say within 15 minutes). What we thought would be much nicer is if Joe ran something sort of simple deamon process which the mail server could query to confirm that he was a valid user - hence the interest in the thread ... Manar
-----BEGIN PGP SIGNED MESSAGE----- If you have started a prosecution in any jurisdiction for a DENIAL OF SERVICE attack on any of your resources, please contact me directly. We've identified the individual (inDUHvidual?) and we're exploring our options. We've been involved in prosecuting intrusions :-), but not a DoS (yet). - -- Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNWr5cxTSxpWcaAFRAQFsWQQAslh8lo93jBpiHlVzcGC3bt7WnVFaXtsl dkJ+jQEYbhygUw1n22BY6O1U8/9QaovkqC4zPIonA98juglhl7I+UY1jrpVYnMRd chKEIHil7mN4eqUxa6uSTsXeQvIpsScXH4ZzV5n3jUQf+8mGU67IDnW7u/I9w7Gn ChJL1B4k8Oc= =rLh8 -----END PGP SIGNATURE-----
You'd probably do alittle better down there, but here in Canada it's considered common mischief and doesn't qualify the CCC's section 342 theft of services clause. Likely a better option though since you can easily prove some kind of damages, but it's hard to convince a judge you lost 1000s when nothing physical was taken. Tim Gibson On Tue, 26 May 1998, Tom Perrine wrote:
-----BEGIN PGP SIGNED MESSAGE-----
If you have started a prosecution in any jurisdiction for a DENIAL OF SERVICE attack on any of your resources, please contact me directly.
We've identified the individual (inDUHvidual?) and we're exploring our options. We've been involved in prosecuting intrusions :-), but not a DoS (yet).
- -- Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000
-----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNWr5cxTSxpWcaAFRAQFsWQQAslh8lo93jBpiHlVzcGC3bt7WnVFaXtsl dkJ+jQEYbhygUw1n22BY6O1U8/9QaovkqC4zPIonA98juglhl7I+UY1jrpVYnMRd chKEIHil7mN4eqUxa6uSTsXeQvIpsScXH4ZzV5n3jUQf+8mGU67IDnW7u/I9w7Gn ChJL1B4k8Oc= =rLh8 -----END PGP SIGNATURE-----
What I don't understand is why you can't just present the IP address, and the time of the mis-behavior to the network owners; they should be able to identify the responsible person from the dial-up authentication (RADIUS or other) logs. Even if there is a complete network behind the dial-up (or ISDN or whatever), there *had* to be an authentication of some sort to establish the connection, or they have bigger problems that will not be solved by a "better IDENT". At worst, they can delegate the problem to whoever authenticated: "Find and solve the problem before we allow any of your connections. If this cuts off several people that's *your* problem. Its your subnet and your account. You are responsible for it. Fix it."
I think the answer to this question is that a LOT of ISP admins don't have the time to handle the flood of complaints that would come about from IRC-based complaints. This is why many of the larger ISP's at some point in time get banned from IRC servers in general... As an example, there are plenty of Netcom users who have made "general IRC attacks" (channel takeovers, nuking users, etc.) and Netcom is banned, as a whole, from a number of servers (or at least was several years ago when last I used IRC). Complaints to Netcom would generally go unanswered because when it came to having time to deal with complaints, IRC ones - which generally come down to a he-said,she-said situation, go ignored. A user can produce "a log of what happened", but give me 10 minutes with vi and I can produce an IRC log that says the Pope pronounced Jesus a pagan wizard. Not that I personally care about IRC Servers' demands (I personally consider them a good idea turned into a hideous waste of bandwidth), but their concern is real, from their point-of-view, and the network admins they need to deal with generally are unresponsive because of the very nature of IRC. Derek
:: Tom Perrine writes ::
I've been following the "need a better IDENT" thread for a bit, and have some questions and suggestions.
Let's see if we can *really* define what it is we really want, and figure out if IDENT or "son of IDENT" is really the answer.
My two cents: IDENT is fundamentally bad for this application for several reasons, a few of which I will enumerate: -- It requires devices in the middle to intercept packets and masquerade as another device, for the purpose of answering IDENT requests. I philosophically find this unacceptable. Some may disagree, but enough will probably agree to prevent this from ever getting to 100% deployment. Packets from my IP address should be from me, and packets to my IP address should get to me. -- It provides no way of knowing the source of the information. That is, if I IDENT you, I might be getting an easily faked response from your PC or a not-so-easily-faked response from some device at your ISP. I have no way of knowing which is which. -- IDENT was indended to provide port level information -- that is, what user does Machine X think it using Port Y on Machine X. We have to give this up if we go with forged IDENT responses. It would be better to leave this in place, and implement a new means of getting the new information that we now want, which is: Who does the owner of IP address A.B.C.D think is currently using that address. (Port-level information is, of course, useless on a multi-user machine ... but the "Server End" of a connection has no way of knowing if the client-end is multi-user or single-user.) ISTM that a much better way to accomplish this would be TXT records (or, if we want to make this more complicated, some new RR type) associated with the IN-ADDR.ARPA domain. Using dynamic updates and very small TTL, the ISP can change these as the address is assigned to a new user. This lets you reasonably get the IP Address Owner's opinion of who has that IP address, without giving up anything we already have, and without creating any ambiguity as to the source of the information -- IDENT comes from whoever owns the machine, IN-ADDR.ARPA comes from whoever has the IP Address Space. - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
Brett Frankenberger writes:
:: Tom Perrine writes ::
I've been following the "need a better IDENT" thread for a bit, and have some questions and suggestions.
Let's see if we can *really* define what it is we really want, and figure out if IDENT or "son of IDENT" is really the answer.
My two cents: IDENT is fundamentally bad for this application for several reasons, a few of which I will enumerate: -- It requires devices in the middle to intercept packets and masquerade as another device, for the purpose of answering IDENT requests. I philosophically find this unacceptable. Some may disagree, but enough will probably agree to prevent this from ever getting to 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? Thats examples of connections your clients think are direct to the internet. But they don't know that.
-- It provides no way of knowing the source of the information. That is, if I IDENT you, I might be getting an easily faked response from your PC or a not-so-easily-faked response from some device at your ISP. I have no way of knowing which is which.
Whats the problem with this? I think you can trust your upstream not to be intercepting ident requests not sent to dynamic PPP clients..
-- IDENT was indended to provide port level information -- that is, what user does Machine X think it using Port Y on Machine X. We have to give this up if we go with forged IDENT responses. It would be better to leave this in place, and implement a new means of getting the new information that we now want, which is: Who does the owner of IP address A.B.C.D think is currently using that address. (Port-level information is, of course, useless on a multi-user machine ... but the "Server End" of a connection has no way of knowing if the client-end is multi-user or single-user.)
What difference does this make on a single-user machine? or a multi-user (eg linux) machine? Or, more specifically.. on a dynamic IP client? It was used to get the userid of who owned a port on a machine back when these machines were trusted UNIX boxes and users couldn't change their ident. The question here is 'trust'. Why bother using ident in ANY code anymore if it can't be trusted? Yet it still is. So move the trust demarcation point to where the user has no control over it. Remember, if its a static IP or network client, you don't proxy ident requests - since the static IP is the demarcation point of trust. They can change their ident, but no matter what, their IP or network still stays the same.
ISTM that a much better way to accomplish this would be TXT records (or, if we want to make this more complicated, some new RR type) associated with the IN-ADDR.ARPA domain. Using dynamic updates and very small TTL, the ISP can change these as the address is assigned to a new user. This lets you reasonably get the IP Address Owner's opinion of who has that IP address, without giving up anything we already have, and without creating any ambiguity as to the source of the information -- IDENT comes from whoever owns the machine, IN-ADDR.ARPA comes from whoever has the IP Address Space.
And rewrite all the software that uses ident? DNS wasnt meant to do that. You mean that people have to update their DNS servers to support the new extensions? And upgrade libraries to support this? You're now running two seperate services for much the same thing - identifying usernames. ident was originally designed with multiuser secure UNIX machines in mind. With the advent of ppp stacks and users having their own induvidual IPs, that notion is no longer valid, since the user has control over the ident response. Ident still wins out. Setup transparent redirection to a local box (or boxes depending on your network topology) which can answer the ident request. Only enable transparent redirection *TO* the dynamic IP pool, and not all IPs, and it doesn't affect your static IP clients. Set it up, and forget about it. If the NAS vendors adopt this, well great.. even less work to do. All that is left is for the people who WANT to do this, to agree on a hash algorithm. Adrian
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?
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@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 long. 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 authenticated. 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. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Thu, 21 May 1998, Tom Perrine wrote:
The desire here is essentially for a real-time authentication for ad-hoc users from administrative domains over which you have no control, which you may not "trust", and for which the user identification (username/"nick") AND the IP address are selected either by the user (the nick) or by the domain (dynamic IP addresses).
Not authenticate. Authenticate would imply that the data being returned is reliable. All I think that people are asking for here is a unique identifier of that user, that can be depended upon to return the same result every time a query regarding that user is sent. That's all. It doesn't need to be a username, or anything personally identifying; in fact, it -should- be something obscure...the idea to use a hash of the username, for instance. Just something that uniquely identifies the user between sessions to remote networks. Using ident might be a poor choice for this, because of some people wanting to operate their own ident mechanisms. Perhaps a new scheme, which from the outset is "blessed" to be intercepted as it passes through a terminal server, would be more politically correct.
What I don't understand is why you can't just present the IP address, and the time of the mis-behavior to the network owners;
Laziness and lack of tools on the part of many ISPs. While a timestamp and IP address can reliably and uniquely identify a user to an ISP, it can't do so all by itself...someone at the ISP needs to take the time to correlate that IP address and timestamp in logs. Many ISPs, as unfortunate as it is, have no tools to perform quick lookups like this. Thus, many complaints may fall on deaf ears, due to the unwillingness of the ISP to investigate them (which in turn is due to their lack of tools or skills to retrieve this information quickly). Not that it's an excuse. But it's a rationale. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 10:05pm up 1 day, 23:10, 3 users, load average: 0.01, 0.03, 0.00
On Thu, May 21, 1998 at 12:23:01AM -0400, Jon Lewis wrote:
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?
RADIUS. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
participants (19)
-
Adrian Chadd -
Brett Frankenberger -
Christopher Neill -
Dalvenjah FoxFire -
Daniel Reed -
Dean Anderson -
Derek Balling -
Edward S. Marshall -
Ehud Gavron -
Jay R. Ashworth -
Jon Lewis -
Manar Hussain -
Paul Mansfield -
Phil Howard -
Steve Sobol -
Studded -
Tim Gibson -
Tom Perrine -
Troy Davis