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

[Avi Lior <avi@bridgewatersystems.com>]

Hi Jari and Barney,

See comments inserted

> -----Original Message-----
> From: Jari Arkko [mailto:jarkko@piuha.net] 
> Sent: July 16, 2004 3:13 AM
> To: Barney Wolff
> Cc: Bernard Aboba; Avi Lior; radiusext@ops.ietf.org
> Subject: Privacy (Was: Re: NAI decoration: User Identity issues)
> 
> 
> Barney Wolff wrote:
> 
> > I guess the question is whether there is a long-term one-to-one 
> > relationship between User-Alias and the user's "true" identity.  If 
> > there is, then attackers can gain information of some value by 
> > correlating different accesses resulting in the same User-Alias.

Absolutely.  
 
> This is an interesting issue. There is a very valid reason 
> for employing privacy at the network access protocol level 
> (say, in 802.1X/EAP/NAI). This is primarily to avoid being 
> exposed to other clients on the same network. Not so much 
> against the service provider.
> 
> But I think there is also interest in ensuring some level of 
> protection against the service provider, or at least parts of 
> it. Clearly, the home network is going to know who you are. 
> Maybe even the roaming consortium and the local access 
> network. But I'd rather not reveal my true identity to the 
> access point on the coffee shop wall. It is in an insecure 
> environment, often uses a wireless uplink or other weakly 
> protected physical medium. And if it runs RADIUS, the chances 
> are that its not running ESP so the contents of any new AVP 
> being returned from the home network would be relatively 
> easily visible to those who wanted to look.
> 
> On the other hand, there is also a valid business reason for 
> some intermediaries to relate different sessions to the same 
> entity so that fixed price model can be applied.

Yes this is the requirement that we received.  Some intermediaries are
indeed charged with ensuring policies such as the user is only logged in
once.
 
> One way to resolve these conflicting requirements is to (a) 
> explain that the attribute (be it Class or something new) is 
> to be returned with fixed contents only if the particular 
> business situation requires it, 

Agreed.  The operator will put it in if it needs it in.

>(b) in the proxy, strip off 
> the attribute from the packets going to the NAS and insert a 
> Class attribute with opaque and not-fixed contents instead, 
> and 

It is possible that the proxy may know that the User-Alias is not needed
past a particular point.  It could strip it off and insert it back in
accounting.  This is a normal behavior for some proxies already.  How it
does it is not important.  It could use class. 

>(c) when the accounting request comes back from the NAS, 
> take away the inserted Class and replace with the original attribute.


> But this is complicated. Feel free to suggests a more optimal 
> scheme :-)

Proxies already do this type of operations. It is complicated and may not be
necessary if the User-Alias contained a short lived handle to the user.
Long enough to support the business needs but not long enough to function as
a user identity.  I think if security was an issue that is the way to do
this.

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