Is there any reason that the roaming consortium or the local access network *needs* to know the *true" user identity, in case of the authenticating user (or the home network) requesting privacy ?
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 09:13
An: Barney Wolff
Cc: Bernard Aboba; Avi Lior; radiusext@ops.ietf.org
Betreff: 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.
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.
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, (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 (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 :-)
--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/>