[unisog] fw: insecure wireless LAN deployment at .edu
H. Morrow Long
morrow.long at yale.edu
Fri Jan 25 15:47:39 GMT 2002
What type of authentication system are your POP3 accounts and passwords stored in?
Unix local passwd/shadow files? NIS/NIS+? Netscape or other LDAP? NT or W2K AD domain?
Yale keeps parallel Kerberos 5 and Windows 2000 AD accounts (called the Yale NetID)
in synch and are able to serve out authentication requests against the NetID/password
via a variety of authentication protocols :
Kerberos 4 - compatibility mode
Kerberos 5 - Native MIT mode (for Unix/Linux/PAM/etc)
Kerberos 5 - Microsoft AD mode for W2K apps
CAS - Central Authentication Service (our own web-based SSO Passport-like service)
NTLM - For Samba and Microsoft Windows *
LDAP - Microsoft Windows 2000 AD - not currently used for authentication,
nor as an authoritative lookup server
[X]TACACS - Cisco, for PPP authentication for campus dialups
RADIUS - Microsoft AD IAS - for Cisco 3030 VPN server w/PPTP in MSCHAPv1/2 mode
We require MAC address registration for both residential room connections as well as
roaming. Students register their MAC addresses at start of term via a secure website
which requires them to authenticate with their Yale NetID and password. They can
register multiple computers. DHCP tables are automatically built from this web entry
and the DHCP servers reloaded every so many minutes. All dorm computers use DHCP and
DHCP will also vend IP addresses to students "roaming" by connecting via wired or
wireless locations on campus.
This system has been in use for a number of years for students and it has already expanded
to use by Faculty and staff primarily for roaming and we are now considering it for
use by most non-server computers -- e.g. desktop Macs and PCs -- for ease of network
configuration of subnets (changing subnet addresss, # of hosts per subnet via mask, etc)
as well as some security considerations. Typically most students (and this would apply
to desktop PC/Mac faculty users) are (and would be) assigned a semi-permanent (for 1 year)
"home" IP address on the subnet on which the computer would sit while at Yale most of the
time. However, using DHCP it would be much easier to change the IP address if needed (call
up the user and have them reboot their computer).
- H. Morrow Long
> 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>
> > >
> > >
> > >
> > >
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2663 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dshield.org/pipermail/unisog/attachments/20020125/a1ad80f3/smime-0006.bin
More information about the unisog