Jari,
please note that there appears to be a serious misunderstanding of my statements.
In no way did I propose anything that would compromise privacy - in the opposite I am proposing that the attribute "privacy-protected-identity"/"billable identity"/"user-alias" may be considered *essential* to enable privacy by means of using an anonymous NAI for routing the authentication request and a billable-identity only resolvable by the home network for accounting.
I never stated what you linked with my name:
"Get the user's "trackable" identity for the access
network so that fraudulent users can be tracked down and
acted upon without involving home operator (possibly in
another timezone and government etc)."
The opposite is true: Provide a "billable-identity"/"privacy-protected-identity" which on one hand does not allow any tracking by any intermediary or access-network under normal circumstances, but on the other hand allows billing (normal circumstances) and - in case of abuse, i.e. in rare circumstances - tracking down the abusive user.
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.
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.
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.
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):
Jari wrote start:
> No hotspot access in the Big Brother
> Republic unless your home ISP sends your passport number,
> snail address, and biometric data in an Access-Accept. Hmm...
> I think we are going to get here sooner or later :-(
Jari wrote end.
Business reality appears to me to be very different: The home-network may NOT want to provide any resolvable identity data, because they may be afraid that someone else in the food-chain could steal their customer.
Best Regards, Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Jari Arkko
Gesendet: Freitag, 16. Juli 2004 20:27
An: Bernard Aboba
Cc: 'radiusext@ops.ietf.org'
Betreff: Re: Privacy (Was: Re: NAI decoration: User Identity issues)
Bernard Aboba wrote:
> It seems like everyone is seeing a different application for the
> attribute
> -- and that is why it is so hard to come to agreement on the problem
> statement.
Right. I think we have seen the following applications
or individual requirements:
1. Lothar: Get the user's "trackable" identity for the access
network so that fraudulent users can be tracked down and
acted upon without involving home operator (possibly in
another timezone and government etc).
Note 1: This requires some sort of real identity, just
stable but opaque identifier would be insufficient. Or
its sufficient for denying further service, but not for
taking some action against the user.
Note 2: I'm not sure I want to think about the privacy
implications of this. No hotspot access in the Big Brother
Republic unless your home ISP sends your passport number,
snail address, and biometric data in an Access-Accept. Hmm...
I think we are going to get here sooner or later :-(
2. Avi: Controlling a policy for the user, such as limits
on the number of simultaneous sessions per user.
Note 3: This is only useful if the home network's policy
is different from the access network's policy. For instance,
home network has unlimited access while access network
allows at most one access at a time.
Note 4: Even if the policies are different, home networks
could still apply the policy on a per-visited network
basis. This could be problematic for provisioning,
however.
Note 5: Even if the access network applies the policy,
it has no guarantee that the identity given to it is
correct. A fraudulent home network could claim that
all sessions come from a different user, whereas in
reality they actually are from one user. Does this
matter?
3. Farid: Retrieve real identity when tunneled or
pseudonym-based EAP methods are used.
4. Blair: Correlate accounting records with
an identifier so that fixed price
billing models can be applied at a service
provider.
Note 6: This requires a stable (~ month)
identity, but it does not have to be a "real"
identity. Compare to requirement 1!
5. Farid: Provide a new format to carry non-NAI
identities, such as IMSI or E.164 numbers.
6. Farid: Provide an alternate, second identifier
in addition to the NAI.
Note 7: I am presuming that this is a requirement.
Is it?
7. Jari: Carry a privacy-protected "handle" instead
of the "real" identity when returning User-Name/
Class/User-Alias.
Anything else?
--Jari
--
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/>