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

[Jari Arkko <jarkko@piuha.net>]

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