Remote Access VPN Requirements and IPSec- Based Implementations

Remote access VPN solutions require user authentication (not just computer authentication), authorization, and accounting to provide secure client-to-server communication, and they require tunnel address assignment and configuration to provide manageability. IPSec-based implementations that do not use L2TP are using nonstandard proprietary methods to address these key remote access VPN requirements.

User Authentication

Many IPSec TM implementations do not support user-based authentication with certificates. When computer-based authentication is used by itself, it is impossible to determine who is accessing the network in order to apply proper authorization. This is the reason why IPSec TM can be used only for site-to-site connections and not for remote access for individual users. With today’s multiuser operating systems, many people use the same computer, and without user-based authentication, IPSec TM cannot distinguish between users. Thus, using IPSec TM without user authentication is inappropriate for use in remote access VPNs.

Third-party IPSec TM implementations based on XAUTH, a non-standards-track proprietary technology, attempt to address this issue by supporting proprietary user authentication technologies along with group preshared keys. As a result, a group preshared key introduces a man-in-the-middle vulnerability, allowing anyone with access to the group preshared key to act as a go-between by impersonating another user on the network. The man-in-the-middle vulnerability is the reason that XAUTH-based IPSec TM implementations have been rejected by the IETF.

More Info

For more information about XAUTH and other proprietary VPN protocols, see Appendix G, “Frequently Asked Questions.”

IPSec TM was designed for site-to-site VPN connections, in which user authentication and tunnel addressing is less of an issue. Because site-to-site VPN connections are usually between routers, fewer computers are needed and address assignment is simplified. Because routers often do not have user-level authentication, computer authentication might be sufficient in many cases. Microsoft supports IPSec TM in Windows Server 2003 for site-to-site configurations that require IP-only, unicast- only communications. In this scenario, user authentication is not an issue and interoperability is good. Windows Server 2003 has also been tested by the VPN Consortium (www.vpnc.org) against all major vendors for IPSec site-to-site connections and has been determined to have full interoperability. It is important to reiterate, however, that IPSec TM is supported for site-to-site only without the use of XAUTH/MODCFG, and it is not supported for remote access for individual users.

Note

For remote access, Microsoft strongly recommends customers deploy only L2TP/IPSec because of the authentication security vulnerabilities and nonstandard implementations of IPSec TM. Microsoft also recommends L2TP/IPSec for multiprotocol, multicast site-to-site configurations. Also, the use of L2TP/IPSec means that an organization does not need to roll out a third-party VPN client to activate VPN capabilities. Everything that is needed for L2TP/IPSec is in the native Windows client operating systems.

While many customers are interested in eventually deploying smart card authentication, in most cases it remains necessary to support legacy authentication methods such as passwords or token cards during the transition period. Some customers might also want support for advanced authentication technologies such as biometrics (for example, retinal scans, fingerprints, and so forth). There needs to be a standard way to accommodate both legacy authentication as well as emerging authentication methods.

IPSec TM, as originally specified, supports only user authentication via user certificates or preshared keys. However, most IPSec TM implementations support only the use of computer certificates or preshared keys. L2TP leverages the Point-to- Point Protocol (PPP) as the method of negotiating user authentication. As a result, L2TP can authenticate with legacy password-based systems through Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP), or MS-CHAP version 2 (MS-CHAP v2). It can also support advanced authentication services through the Extensible Authentication Protocol (EAP), which offers a way to plug in different authentication services without having to invent additional PPP authentication protocols. Because L2TP is encrypted inside of an IPSec transport mode packet, these authentication services are strongly protected as well. Most importantly, via integration with Lightweight Directory Access Protocol (LDAP)– based directories and Remote Authentication Dial-In User Service (RADIUS), L2TP gives the industry a common interoperable way to authenticate users while supporting the authentication services that most customers and vendors already have in place.

While there are vendors working on and proposing other authentication services for IPSec only, these alternatives are not on an IETF-standards track. Rather than supporting existing IETF standards for extensible authentication, these proposals introduce yet another authentication framework—with serious known security vulnerabilities. Microsoft believes that customer needs are best served by keeping security implementations standards-based.

Address Assignment

Currently many IPSec TM implementations use proprietary methods for address assignment and configuration, rather than supporting IETF standards such as Dynamic Host Configuration Protocol (DHCP). Microsoft, along with Sun Microsystems, Intel, and RedCreek, has proposed using DHCP to address and configure IPSec tunnels, allowing integration with enterprise-class IP address management solutions. IPSec TM clients that support proprietary address assignment methods are incapable of supporting the wide range of configuration options already supported by DHCP. In addition, these clients cannot use advances in DHCP technology, such as DHCP Failover, address pool management, or DHCP authentication. They therefore represent a dead-end for IP address management.

Because L2TP uses PPP, it can easily be integrated with existing IP address management systems. PPP clients can use Internet Protocol Control Protocol (IPCP) for address assignment and the DHCPInform message for configuration, while PPP and L2TP servers can integrate with IP address management and configuration systems via DHCP and RADIUS. As a result, L2TP provides good interoperability based on existing standards.

PPTP: An Alternative to IPSec-Based VPNs

PPTP was the earliest widely supported VPN protocol. Developed before the existence of IPSec and PKI standards, PPTP provides for automated configuration and supports legacy authentication methods. Because PPTP does not require a PKI, it can be much more cost-effective and easier to deploy in situations that do not require the most sophisticated security. When interoperating with third-party vendors, PPTP might also be the only viable option when VPN connections must pass through NATs, which are incompatible with any IPSec implementation that does not support the newly developed IPSec NAT traversal (IPSec NAT-T) technology, currently in IETF draft form. With the proper down-level clients, or hotfixes/service packs from Microsoft, all currently Microsoft-supported Windows operating systems, including Windows Server 2000, support IPSec NAT-T. Therefore, lack of support should not be a major concern if an organization wants to deploy IPSec-based solutions on Windows platforms. If third-party interoperability is needed, make sure that the third-party vendor has successfully implemented draft 02 of the IETF IPSec NAT-T specifications.

With Windows Server 2003, you can use IPSec transport mode within a PPTP tunnel to get extremely powerful encryption services while also maintaining the ability to send information through NATs. The Microsoft implementation of PPTP since Windows 2000 adds security enhancements while preserving the other useful properties of PPTP, primarily through the addition of support for MS-CHAP v2 and EAP. These enhancements provide the ability to use smart cards and public-key certificates to strengthen both user authentication and encryption keys. This strengthens protection against both user impersonation and brute-force decryption of intercepted packets. As a result, PPTP can be a useful alternative or complement to L2TP/IPSec-based VPNs. To maintain the proper level of security with PPTP, make sure to implement strong password policy with the use of PPTP.

SSL VPN: Where Is Its Place in the VPN Market?

One of the new technologies making a stir in the remote access market is SSL (Secure Sockets Layer) VPN. Instead of using standard tunneling protocols such as PPTP or L2TP/IPSec, SSL VPN takes advantage of SSL Internet encapsulation to punch through firewalls over Transmission Control Protocol (TCP) port 443, the port that is usually open to allow for SSL-encrypted communications to Web sites. Microsoft does support SSL as part of the overall strategy for remote access, but given the level of security that SSL provides compared to IPSec, it is used as a security option on an application level as opposed to full-blown VPN connectivity. The following table breaks down where SSL- enabled communications come into play in relation to security and accessibility levels.

Table 4-1 shows the Microsoft strategy for remote access solutions.

Table 4-1: Microsoft Remote Access Solutions

	High security	Low security
Full access	L2TP/IPSec (or PPTP)	SSL VPN
Partial access	SSL-enabled Terminal Services	SSL-enabled e-mail with Microsoft Outlook Web Access

There are two types of remote access:

• Full access. With this type of remote access, the machine that is accessing the network is doing so in a way that makes it appear to be virtually on the network. In other words, it’s operating consistent with VPN using L2TP/IPSec or PPTP.

• Partial access. This type of remote access is accomplished by giving remote access to specific applications, such as Terminal Services and Outlook, using SSL remote procedure call (RPC) or Outlook Web Access.

SSL has its uses as long as it remains application-specific. Microsoft has targeted several applications to be accessible remotely using SSL encryption, but each of the applications already has its own authentication and authorization capabilities, which makes SSL a viable option for them.

SSL in itself does not have any mechanism for authentication and authorization. Several vendors give proprietary authorization controls for SSL VPN, but none of these are ratified standards and, as stated earlier, for interoperability Microsoft will strictly adhere to IETF-ratified standards. Because SSL does not have the ability to do authorization control, it provides a lower level of security than L2TP/IPSec or PPTP, which are based on secure and proven PPP methodology and EAP support.