[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Hi Lothar,
I suggested the use of the billing-identity attribute for "tracking" in
response to the requirement stated by Klaas Wierenga:
"Some universities want to know the real identity of a user in case of
abuse" which he made in the context of the following NAI:
"anonymous@university-a.nl" which implies that the NAI can not be used
for this purpose.
The point is, that I do not beleive that these universities require the
real identity "in real time" - rather I assume it would be perfectly
sufficient to be able to track down the real identity of an abusive
anonymous user after the fact of abuse. In this case, the university
would have to request the resolution of the anonymous user-name from the
home network providing evidence that the request is legitimate.
Actually, currently this is exactly the path we are following. We have a
project (http://www.sourceforge.net/projects/usertracking) that tries
to gather all the relevant data to do this. And I agree completely with
you that this is in general the desired behaviour. However I believe
there are 2 buts:
- Sometimes you do want to track down realtime the abusive user, if some
user from university-a is sending lots of spam via university-b, are you
going to shutdown all users from university-a (since they are all
anonymous@university-a to university-b) or just badguy@university-a?
Just as a user has the right to only connect via a provider that guards
their privacy I believe a visited institution should have the right to
refuse anonymous users, it's after all their infrastructure they are
giving access too.
- Universities or other entities may be in some kind of federation where
they agree to share user data with eachother. Either the low level
attributes of a user or some aggregated form of it.
As I mentioned before, I am not sure whether this kind of authorisation
should be carried on this layer or on some other like EAP. I think
however that there is value in giving the *possibility* to reveal the
real identity of a user, this 'real identiy' may also be some kind of
pseudonymous id, but it is useful to be able to distinguish individual
users.
In my mind, the real problem is to find the right balance between the
valid privacy and security requirements of the user, and the valid
privacy and security requirements of the home-network povider, the
intermediaries, the access provider and the Internet at large.
agreed
A privacy conscious user may contract only with a home-network that
cares about privacy and resolves his true identity only to a legimitate
requester providing strong evidence of abuse and of course only on the
basis of local legislation of the home network anyway.
By the way: A privacy conscious home-network provider may not want to
expose his customer's clear-text user-names to access-networks and
intermediaries.
Yes, within the TERENA (the 'club' of european research and education
networks) Taskforce Mobility (http://www.terena.nl/mobility) we try to
do this by defining policies for the european toplevel RADIUS-server,
the country level toplevel server and the institutional RADIUS-servers.
Here we try to state what users can expect and also what 1 NREN can
expect from the other NRENs.
In a nutshell, my proposal was actually aimed at avoiding the below
cited horror scenario that Jari has put in the context of my name (much
to my dislike):
Actually I'm trying to do the same. I have noticed that candidate
participants to this hierarchy often are afraid they lack the tools to
exclude abusive users/institutions and countries. By providing them the
tools to exclude whoever they feel like the reality is that they don't
bother to take any of these measures, just having the tools is enough
insurance.
Klaas
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>