[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NAI decoration: User Identity issues



> The intent of User-Alias in the draft (note the draft calls it User-Alias as
> opposed to Billable-Identity) is to allow intermediaries to associate this
> AAA transaction with an actual User without revealing the identity of the
> user.  It's a handle to a user.

So this atribute is only for use by proxies?

> Note the draft allows the home network to put anything it wants in there
> including the true identity of the user.

If there is no guarantee that this is a billable identity, it is
indistinguishable from the Class atribute.

> Class attribute would not work because Intermediaries can't use the class
> attribute generated by a server.

Why can't they use it? There is no obstacle.

> The user-name can't be used because in an Access-Request it may contain no
> useful information and in an Access- Accept it could be completely
> re-written by intermediaries.

No. The User-Name attribute is not re-written by intermediaries when sent
in an Access-Accept.  If it were, then Blair's problem wouldn't exist
(mis-routing), and there would be no need for another attribute.

Bottom line:  User-Alias does not appear to meet the requirements of the
problem that has been posed, and seems to introduce lots of new issues.


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