[unisog] VPN Protection of Wireless Networks
Peter Van Epp
vanepp at sfu.ca
Thu Dec 13 23:00:53 GMT 2001
> "Jose A. Dominguez" wrote:
> > On Thu, 13 Dec 2001, Gary Flynn wrote:
> > > In October I asked about vendor lockins on various security options
> > > for wireless networks. VPN protection was mentioned quite often.
> > > From my reading, effective VPN protection would require each individual
> > > user to have a unique key or digital certificate. Are people actually
> > > doing that? If so, how are you handling the administration of handing
> > > out and revoking keys and certificates? What, if anything is done to
> > > educate the end user of the importance of keeping them secret?
> > Having certificates would be nice but it's not arequirement. You can do
> > that with Radius and standared username/password pairs. It'll all depend
> > on what tunnel termination device you use.
> If a shared key is used to connect to the VPN concentrator before
> authentication, doesn't this leave the subsequent authentication
> credentials up for grabs in a MIM attack from anyone else with
> the shared key?
> Gary Flynn
> Security Engineer - Technical Services
> James Madison University
> Please R.U.N.S.A.F.E.
It might, but remember an MTM attack isn't all that easy to set up. The
attacker needs to be able to spoof being the server to the client and the client
to the real server in this case in an RF field where the real client and server
can hear each other as well. I expect that isn't going to be all that easy
in real life (although it is a concern, higher power transmitters and/or
directional antennas are one possible solution for a successful spoof).
What we are doing is using a Vernier box (with radius on the back end
although ldap/X.509 is also possible) to authenticate the user via SSL. The
vernier box has a cert, and thus if spoofed will give the user an "invalid
certificate" warning (which they may of course ignore). After that we suggest
(but don't currently require) they use ssh to protect their conversation over
the link (the SSL protects their authentication information as long as the
user is careful).
While we currently don't have an instance, should someone require
secure access via wireless we can provide them with a VPN client and an X.509
certificate (TimeStep in our case) which would be in addition to the Vernier
box (they'd still need to authenticate to the vernier box to get off the
wireless net to establish the VPN connection). Client and certificate issue
is out of band and the VPN client and CA deal with issuing certs and the CRLs
(entrust under the covers currently). You are correct this is a pain in the ass
as well, but if you need that level of security thats what you need to do!).
My view of this is that we have made it possible for the user to use
wireless in a secure manner (SSL authentication to a certificated server
to authenticate them, SSH on their part to maintain the link securely) without
going to a probably unsupportable in the general case (VPN for everyone) level.
I expect for most people even the SSH isn't a real requirement, their
authorization credentials are protected by the SSL and if their normal traffic
is sniffed then it is and no great problem. If that is a concern using SSH will
remove it and provide end to end encryption. If we require security for some
reason (and are willing to do it across wireless for some reason) then the
full certifcate based VPN with all its hassles is in order.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
More information about the unisog