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

["Roy Albert" <ralbert@ipass.com>]

In the case where someone's credentials have been compromised, it is
necessary to have a unique per-user identifier to help detect this (much
as credit card companies do) by monitoring for unusual activity. This is
not quite covered by your points below.

-Roy

Roy D. Albert
ralbert@ipass.com
 

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Friday, July 16, 2004 11:27 AM
To: Bernard Aboba
Cc: 'radiusext@ops.ietf.org'
Subject: 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/>



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