Re: Chargeable-User-Identity

[Tomasz Wolniewicz <twoln@umk.pl>]

Dave Nelson wrote:
>> Since the visited network does not bill us for our users, we have no
>> reason to know where our user is, but more importantly, we would not
>> want this information to travel in the open.
>>     
>
> OK, that sounds a bit paranoid.  If the user wants to maintain true
> anonymity, they will need to use EAP methods with an anonymous outer
> identity.  In that case all that can be detected is the number of users
> visiting a particular university on a particular day, not their identity.
> I'll admit there is *some* information there, but if you're going to perform
> traffic analysis of eduroam traffic, that kind of information is going to
> come out anyway.
>   
It *is* paranoid. I quite agree. Personally, I do not mind if people
know where I am. But there are plenty of paranoid people out there and
we do not want to loose the potentially useful thing like an opaque user
identity by doing something that will be challenged.
>   
>> We want to have the Operator-Name (or equivalent) for just one reason -
>> when we generate the CUI we want to do something like:
>> md5(User-Name:Operator-Name:local_salt)
>>     
>
> Sure.  You don't need it to be the actual name of an operator.  I
> understand.  What I'm challenging is whether it's acceptable practice to
> overload an existing RADIUS attribute to carry a new data object.  Including
> a "unique but meaningless salt" in an attribute defined to hold a human
> readable operator name sounds attribute overloading to me.
>   
But this is exactly what I would want to avoid.

Frankly, I think that this  discussion is going in the wrong direction.
We definitely would not want to use any attributes in a way that they
have not been designed for.

Perhaps I should repeat our case.
We would like to use the Chargeable-User-Identity attribute and this
seems to fall within its expected usage.
We have found out that we would need some visited-network identifier to
be fed into the CUI generation algorithm.
While looking at that, we have also realised that this network
identifier could be relevant also for other possible CUI applications
and this is why Stefan asked the list. Then the Operator-Name was
suggested and this looked like just the thing. But now it looks like we
would want to overload the attribute, so probably we are back to square
one. :(
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, but perhaps the future will show the
need for yet another attribute for this purpose.

Of course there is an option of using a new VSA and keep it all internal
to eduroam.

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