Re: Privacy (Was: Re: NAI decoration: User Identity issues)

[Jari Arkko <jari.arkko@piuha.net>]

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