Re: Chargeable-User-Identity

[Tomasz Wolniewicz <twoln@umk.pl>]

David B. Nelson wrote:
>> I still think that providing an option for the Operator-Name
>> to carry something Operator-Name related, but otherwise not
>> obvious, could be useful in various applications...
>>     
>
> In other words, an obfuscated name for the operator.  From a security
> (privacy protection) perspective, simply using an obfuscated name for each
> visited network won't provide very much protection if the same name string
> is used in each request, as the operator's name can likely be derived by
> correlating the source of the messages with the obfuscated name.  If the
> messages are originating from an IP address assigned to foo.edu, it's a safe
> bet that the obfuscated name stands for Foo University.  :-)
>   
Not quite :). The messages carry the NAS-IP-Address, which (in very many
cases) can be something like 192.168..,
but I admit that this can be a give away. Since the messages pass
thorough proxies the actual source of the request is lost on the way.
> I think you may want to create a threat model to enumerate the adversaries
> that can discover and misuse personal information, and then see how to
> design the protocol to address the attack opportunities presented in that
> threat model.
>   
Let's say that we want to use a best effort here. We do not want to
transport and collect data that we do not need for the system to work.
The current eduroam structure is not perfect in many respects. The next
model should be direct server connections based on RadSec, without any
proxy structure. In this model, the Operator-Name will not be needed, as
the peers will know each other and the AAA server will be able to
generate the CUI differentiating between the networks. Therefore we are
discussing a temporary model here, however this temporary state may take
several years.

RADIUS over UDP is not a very secure transport, while RadSec will be. So
we do not want to invest too much time designing something perfect, when
we already have the candidate.

While I am at it, I should perhaps add, that the entire project is based
on CUI implemented in the server and not in the NAS. With help from Alan
DeKok we have a working FreeRADIUS implementation. This way we are able
to introduce CUI on a large scale, in spite of the lack of NAS-based
support.

Tomasz

-- 
Tomasz Wolniewicz    
          twoln@umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576


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