RE: User Identity issues - Business Domain

[Avi Lior <avi@bridgewatersystems.com>]

Hi

Originally when first being involved with this issue the need we saw was
that some intermediaries needed to know that a particular AAA transaction
was associated with a given user.  For example, the intermediary was
responsible for ensuring that the user only logged in once to the network.
Methods such as EAP that can hide the identity of the subscriber created
problems to these intermediaries.

As the I-D suggests adding a UserAlias which the home operator asserts that
it belongs to a given subscriber without revealing the subscribers identity
serves that purpose.

We did discuss putting this identity in the User-Name (User-name rewrite but
we felt that user-name re-writing was already overloaded and not well
specified)  Hence the we thought that a new attribute would be used.

Accounting or billing needs would also benefit but only when this is done
outside the context of the home network.  In the home network Class
attribute can be used.  Accounting Intermediaries could resolve the
User-Alias by interacting with the home network which would then provide the
billing entity for those records.
 
I think the routing of Access-Request messages and Accounting messages is
really a separate issue.  

User-Name re-writing could be the way to solve the routing problem or not --
Unfortunately the User-Name attribute is starting to to get somewhat
overloaded.  I guess in hindsight it would have been better to leave the
User-Name attribute to serve as strictly the User-Name attribute (and
perhaps an Alias) and have another attribute used for routing purposes.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Wednesday, June 16, 2004 10:57 AM
> To: radiusext@ops.ietf.org
> Subject: RE: User Identity issues
> 
> 
> Bernard Aboba writes...
> 
> > As Blair notes, there are cases where the Accounting data needs to 
> > follow the same path as Authorization, and User-Name rewriting can 
> > break that.
> 
> I generally understand that the issue is multi-party 
> brokering/mediation.  There are multiple entities that need 
> to get their "cut" of the revenue associated with the user's 
> session.  Does that imply that the accounting requests need 
> to traverse the same path as the authentication requests?  
> Does each entity need to maintain their own accounting logs, 
> or do the entities trust one central clearing house to give 
> then their fair share of revenue?  If the latter is true, 
> then it would seem that accounting requests could be sent 
> directly to the central clearing house, along with some 
> indication of the list of parties involved, so that the 
> revenue allocation can be calculated and distributed.
> 
> I guess what I'm asking is that the business-domain problem 
> be clearly defined before we attempt to create a 
> protocol-domain solution that meets the business requirements.
> 
> --  Dave
> 
> 
> 
> --
> 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/>