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

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

We do this today as an intermediary. The home networks are mostly
enterprises and have no facilities for doing this. 

-Roy

Roy D. Albert
ralbert@ipass.com
 

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Friday, July 16, 2004 11:48 AM
To: Roy Albert
Cc: radiusext@ops.ietf.org
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)


Thanks. Would this be done by the home networks or the
intermediaries? Are you willing to say if something
like this is currently done in your organization,
acting as an intermediary?

--Jari

Roy Albert wrote:
> 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/>