|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Suggestion for improved identD
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 ([email protected]) | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000
Been there, done that, erased the evidence, blackmailed the witnesses...
|