Wireless Network Roaming for the University of California
As an outcome of the February, 2010 ITLC meeting, the Communications Planning Group (CPG) was asked to work with the UCTrust Work Group to prepare a recommendation report evaluating the viability, risks, and cost at an institutional level for a common wireless authentication and access methodology to allow any member of the UC community to use the wireless networks of any other UC entity without need for creation of guest or visitor accounts.
In the May, 2010 CPG meeting, it was decided to create a work group to pursue this issue. David Walker agreed to convene the group, and 19 members were drawn from six campuses and one medical center: UCB, UCD, UCD Health System, UCLA, UCR, UCSD, and UCSC.
Initially, the group pursued a strategy of leveraging UCTrust to federate the "captive portals" that each campus uses to authenticate users to their unencrypted networks. During this time period, however, eduroam-US, in partnership with InCommon, became a viable alternative. We determined that eduroam-US is a better alternative for the following reasons:
- eduroam-US will, eventually, extend wireless roaming for UC travelers to institutions throughout the US and Europe, not just within UC. As such we believe it will be come a de facto standard for higher education.
- The cost to implement eduroam-US is relatively small for campuses with an 802.1x infrastructure for encrypted wireless Ethernet. While not all campuses currently have such an infrastructure, all participating campuses plan to create one. Some of the campuses that did not participate, however, anticipate difficulty to implement and operate 802.1x.that could delay their participation.
- While eduroam-US is new, and there are policy and operational issues it must resolve (see below), we believe that it will resolve those issues.
- Federation of captive portals is new. If UC were to follow that strategy, it would need to do its own development work in most cases. In other cases, negotiation with vendors would be required. UC has experience with federating applications, and we know the cost is manageable. This project, however, would involve federating 12 or more captive portals, depending on which locations participate, so the effort is much larger than most.
The Plan
The participating campuses plan to join eduroam-US over the coming 12 months (by September, 2011), and we will work within the eduroam-US organization to resolve issues we have identified during our deliberations. We encourage the other UC locations to join eduroam-US (scheduled according to local priorities and tolerance for eduroam-US's maturity) to enable wireless roaming among all UC campuses. The following chart shows a quick estimate of campus readiness; firm estimates will require further investigation..
Campus | Quick Estimate |
---|---|
UCB | Can implement eduroam within the next 12 months for the portions of the campuses with WAPs that support it. |
UCD | Plan to implement by the end of 2010 for centrally-managed portions of the campus. |
UCI | Currently testing. Planning on implementing on August 15, 2011. |
UCLA | Testing now. Plan to implement by the end of 2010 for centrally-managed portions of the campus. |
UCM | Have an 802.1x wireless network. Ability to deploy AES will require more investigation. |
UCR | As of 2012, eduroam is available campus wide and authentication is available for UCR individuals traveling elsewhere. |
UCSD | Can implement campus-wide within the next 12 months. |
UCSF | Can implement within the next 12 months. |
UCSB | Can implement 802.1x, but does not plan on adopting eduroam until there is substantial progress in resolving the operational and management issues. |
UCSC | Can implement eduroam within the next 12 months for the portions of the campuses with WAPs that support it. |
UCLA and UCD will be first with implementations planned by the end of calendar year 2010.
Issues Associated with Federated Wireless Guest Access
The following issues have been identified as needing to be addressed as we role out federated guest wireless services. We will work within eduroam to detemrine suitable resolutions.
- Host institutions may require information about their guests. This information is used to communicate with guests in the following situations:
- A security vulnerability is suspected on a guest's computer.
- A copyright infringement notice is received for a guest.
- A security investigation involves a guest.
- Host institutions may desire to present local information, such as its network policy, to guests.
- A wireless guest access federation needs policies to govern operational issues and other interactions among its members.
Most campuses also have the issue that not all of their wireless access points support the eduroam specifications, specifically AES encryption. Also, most campuses have wireless access points that are not centrally managed. Of necessity, eduroam access will not be available from all wireless locations at all campuses.
While not specifically an issue for federated access, the implementation and operation of 802.1x and encrypted wireless access requires resources More specifically, there are concerns that implementing encrypted wireless puts strain on users having to perform client configuration, and in turn this will place additional strain on the help desk. We will evaluate XPress Connect from Cloud Path Networks, among other solutions, for use with eduroam.
Workgroup Membership
- Robert Cartelli, UCSC
- Dedra Chamberlin, UCB
- Patrick Flannery, UCDHS
- Bob Grant, UCR
- Chris Hain, UCD
- Russ Harvey, UCR
- Stephen Hock, UCR
- Erik Klavon, UCB
- Gabe Lawrence, UCSD
- ken lindahl, UCB
- Jim Madden, UCSD
- Jeff McCullough, UCB
- Dave Parsons, UCLA
- Mark Redican, UCD
- Andrew Tristan, UCR
- Mike Van Norman, UCLA
- David Walker, UCD, convener
- David Wong, UCD
- Albert Wu, UCLA