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