Re: Scope of applicability for CUI

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

Hi,

On Mon, Dec 20, 2004 at 10:30:35PM +0200, Jari Arkko wrote:

> Avi Lior wrote:
> 
> >An intermediate proxy when seeing Authentication/Authorization traffic 
> >can't
> >correlated it to a specific user when methods such as EAP are being used.
> >
> >The only thing a intermediary can do is use class to correlate an 
> >accounting
> >stream with a authentication stream. But it can't correlate that to a
> >specific user.
> >
> >So if iPass wants to limit how many times John logs in (and they do) then
> >they would not be able to do so when certain EAP methods are being used.
> 
> Agreed. This is for me the prime reason why CUI is needed.

Ok, I understand that. But then it seems to me that CUI could get the
exact same semantics of Class, with the exception that there may only be
one instance present.

And I think to avoid the confusion, it should be made more clear then
that CUI is only a communications device from a home AAA (at the
time of accept) to a proxy AAA (at the time of accept and when
accounting, via the NAS); for all 'normal' cases, Class should be used.

Let's try to work out your example a little. A proxy AAA like iPass' 
could refuse to forward the accept towards the NAS if it doesn't receive
a CUI from the home AAA, and send a reject instead. Ok.

Similarly, if it wants to get (some) certainty about whether it can
expect to receive CUI in the subsequent accounting from the NAS, it
could reject all requests from NASes that don't advertise their support for
echoing CUI by putting a dummy CUI in their access requests.

An empty CUI as advertisement violates RFC2865 though, which says that
empty string attributes MUST NOT be sent [p. 24]. Any valid value should
do though, the empty value conveys no special meaning here. If the
attribute is present at all, the NAS indicates its support for echoing
CUI. A single NUL character SHOULD perhaps be used by NASes, but the
receiver MUST not attach any meaning to it for the purpose of
establishing the NAS' support for CUI.

I still think it's a bit weird for an intermediate to enforce a limit
(on simultaneous use, no less) based on data supplied by the home AAA,
instead of the home AAA enforcing that limit itself. With the use of CUI
as in your example, iPass needs to  trust the home AAA that it doesn't
simply generate a random CUI for every single authentication to thwart
such a limit.

If iPass would be smart, they would only limit things it can actually
count without trusting the home AAA. It knows eg. when it sends an access
request to which home AAA, and so with /some/ certainty, it knows how
many sessions are open for a wholesale customer (if it doesn't miss too
many Stop records). Let it count the total number of simulatenous
sessions for a wholesale customer then, instead of for a particular CUI,
and let the customer's AAA enforce the limits for its individual end
users, using any policy it wishes to use.

No need for trust, and no need for CUI; this actually seems a better
solution for your scenario.

Are there any scenarios where
CUI-as-a-vehicle-between-home-and-intemediate offers perhaps some more
improvement? This is not rhetorical, but a honest question.

Cheers,


Emile.

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