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.