[unisog] fw: insecure wireless LAN deployment at .edu

Ben Curran bdc1 at humboldt.edu
Thu Jan 24 21:16:34 GMT 2002

One of our concerns with authenticating users to radius, kerberos 
etc. is that our only student password/login pair granted during 
initial registration to all students, is their POP3 account logins. 
(They also have separate logins for Banner web reg) We don't want 
network admin to get involved in managing student accounts since 
this is handled nicely by enrollment management & help desk staff. 

Any recommendations for "offloading" these existing accounts to 
"new" wireless (or otherwise) authentication databases?

Ben Curran

On 23 Jan 2002, at 14:23, José Domínguez wrote:

It doesn't scale at all. After trying several technologies and 
setups, including local MAC ACLs, Radius-based ACLs, proprietary 
authentication/encryption (Orinoco's AS2000) and VPN (using Cisco's 
VPN3000 and VPN5000) we have scaled down to using our own filtering 
gateway. Basically, wireless users are free to roam within the 
wireless network but once they want to go out of it they'll have to 
authenticate. To authenticate they just open up their SSL-enabled 
browser and go somewhere which will redirect them to the 
authentication page since the gateway detects that the user's mac 
address is not in the list of allowed mac addresses. The user will 
then authenticate thru an SSL encrypted session against our radius 
server and if successful its mac address will be added to the filters.

We are aware of several places using similar solutions. NASA and 
Georgia Tech come to mind but I'm sure many others are.

Our main reason to move to this platform was based on the number of 
different wireless devices that people want to use including some 
PDAs (Palm and PocketPC based) and other devices like IP phones. This 
also means that data protection is left to the user and they have to 
make sure they use secure protocols.

Not a perfect solution but it's one that it's not proprietary on any 
way and allows for almost any device to work. We have worked on most 
of the security implications and are still defining some mechanisms 
for attack detection and "search and destroy" procedures. We have 
some ideas on how the system can be broken and have taken some steps 
to reduce the probability of this happening. 

Our biggest concern is user's passwords being sniffed because the 
users don't use secure protocols and this in the end could compromise 
other systems. We are waiting for this to happen to take some extra 

I hope this helps ... BTW, if you'll be at the next Internet2 
Joint-Tech meeting in Tempe, AZ I will be there talking about all 
of this and way we did what we did (Read end-user pressure).


On 01/23/2002 15:13 EST, Brian Reilly wrote:
> On Wed, 23 Jan 2002, Jose Nazario wrote:
> > 
> > - Filter Mac addresses at the AP to allow access only by known clients
> > 
> Are (m)any of you doing this for your campus-wide wireless deployments?  
> If so, I'd be interested in any feedback on technologies, tools, and
> procedures that have worked well.  My experience is that manual management
> of MAC address filters does not scale very well for a large number of
> users.
> Thanks,
> Brian
> --
> <reillyb at georgetown.edu>

More information about the unisog mailing list