RE: NAI decoration: User Identity issues

[Avi Lior <avi@bridgewatersystems.com>]

Hi Barney,

Let me offer an explanation.

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.

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

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

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.

Hope this helps,

Avi



> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Thursday, July 15, 2004 1:53 PM
> To: Bernard Aboba
> Cc: Blair T. Bullock; radiusext@ops.ietf.org
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> On Thu, Jul 15, 2004 at 09:38:12AM -0700, Bernard Aboba wrote:
> > 
> > In addition to the billable identity attribute though, I 
> think we will 
> > probably need to explain the logic behind it and provide 
> advice on how 
> > User-Name and Class can/should be used, to make sure people 
> understand 
> > the issues.  That might go in the "RADIUS issues and 
> solutions" draft.
> 
> I'm a little confused.  Can someone state clearly what 
> problem is being solved by Billing-Identity that would not 
> just as well be solved by leaving User-Name alone and putting 
> any altered name in Class?  Is it just that people perceive a 
> need for entities other than the home authentication and 
> accounting servers to know the "true" identity of the user?  
> If that were all, I'd push back, asking why it's anybody's 
> business other than those home servers'.
> 
> If Billing-Identity is intended for detailed cost 
> accumulation, perhaps it should be called 
> Billing-Accumulator-Id instead.  But in any case, it would 
> seem that it has meaning only within the scope of the server 
> that generates it; otherwise, ford.com's server can routinely 
> generate Billing-Identities that say @chevy.com.  Presumably 
> that's why we don't want to overwrite the original User-Id.  
> Is leaving User-Id alone enough to provide auditability, or 
> should we introduce a Diameter-style audit trail that records 
> how the Access-Accept got back to the NAS?
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via 
> the 'Net.
> 
> --
> 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/>
> 

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