On Mon, 20 Feb 2006 11:50:40 -0500, "Lee Badman" <[EMAIL PROTECTED]> said: > Another question from the VPN angle... > > Curious how others view PPTP these days as a "viable" security > mechanism for bothe remote access VPN and in wireless environments. > Not strong enough? Too easily exploited? Good enough for wireless but > not remote access? Moving toward or away from PPTP?
Short answer: We use PPTP/MPPE for WLAN authentication, as an alternative to web redirect, and for remote access. We find it very supportable. We have a different VPN password from other services. Medium answer/justification/diatribe: Network layer never provides any real access control, authorization, or privacy. PPTP/MPPE is entirely suitable because it has no business doing anything other than weak accountability anyway. However, there be dragons if you authenticate your PPTP users on your Active Directory: don't do that -- more details in long answer. Long answer/much diatribe: There are a few points here: 1) There are three things that a VPN provides: a) Network access authentication. This is great for wireless as an alternative to web redirect -- domain login w/ roaming profile, etc, is a good reason for this. Network access alone can never imply any other service authorization, but it does provide some accountability. b) Location virtualization (an "on campus" IP address). This allows service administrators to limit their exposure to applications with suspect resiliency (notably, anything from Microsoft that opens a socket). In no way does this imply authorization to any service -- there must still be end-to-end authorizaiton negotiation -- but it does mitigate some risk of zero-day and misconfiguration exploits of application weaknesses. c) Partial network-layer encryption. "Partial" because (like so- called "wireless encryption") it isn't end-to-end. For this reason, this is not suitable for any application that requires privacy. In spite of this unsuitability, some applications have sufficient value that we are willing to excuse their lack of an appropriate privacy model and attempt to mitigate the risk through VPN encryption. As a temporary mitigation, MPPE encryption is better than nothing and does reduce the risk of running these applications on the network in the clear. This can only be considered a temporary work-around for these applications, however. 2) Perhaps the most important vulnerability of the MPPE encryption is the imminent hackability of the user's password. Since the VPN is only providing network access, and no authorization should ever be provided by network access alone, this shouldn't be a big deal -- if someone's VPN password gets hacked, all the hacker should get is network access. We'd rather that not happen, since we do count on some level of accountability, but it isn't "game over". Unfortunately, people tend to use the same password for different services. Hence, we go to some effort to force the VPN password to be different from other passwords the user may have to access resources. This is a point of caution for those who use their AD to authenticate VPN clients -- these users' passwords need very strong requirements in terms of length, complexity, and expiration, since exposure of a user's AD password is normally considered a Very Bad Thing and compromise of this password via PPTP/MPPE is easy. Better would probably be to have a separate VPN authentication system (could be a stand-alone Windows IAS server, just don't let it join the domain), then have a more supportable password policy. 3) Usability and support are absolutely critical for a successful VPN solution. PPTP isn't perfect, but it is more likely to be something any user can set up and succeed in using without incurring undue overhead or help desk costs than any other VPN solution we've used. The scalability of PPTP servers (we use cisco 7301 routers) is very good, making it an extremely cost-effective solution. We have tried (semi-)proprietary IPsec solutions (mostly Cisco's VPN client w/ a PIX, but others as well) and Microsoft's L2TP+IPsec, and both of these approaches has a much higher cost/user to support. 4) Education is key for the IT community. Perhaps the most common security fallacy is an over-emphasis of the large campus perimeter as a trust boundary. There's a description in the security community: crunchy on the outside, soft and chewy on the inside. There is only one trust boundary: the host. Sysadmins and users must be repeatedly reminded of the trust model: information will be misdirected, corrupted, lost, sniffed, and injected -- be happy that with non-zero probability your packets make it to their intended destination intact. This is not the network's "fault"; it's just how it works. We can do a lot to improve your packets' survival chances, but we can't fundamentally change the model. On a different note, we've done some testing of OpenVPN for a network- layer SSL VPN. Very good stuff and reasonably supportable. Far superior authentication model. We might offer this as an alternative to PPTP if we can work out all the support and business process questions. --ckg -- Clark Gaylord Communications Research Engineer Virginia Tech [EMAIL PROTECTED] "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, Historical Review of Pennsylvania, 1759 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
