[unisog] fw: insecure wireless LAN deployment at .edu
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
> 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