RE: NAI decoration: User Identity issues

[Avi Lior <avi@bridgewatersystems.com>]

Hi Barney,

See my comments inline:

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Thursday, July 15, 2004 3:56 PM
> To: Bernard Aboba
> Cc: Avi Lior; Blair T. Bullock; radiusext@ops.ietf.org
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> 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.

This is up to the home operator to determine.  He can put in the User-Alias
a long lived identity or he can choose a short lived on so that it becomes
more difficult to correlate between the User-Alias and the true identity.

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

Well Class is not usable because one the specification say that it should
not be used but also it can contain other things in it so that it can not be
used as a User-Alias.

For example on one invocation:
Class=123.45.234.134,JOE234
On another AAA transaction on behalf to the same user:
Class=789.34.453.122,JOE234

So although it's the same user the class attribute has some different values
in it.

The only way that class could be used is to specify what should go in it and
how it should be formatted. I don't think we want to go there.


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