RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Well, CUI is not needed by the home network.  It's needed by entities
outside the home network. Class can't be used by these.

We have given lots of examples, and we belive that it is understood that
intermediaries and visited network need CUI in certain business roaming
cases.

The authors of the draft understand Class and we are not trying to reinvent
this attribute.

Avi

> -----Original Message-----
> From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> Sent: Monday, December 20, 2004 11:50 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Jari Arkko; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org
> Subject: Re: Scope of applicability for CUI
> 
> 
> Hi,
> 
> On Mon, Dec 20, 2004 at 10:34:30AM -0600, Nakhjiri 
> Madjid-MNAKHJI1 wrote:
> 
> > Can you explain it a bit more for the less sophisticated?
> 
> Well, a suggestion was made that a. CUI could be learned at 
> the Access-Accept, and b. that it would be a session 
> identifier to allow the /home/ AAA and the NAS to correlate 
> their accounting records.
> 
> To me, this exactly describes Class; the home AAA is the 
> first source of the accept after, and thus defines Class; and 
> it can use the Class received in accounting records to 
> correlate them with the unique access value it generated 
> earlier in Access-Accept.
> 
> The value can be either unique per login, or unique for a 
> certain ad-hoc identity that allows a number of minutes, or 
> volume during a certain timeslot.
> 
> At any rate, the entity that ultimately charges the user (the 
> home AAA, that vouches for the user's credentials) defines 
> it, and it's present in all accounting about this user.
> 
> So, the /only/ reason for CUI would be if some home AAA 
> wishes to accept a user, while expecting an intermediate 
> AAA's owner to bill the user, and it wants to convey the 
> entity to bill to the intermediate AAA.
> 
> That such a scheme with distinguishable CUIs can be easily 
> compromised 
> by a non-trusted NAS owner is conveniently ignored. 
> 
> I'm of the school of belief that you should only send an 
> accept for a user if you're willing to foot the bill for him. 
> And for all such circumstances, Class works fine, and cannot 
> be forged by the NAS owner or any intermediate proxy owner if 
> properly generated by the home AAA.
> 
> Kind regards,
> 
> 
> Emile.
> 
> > -----Original Message-----
> > From: Emile van Bergen [mailto:emile@e-advies.nl]
> > Sent: Saturday, December 18, 2004 12:19 PM
> > To: Jari Arkko
> > Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; 
> radiusext@ops.ietf.org
> > Subject: Re: Scope of applicability for CUI
> > 
> > Hi,
> > 
> > On Sat, Dec 18, 2004 at 11:21:13AM +0200, Jari Arkko wrote:
> > 
> > > This also implies that the CUI is something that can be 
> learned very 
> > > late in the process, perhaps even as late as in the Access-Accept.
> > > 
> > > By the way, what would be the meaning of CUI for "pay as you go" 
> > > type of approaches, e.g., micropayments or the like over 
> EAP? There 
> > > might not be any billable user identity; the only thing 
> that could 
> > > be provided in those cases is some kind of a session 
> identifier so 
> > > that the home AAA and the NAS can correlate their accounting 
> > > records.
> > 
> > To paraphrase Henry Spencer: those that do not understand Class are 
> > condemned to reinvent it -- poorly.
> > 
> > Cheers,
> > 
> > 
> > Emile.
> > 
> > -- 
> > E-Advies - Emile van Bergen           emile@e-advies.nl      
> > tel. +31 (0)70 3906153           http://www.e-advies.nl    
> -- 
> E-Advies - Emile van Bergen           emile@e-advies.nl      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

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