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...