Re: AW: -01 version of Chargeable User Identity

[Barney Wolff <barney@databus.com>]

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?

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.

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.

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.

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

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