Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '"safe" IPSec configurations for network admins' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
"safe" IPSec configurations for network admins
Authored by: cuberoot on Aug 29, '07 03:59:28PM

Network admins beware: If you are allowing access to your network using IPSec then you should make sure you understand the risks associated with any configuration you enable.

IKE typically has two well-supported ways of negotiating a phase-1 security association: certificates and preshared keys. The rub is that both ends of the connection must use the same mechanism. I.e. the server can't present a cert while the client presents a PSK. Since the phase-1 SA always happens first and is used to protect the rest of the session, it is important to understand that:

  • In certificate-based IKE phase-1 exchanges, the client can authenticate the server based on the FQDN of the server in the CN of the server's cert before continuing.
  • In PSK-based IKE phase-1 exchanges, the client can only be sure that the other end knows the same PSK (a.k.a. group password) that the client knows.

This means that in the PSK-case, anyone with knowledge of the PSK (it can be cracked, ex or other rogue employees have it, anyone who can download your vpn client config or anyone who has had temporary access to a machine with your VPN information configured has it, etc.) and who is capable of intercepting traffic between a vpn user and your vpn concentrator (coffee shop|home|hotel wifi, FakeIKEd, etc...) can steal the user's credentials and make their own connection to your network using them.

AFAIK, there are three well-supported ways to use IPSec to do client-termination "safely":

  • For those with a deployed PKI or those with the resources and inclination to deal with the overhead of deploying one, certificates are probably the way to go. Certificates provide a means for the client to authenticate the server and for the server to authenticate the client.
  • For folks using a Cisco VPN client or another client that uses XAUTH/MODE-CONFIG, you should enforce the use of Hybrid mode IKE (Cisco calls it Mutual Group Authentication) wherein the phase 1 exchange is authenticated as part of the ensuing XAUTH/MODE-CONFIG exchange using a certificate for the server-side only. This is much easier to manage than the above because only the VPN concentrators need a certificate.
  • Those with IPSec clients using L2TP/IPSec such as the Windows and OSX built-in clients should require a certificate-based phase-1 exchange. You do not, however, have to issue certificates to all your users! You can use a single client-side "machine auth" certificate that is shared among all your users for your phase-1 exchange (because that enables the client to authenticate the server during phase 1) and use passwords via PAP or MSCHAP or whatever for the actual "user authentication" in the L2TP exchange.

I don't have the cycles at the moment, but I'd love to see someone document the above three "safe" configurations for both the windows native client (potentially both with and without the CMAK), the OSX native client, the Cisco client, Cisco concentrators, ipsec-tools+l2tpd-base concentrators, openswan, etc.. Does this already exist somewhere? Cheers!

[ Reply to This | # ]