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

Patrick Darden darden at armc.org
Fri Jan 25 13:01:29 GMT 2002


Radius can use existing unix passwd or shadow files.

--
--Patrick Darden                Internetworking Manager             
--                              706.475.3312    darden at armc.org
--                              Athens Regional Medical Center


On Thu, 24 Jan 2002, Ben Curran wrote:

> 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 
> measures.
> 
> 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).
> 
> JosE.
> 
> 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