RE: AW: -01 version of Chargeable User Identity

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hi Barney,
Thanks for discussion.  Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Friday, October 22, 2004 11:52 PM
> To: Adrangi, Farid
> Cc: Barney Wolff; Emile van Bergen; Lothar Reith; 
> radiusext@ops.ietf.org; Bernard Aboba
> Subject: Re: AW: -01 version of Chargeable User Identity
> 
> 
> On Fri, Oct 22, 2004 at 03:32:38PM -0700, Adrangi, Farid wrote:
> > 
> > No, the NAS is not going to bill the end-user directly.  
> But, it could
> > use a unique identity (known by the home network) that can 
> be associated
> > to a session, for possible charging disputes in future.  In 
> general, a
> > unique identity (known by the home network) is useful to all parties
> > involved in *roaming* transaction for correlating the 
> authentication and
> > accounting packets.  I think we all are in agreement on 
> this point.  Now
> > whether or not this can be addressed by Class(25), 
> UserName(1), or a new
> > attribute CUI is under debate here.  On use  of Class(25) attribute
> > (which mostly discussed in this thread), it does not 
> address the problem
> > completely as its content opaque and cannot be interpreted by the
> > entities outside the home network.  Of course, in roaming 
> situations,
> > where there is a bilateral agreement between parties on use and
> > interpretation of the Class(25) attribute, then it works.  
> But, we don't
> > think bilateral agreements scale in a complex global roaming.   
> 
> Whoa!  There are several assumptions here that I don't think are
> universally shared (if only because I don't share them :).
> 
> 1.  How does the unique identity help in charging disputes?  If the
> parties don't trust each other, how is an unverified identity asserted
> by the home server going to improve things?
> 

There has to be some sort of trust relationship between the parties.
The unique identity (known to the home network) would help when the
user's identity is not exposed to the local and intermediaries outside
the home network due to use of specific methods with identity protection
(e.g., EAP-PEAP or EAP-TTLS,  EAP-SIM, and EAP-AKA).  


> 2.  There is no need for end-to-end bilateral agreements no matter
> how complex the roaming.  How can it possibly make sense for the
> billing to take a different path than the access-request and
> accounting packets take?  The whole problem is people trying to
> shortcut that flow, and CUI or not that will just dissolve into
> profit-destroying billing disputes.
> 

It seems that you misunderstood me.  I do agree with your point that it
does not make billing to take different path than access-request.  I
don't think I ever suggested otherwise!  


> 3.  An opaque Class is every bit as good as CUI as evidence that the
> home server did indeed send Access-Accept.  It's the home server owner
> that needs to be convinced, and in that sense opacity is a 
> plus, because
> it can be arranged so that neither the NAS nor any proxy can fake or
> replay a Class, if the home server is sufficiently paranoid.
> 

Then, how can the Local and intermediary networks enforce usage policies
(e.g., a limit on simultaneous sessions) per user basis if they are not
supposed to look at or interpret the content of the class attribute, and
if the user's identity is not exposed to them in UserName(1)?  


> 4.  If, on the other hand, the home server owner is going to 
> claim that
> no Access-Accept was sent and yet it's been billed for service, CUI
> is no use, because an evil NAS or proxy can indeed replay one.  Do we
> want to introduce asymmetric crypto to provide non-repudiation?  Oy.
> 

I think there is a little bit disconnect on the intent of the CUI here.
The home server and NAS are business entities and therefore some
business ethics and trust are expected here.  The main intent of CUI is
to help entities (involved in the roaming transaction) outside the home
network to identify a user's session by an identity known to the home
network.  


> > The proposed CUI attribute is optional, hence it should be 
> used where
> > there is a need for it.  In situations where the class(25) attribute
> > works fine, no need to introduce CUI.  
> 
> Yes.  The problem is that 2865 says that both server and 
> client MAY ignore
> unknown attributes.  The clear implication is that some may not. 
> In
> retrospect, granting that flexibility was unwise.  My own 
> implementation
> ignores unknown attributes as a client. As a proxy, it passes unknown
> attributes in requests and strips unknown attributes in 
> responses.  That's
> not clearly wise in the general case but correct in its particular
> application.
> 

When you say "my implementation", I assume you are referring to a
commercial implementation currently being deployed.  Right?  Just for my
own curiosity, why passing unknown attributes in requests but not in
responses -- what is the logic behind it?

Anyhow, do you think this problem is specific to CUI?  Or, is it a
general problem when a new attribute is introduced?

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