Re: AW: -01 version of Chargeable User Identity

[Bernard Aboba <aboba@internaut.com>]

> I still don't understand the local (ie, NAS) problem.  It's not going
> to bill the end user directly, in any scenario that makes business sense.
> If for no other reason, it has no billing address or credit card number,
> just, even given CUI, joeblow@example.com.  So for whom is CUI intended?

Well, the original request was for the authors to explain the problem in
their draft, and for the WG to read their explanation and opine as to
whether the problem statement is convincing.  So the authors
really need to answer that question to the WG's satisfaction if this draft
is to become a WG work item.  The other alternative is for the WG to
reject the submission, either for consideration as a WG work item, or for
allocation of an attribute type under RFC 3575.

Since the GSMA asked for this, we owe them an extra dollop of due diligence --
and therefore the attempt to determine whether there are any scenarios in
which the CUI attribute is needed.

In the last few emails, I think we've established that if the local realm
and home realm are doing business directly then the home
realm can send Class and get what it needs and as far as I can see, there
is no need for CUI.

But what if the local server bills an intermediary?  Then it can't
necessarily be sure that the intermediary and home server are in agreement
on what is to go into the Class attribute.  In other words, Class could be
meaningful to the home server, but not to the intermediary.  If the
intermediary and home server have arrangements that relate
to things like simultaneous usage, then the intermediary may not be able
to carry out those agreements without a meaningful username.

I accept your argument that the local server may not care  about whether
it can confirm a billable identity or not.  If there is some
kind of monthly report required, the local realm can generate that report
based on the class attribute(s), by pre-arrangement with the home realm.

> What does "assurance" mean?  Does it mean that somehow the Access-Accept
> is more trustworthy because the home server said it was joeblow@example.com
> rather than just anony.mouse@example.com?  Why does the NAS's owner care?

"Assurance" means that the local server has fulfilled the terms of its
obligation to the entity that it bills.  If this is the home server, then
I think there is no need for CUI, since echo'ing the Class attribute
should give the home server whatever it might need.

However, if the payor is an intermediary, then the Class attribute may not
be sufficient.

> Call me stubborn, but I still see the only scenario where CUI is required
> would be where the access and accounting servers are run by different
> organizations that fail to negotiate a format for Class, and where (despite
> that) the accounting server is willing to trust what the access server
> says about the user's identity.  I find it hard to believe this is a real
> case, or to sympathize if it is.

Yes, I think this is essentially the same scenario as the one I outlined
above, where the Accounting Server is run by an intermediary and the
authentication server is in the home realm.

Perhaps RADEXT WG participants from roaming firms can answer whether this
is a real usage scenario or not.

> Oh, wait.  We did hear the scenario.  The NAS or proxy is pricing based on
> the maximum number of distinct users per time-period, rather than on total
> minutes of use or number of calls or anything else easy to record.  For this
> we are talking about attribute support negotiation, servers keeping state
> on NAS capabilities and such?

Yes, that would be a scenario where a username is needed by the local
server and intermediary and CUI provides this, whereas Class doesn't
accomplish this without pre-arrangement.

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