I have been reading this thread for a while and I am not sure if this attribute helps in 2 scenarios that an intermediary can face...
1) The wholesale billing plans that are being seen currently in WLAN roaming world are based on per-user-per-location for 24 hour period. That means that the same user is allowed to login and logout any number of times from that location and he will be charged only once for that 24 hour period.. This requires correlation of the multiple RADIUS sessions of that user from a particular location (NAS) and currently this is being achieved by using the username and NAS-ID attribute.. How would we be able to do this once TTLS EAP or other protected mechanisms are required and 802.1x becomes a requirement for the roaming world?? The CUI will not be able to be of much help since the home AAA can theoretically send the same CUI for all its users logins from that location so that it doesn't have to pay the intermediary for separate users.. This is a not an issue in a clear-text username attribute correlation where an intermediary knows who is being authenticated and accounted for.
2) Consider a business relationship scenario like this.
+---C----+---E
| |
A-------B-+ +---D
| |
+------------+
B is the intermediary and C is an intermediary.. B would like to deny access to D through C since it has a direct roaming agreement with D or atleast it wants to tell D that the only way to get access to A (access network) is through B.. But by using protected usernames, D can do a roaming relationship with C without B knowing about it and maybe C is getting a better deal for it since it has already negotiated discounted rates with B and it is getting a piece of the pie even in the case where it is not required... For whatever reasons, how can B know that a particular request is finally ending up in D via C if the user identity is hidden.. CUI will not help in this scenario either.. B has to do business with C since C has exclusive access to E.. But B knows that it can get to D on its own and wants to shut off access for D's users if they are being authenticated through C.. Apart from pricing model restrictions, what is the technical feasibility using RADIUS to allow/deny this from happening... Right now there is a way using usernames that if the username is C/joe@D.com then B can reject that access-request.. however if it is C/xdfaer342 (encrypted) then how does B prevent it??
Thanks
-Bik
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
Sent: Tuesday, December 21, 2004 12:09 PM
To: radiusext@ops.ietf.org
Subject: Re: Scope of applicability for CUI
Avi Lior <avi@bridgewatersystems.com> wrote:
> Yes there is only one instance. But that is the least of the differences.
> Unlike Class, CUI is supposed to be interpreted by the client. In so far
> that the client knows the CUI is assertion by the Home Network that this is
> a handle to a subscriber.
If the main purpose of the CUI is to give an opaque handle to a
subscriber so proxies can control multiple logins, then I'm not sure
what it gains us. The home server can limit multiple logins, so the
proxy server doesn't have to. As Emile said, if the proxy server
doesn't trust the home server to manage multiple logins, it shouldn't
trust the home server to create the same CUI for the same user.
The main benefit I see is that the multiple login use of the CUI is
managed by the proxy server, which means the home servers can be
simpler to configure.
If that's the main reason for CUI, then I would like to see a
sentence or two in the document explaining the different approaches,
the issues with CUI, and why this approach was chosen.
I'm not opposing it, I just want the reasons for choosing it to be
clear 3 years from now to people outside of radiusext.
Alan DeKok.
--
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/>