[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Clearinghouse/Aggregator Support for CUI



Title: Message
Absolutely correct.  The originally presented NAI as per the Identity request must stay unchanged for all RADIUS events.  As such, the original RFC language must be closed.  In order to expose the underlying authorized profile of a tunneled EAP method, CUI should be used instead rather than manipulating the User-Name attribute which could possibly change the Accounting's routing (most assuredly so when promiscuous source based NAI construction is used which is unknown to the home network...commonly so).
 
RADIUS User-Name must remain as originally presented.  The actual authenticating profile name, or in cases where privacy is required, an alias may be passed back in the Access-Accept to populate the CUI.  While an alias in the Access-Accept is a function that needs to be implemented on the home Authentication Server, that is something which is tenable based on the CUI standard that we propose.  Networks can build an anonymity mechanism by returning an alias (such as a phone exchange, PIN, etc) in the Access-Accept User-Name to populate the CUI, but that is to their discretion.  Otherwise, the normal "unrealmed" username of the authorized profile would be used in the CUI which does not affect RADIUS routing (i.e. "blair").  This provides a mechanic for per-user/per-session correlation, exposes the actual authorized credential while still allowing networks to build anonymous tunneled systems with some semblance of fraud detection and service oversight where none exists today. 
 
Blair


From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
Sent: Sunday, October 24, 2004 11:36 PM
To: Blair T. Bullock; Barney Wolff; radiusext@ops.ietf.org
Subject: RE: Clearinghouse/Aggregator Support for CUI

Hi Blair,
 
Thanks for good notes Blair.
 
On "UserName Overwrite" below,  the RADIUS routing is done based on the realm portion of the NAI -- not the user-name part.  As long as the realm and decorated portion of the NAI sent in the Access-Request gets reflected in the Access-Accept  then the billing should follow the same path as the authentication packets.  for the purpose of  the CUI, when we say "User-Name Overwrite", I think we are referring to the user-name part of the NAI,  NOT the realm or decoration part.  However, the problem arises when the decoration part in Access-Request is stripped off on its way to the home RADIUS server.   And where the RFC2865 says this about the UserName(1) : "   It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session."    To fix the routing problem (i.e., ensuring authentication and accounting packets follow the same path),   it seems to me that the NAS should also always  include the UserName(1) that was sent in the Access-Request in Accounting-Requests (on contrary to what RFC 2865 states).     And if so ,  then the intermediaries will not have access to the CUI that was conveyed by the User-Name Overwrite    In summary,  This problem can be fixed with the introduction of the CUI *in conjunction* with the language changes to RFC2865 (as mentinoed above).  Your comment?
 
BR,
Farid
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Blair T. Bullock
Sent: Sunday, October 24, 2004 1:18 PM
To: Barney Wolff; radiusext@ops.ietf.org
Subject: Clearinghouse/Aggregator Support for CUI

Collegues,
 
I wanted to chime in again on the adoption of CUI and summarize where I see the general consensus within the industry on legacy-based work-arounds.  When I say "Industry", I mean from the results of parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, IRAP, Intel/IDA IWS and several well-respected RADIUS experts within this organization.  From a Clearinghouse/Aggregator standpoint, I have intimate knowlege of several major RADIUS clearinghouse systems and their supplying networks and know that what I describe here is absolutely crucial to the proper adoption and mediated AAA of Tunneled EAP methods for WPA Public Access.    This problem is very well understood!    Class doesn't work.  NAI modification is bad.  The Outer-Identity is discarded at Authorization and there is no good way to oversee tunneled EAP authentications without Early Termination or reflection in User-Name which modifies the NAI.
 
CUI is basically designed to close operational loopoles in RADIUS allowed by the original RFCs, but which have impacted roaming network solutions in a negative way, particularly with the introduction of multiple identity tunneled protocols such as PEAP or TTLS.  To concur what was said earlier on this thread, a clearly chargeable user/alias reflecting the home network's authenticated user profile is absolutely neccessary for all parties and *must be transparent*.  
 
The concern for legacy-based support is valid, but unwarranted.  If presented in a hybrid network, any new attributes should be silently discarded and not dropped or NAKed due to malformation or unsupported attributes.  Besides, the CUI is specifically geared to Multi-Identity EAP authentications which in all honestly, are built with the latest protocols.  An older radius endpoint could trigger CUI by virtue of including the User-Name in its Access-Accepts, but would merely drop the attribute when it arrives in Accounting (assuming that the NAS doesn't change the NAI and route it into neverland)
 
The loophole RADIUS operations are:
 
1 - User-Name Overwrite:   Overwriting the User-Name with the User-Name in the Access-Accept.  Ouch!! Whether by chance or choice, this is just *wrong* as an accounting approach.  In a Local or Bi-lateral service, I can see why this would be useful to reflect the authenticated profile from the Access-Accept User-Name (assuming the home network uses an @realm or they won't get Accounting back, even in standard methods).  But with a Tunneled EAP Inner ID being returned in a Home-Based Access-Accept to a network which derives its peering from client-based source decorated NAI?  It is Desastrous!!  Furthermore, willfull lack of decoration for the Inner ID is a clear opportunity for fraud!  Therefore, User-Name is not allowed to be returned in the Access-Accept User-Name so that RADIUS networks can be assured to receive Accounting packets down the same peering path that the Authentication use.  
 
2 - NAI:  As someone rightfully noted on this reflector, the proprietary Global clearinghouse Prefix-based NAI construction methods which have evolved over the past decade are not represented in the latest drafts.  These methods were designed with business and RADIUS legacy interoperability in mind.  Simple chained suffix-based routing to consumers (@realm@realm) was the only standard that we had.  It allowed for reseller arrangements.  However, in order to deal with the aggregation of networks for supply, another mechanism was needed.  The prefix.  The "/" was initially presented by UUnet and because it was not specifically reserved, allowed the formation of proprietary network aggregation while leveraging the stadards-based realm support for resale of that aggregated service. operator/agregator/user@realm@reseller.  Now it is supported ubiquitously and maintains legacy compat down to livingston 1.16.    Whether good or bad, reality dictates that it is a defacto standard.  Ergo the originally presented NAI held by the NAS must not be changed based on "standard" NAI construction principles...ever...at least for use with these global networks and their partners.   You simply don't know in every case how they have constructed the NAI and must always respect a pre-decorated NAI. 
 
The disparate NAS support for User-Name overwrite is mitigated by the elimination of User-Name in the A-A, basically breaking CUI too until allowed on a verified CUI functional network which will be the normal oversight for deploying a new WPA service.   Tunneled EAP for Public Access roaming will not be adopted until the User-Name is passed back in the Access Accept for use with the CUI only and never the User-name.  This will only happen after verification that these specific operations have been corrected and CUI fulfills the exposure of the Authenticated Home User Profile without modifying the Accounting User-Name.  Its that simple.  We need the NAI in the User-Name unspoiled to honor our routing and aggregation methods.  A consistent way to expose the actual authenticated profile on a per-user/per-session basis for the purposes of revenue assurance, fraud detection and service oversight is fundamental in a Federated AAA Fabric such as iPass or an aggregated RADIUS peering fabric such as with our many competitors. 
 
From discussion with WISP global partners deploying WPA, CUI service oversight is also crucial where **no roaming** is even occurring!  Since the OuterID is dropped at the time of authentication, you simply have to know which profile is authorized as exposed in the accounting.
 
CLASS - The Class Attribute was the initial legacy-based work-around to CUI based on its ability to reflect home data in an accounting stream.  However:
 1 - It is intended to be opaque to all but the home network (which does no good since the whole purpose is to tie specific sessions to distinct authorizations between all parties.)
2 - This is an additive attribute and their value ordering unspecified.  How many classes to we demand support for in a NAS?  One?  Four?  Eight?  Many of these APs don't have that much processing power.
 
CUI is the correct standards-based approach to fixing the problems which have arisen with multiple-identity RADIUS auth and accounting methods.  While it will not solve all problems (like MSCHAPv2 in TTLS IN TTLS), but it does respond to the readily available EAP supplicants and provides the current global RADIUS networks with the capacity to deploy, bill and oversee WPA networks against fraud.  Without this, other proprietary methods will be done, I assure you.  However, our job would be much easier if there was wide adoption of the CUI attribute.  iPass for instance, would mandate and facilitate its adoption immediately.
 
CUI is not an overloading of a legacy attribute or arbitrary kludge of existing attributes in order to make these networks work.  It is a necessary correction amongst the others listed above.
 
Thanks for your time.
 
Blair Bullock
Systems Arhitect, iPass Inc.