RE: Chargeable-User-Identity

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Tomasz Wolniewicz writes...

> ... user blacklisting based on and observed misbehaviour
> is just one of the use cases for CUI in eduroam, but there
> are more.

It's often very useful to enumerate and explain all the relevant use cases.

> 3. Promoting the user access rights. A positive example,
> for a change.  Suppose we gave an official guest at the 
> university and we want to provide him with some extra 
> services. CUI will allow us to place the user in a special
> VLAN and allow printing, for instance. This is a lot
> easier then creating a local account and setting up the
> user access based on that.

You're going to set up a local "shadow" user authorization database, keyed
on CUI values, to add, remove and modify user access permissions?  Hmmm.
Good luck managing that.  You potentially have no way to link the real user
identity to a CUI at the remote site, but you think it can be useful for
creating a supplementary authorization service?  I can foresee all sorts of
operational problems with such a scheme.  As I say, good luck with that.  I
see no direct conflict with RADIUS services or attributes.  It's just that
sometimes CUI can only be related to a specific session, and its
packet-level behaviors, and not to a person.



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