"8,500 undergraduates start over one weekend," he explains, "and they all want their MAC addresses registered immediately."
Unfortunately, when the university began rolling out its 802.11b network, there weren't any security tools available that could handle that type of traffic load. In this article we take a look at the three-step custom solution Seruya devised.
Founded in 1925, the University of Miami is a private educational institution with nearly 15,000 students and 9,400 faculty and staff. In addition to the main campus in Coral Gables, it also has a medical teaching facility and a marine research campus, both in Miami. From an IT viewpoint, it treats each of these physical locations as a campus, and the wireless cloud as an additional campus.
The university provides an Ethernet connection for each student living on campus. The Coral Gables campus also has a wireless cloud, called "WirelessCanes," covering more than 240 acres (www.miami.edu/UMH/CDA/UMH_Main/1,1770,12330-1;12301-3,00.html), which the students can access by wireless laptop or PDA. Connections to the outside world include several 300Mb Internet connections.
In addition, the university is a member of the Internet2 consortium and has direct fiber links to other local universities.
Seruya set up the first elements of the 802.11b wireless cloud, which now contains about 500 Proxim OriNOCO Access Points (models 500, 1000 and 2000), during the summer of 2000. Although he hired some contractors to do the wiring, all the security design and implementation was done in-house using either students or university staff. Doing it this way, he was able to keep the security systems hard costs down under $10,000, including a small UNIX server to host the software.
"When we started there was a question of how to deploy it and get it to work in a secure fashion," he explains. "There were no prepackaged solutions available at that time, so we decided to come up with our own scheme."
While it would have been technologically easy enough to set it up for the students to fill out access request forms and have staff enter them into a database, that method was too slow and demanded too much staff time. The students would have been lucky to get on line by the end of the semester, and then IT would have to keep track of any students who graduate or drop out so that they would lose their access privileges.
The first breakthrough, therefore, was to merge the wireless security with existing student database used as part of the overall student portal. The university's registrars keep track of the status of each student, and the network access was made part of the registrar database. The students use this portal and the associated database to register for housing, classes and other services.
Any student who is actively enrolled at the university is assigned a login and password as part of the registration process. If the student is no longer active for whatever reason, when the registrar notes them as inactive, their logon is automatically disabled.
"The biggest concern for us is something falling through the cracks," says Seruya. "This way there is no paperwork for us to process and we don't have to keep track of everyone's status."
A similar system exists for faculty and staff, but in this case it is tied into the HR database, rather than the Registrar's. When the university hires an employee and enters that person into the HR system, that person automatically gains network access, which terminates upon departure or termination.
The wireless security system Seruya and his team devised consists of three layers: The first layer is the access points themselves. The student's wireless adapter card will locate the nearest Access Point and attempt to gain access. The AP will then check the device's MAC address to see if it is registered and allowed to be on the network. If it does not recognize the MAC, it will direct the person to a page to register the device. The page also contains instructions on how to determine what their devices MAC address is.
Once the student enters the required information, the system then automatically populates the wireless access database with that user and device. The entire process takes less than two minutes, at which point users gain access to the network.
"What used to take us weeks and weeks now takes minutes," says Seruya. "In one night, 1,500 students registered themselves."
Once the AP validates the device, the next security layer lies with the Dynamic Host Configuration Protocol (DHCP) server. The wireless devices need to get an IP address from the DCHP server, but it wont issue one until it verifies the MAC address.
Finally, after passing the above two steps, the user is directed to a Web page to enter their logon and password. These are the same logon and password they use to access the student portal, so IT doesn't have to maintain a separate database for these.
The security system in general has served well, but each year Seruya adds additional features. For example, initially students were just able to register one wireless device. But as wireless PDAs started taking their place alongside wireless laptops, that was no longer adequate, and the system was reconfigured to permit multiple MAC addresses for a single student.
For this summer, he has a list of requests from students, along with his own wish list. One particular feature he would like to add is that the system re-authenticates users every six hours or some other predetermined time period. This would reduce the amount of time that users could stay logged on after their authorization was cancelled. He is also examining commercially security platforms that have become available over the past few years to see if they would do a better job than his home grown one.
"Every summer we have the opportunity or improve or reconsider the track we are going down," he explains. "We are not naive enough to think that what we are doing now is the right thing to do forever."