[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scope of applicability for CUI
- To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
- Subject: Re: Scope of applicability for CUI
- From: Emile van Bergen <email@example.com>
- Date: Mon, 20 Dec 2004 17:50:14 +0100
- Cc: Jari Arkko <firstname.lastname@example.org>, 'Avi Lior' <email@example.com>, "'Nelson, David'" <firstname.lastname@example.org>, email@example.com
- In-reply-to: <EBF631554F9CD7118D0B00065BF34DCB09EA1612@il27exm03.cig.mot.com>
- Mail-followup-to: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>, Jari Arkko <firstname.lastname@example.org>, 'Avi Lior' <email@example.com>, "'Nelson, David'" <firstname.lastname@example.org>, email@example.com
- References: <EBF631554F9CD7118D0B00065BF34DCB09EA1612@il27exm03.cig.mot.com>
- User-agent: Mutt/1.3.28i
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
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.
> -----Original Message-----
> From: Emile van Bergen [mailto:firstname.lastname@example.org]
> Sent: Saturday, December 18, 2004 12:19 PM
> To: Jari Arkko
> Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; email@example.com
> Subject: Re: Scope of applicability for CUI
> 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.
> E-Advies - Emile van Bergen firstname.lastname@example.org
> tel. +31 (0)70 3906153 http://www.e-advies.nl
E-Advies - Emile van Bergen email@example.com
tel. +31 (0)70 3906153 http://www.e-advies.nl
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.