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/a
gregator/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.