Re: AW: -01 version of Chargeable User Identity

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hello,

On Wed, Oct 20, 2004 at 11:44:05AM -0400, Barney Wolff wrote:

> On Wed, Oct 20, 2004 at 07:20:40AM -0700, Bernard Aboba wrote:
> > 
> > The other issue is whether the NAS supports CUI, and if so, what it will
> > do on receipt of an Access-Accept where CUI is not present.  My
> > understanding is that CUI will typically be required by the NAS, at least
> > for sessions where privacy is invoked.  Without CUI, there may be no way
> > for the NAS to know that has a valid billable identity prior to providing
> > service.  So it seems that the NAS would need to treat an Access-Accept
> > without CUI like an Access-Reject.  There is some precedent for this in
> > RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
> > unimplemented Service-Type this way.
> 
> I think this is not a real issue, at least for the NAS.  After all, the
> NAS (perhaps with proxy help) managed to get the Access-Request to a
> server that was willing to -Accept.  The bill must go to the organization
> responsible for that server.  Whether the server can then bill some
> individual/organization is the server's problem, not the NAS's.
> 
> Surely as a matter of ordinary business practice, a server cannot say
> "provide service" but then refuse to accept billing for that service.

I wholeheartedly agree. And I also think that there's a better solution
to help administrators of accounting servers to guarantee that they
don't process and bill their users for unwanted records.

Historically, the Class attribute seemed to be intended for the
accounting server to distinguish among differently charged service
types, according to information that was available authentication time.

That doesn't help accounting servers in making sure that the session
actually occurred and was not forged by the party operating the NAS or
intermediate proxy, who has an incentive to do so, if it gets paid per
minute or session.

However, if the party that authenticates and is responsible for handling
the bill for the user generates a cryptographically strong cookie and
puts that in Class, it can guarantee that subsequent accounting requests
are only processed if they can be tied to authentications it performed
itself.

I feel this is a better solution to tying accounting to authentication
than eg. requiring Acct-Session-Id in access requests as some operators
stretch RFC2869 to, or CUI.  I know, it's not exactly the same thing,
but as far as I understand CUI's purpose, CUI was aimed at solving a
similar problem.

With a server that allows you to put arbitrary logic and database
queries into the authentication and accounting sequences, such a scheme
can be implemented without any changes to NASes or proxies, or even the
code of the server itself. My server (OpenRADIUS) is an example, but
there are probably others that can do it just as well.

Kind regards,


Emile van Bergen.

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