[unisog] VPN Protection of Wireless Networks

Patrick Darden darden at armc.org
Tue Dec 18 21:14:20 GMT 2001


looks good.  However, I would like to add that a Radius/TACACS+ type
server that hangs off of the VPN Engine but is not connected to legacy
networks and does not depend upon them (e.g. nt domain) is not vulnerable.
Therefore, you could certainly have a shared secrets system that is not
vulnerable, just a bit of a pain to administer (new username/password for
everyone to remember, and another separate system that needs account

I'd also like to point out that in a system that uses Radius/TACACS+ type
services connected to a legacy network like NT Domains, the same usernames
and passwords float around already--so adding Radius/TACACS+ doesn't make
it any less secure.

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

On Tue, 18 Dec 2001, Gary Flynn wrote:

> Patrick Darden wrote:
> > 
> > I believe we are talking about the same thing.  The username/password pair
> > that I have been speaking about is the same as the pre-shared key you are
> > talking about.  Here's the process as I understand it.  During the ESP
> > negotiation phase (initial negotiation of an encrypted IPSEC tunnel) the
> > client sends the username to the VPN engine.  The VPNe knows by the
> > username which pre-shared key (password) to use.  They both begin using
> > that password.  The password itself is never sent.
> Thanks, Patrick and everyone else who responded.
> I took the responses, dived into the Cisco and IPSEC RFCs, and
> wrote a summary of what I believe to be the implications of the
> various authentication methods.
> http://www.jmu.edu/computing/security/vpnauth.shtml
> -- 
> Gary Flynn
> Security Engineer - Technical Services
> James Madison University
> Please R.U.N.S.A.F.E.
> http://www.jmu.edu/computing/runsafe

More information about the unisog mailing list