RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Title: Message

By roaming agreement the HAAA will not send the same CUI for all its users.  When a broker network negotiates with the home network it will require the home network to issue the CUI which is different for every user.

 

So yes the Home Network can cheat but why would it do so?  After all it is relying on its relationship with the broker to generate additional revenue.  If the Home network is found to commit fraud then it is the home network that would be the loser at the end as no one will want to do business with it.

 

But the broker network also has a way of validating that the CUI is not being missused. For example, if the broker network sees that the same CUI is being reported to two different NASes it would just reject the request, log it, and I am sure there will be phone call between two CEOs in that case.  So cheating is possible but hard -very hard.

 

Scenario 2:

 

As I understand scenario 2 it is all about routing.  CUI is not about routing - its not intended for that but is intended for your scenario 1.

 

The username is still in the packet and contains the realm and potentially a route selected by the user -- see other works by my co-author. Routing is done on the realm part of the UserName not the identity part.

 

When eap methods are being used the User Name looks like     "@example.com".  We route only on the realm part or decoration part of the NAI. See 2486bis.

 

Once the Access-Request reaches the home network the AAA path has already been determined. The CUI is applied to the Access-Accept.

 

Hope this resolves your concerns.

 

Avi

 

-----Original Message-----
From: Bikramjit Singh [mailto:BSingh@Nomadix.com]
Sent: Tuesday, December 21, 2004 3:53 PM
To: 'Alan DeKok'; 'radiusext@ops.ietf.org'
Subject: RE: Scope of applicability for CUI

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