Re: NAI decoration: User Identity issues

[Barney Wolff <barney@databus.com>]

On Thu, Jul 15, 2004 at 12:06:36PM -0700, Bernard Aboba wrote:
> > 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.

I guess the question is whether there is a long-term one-to-one relationship
between User-Alias and the user's "true" identity.  If there is, then
attackers can gain information of some value by correlating different
accesses resulting in the same User-Alias.  If not, then indeed User-Alias
is no different than Class.

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

I think the resistance is that Class is opaque.  But if User-Alias is
opaque too, in the sense that the server can put anything in it, that
might change from one access to the next for the same user, then User-Alias
is not useful for aggregating session statistics.

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

Agreed.
Barney

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