VPN Standards and Interoperability

Q. Does Microsoft support standard protocols for virtual private networking?

A. Microsoft supports only standard protocols that have been proven to interoperate. Windows XP and Windows 2000 Professional include an integrated VPN client. Windows Server 2003 and Windows 2000 Server include an integrated VPN server (also known as a VPN gateway).

For remote access VPNs, Windows includes support for the Point-to-Point Tunneling Protocol (PPTP) (RFC 2637) and the Layer Two Tunneling Protocol (L2TP) (RFC 2661, a Proposed Standard) that are secured using Internet Protocol Security (IPSec) (RFCs 2401-2409, Proposed Standards) with IPSec Encapsulating Security Payload (ESP) in transport mode. The integration between L2TP and IPSec is described in RFC 3193 (Proposed Standard). Both the client and server implementations use industry-standard methods for IPSec trust (X.509 certificates) and industry-standard user authentication, including the Challenge-Handshake Authentication Protocol (CHAP) (RFC 1994, Proposed Standard), the Microsoft Challenge-Handshake Authentication Protocol version 2 (MS-CHAP v2) (RFC 2759), and the Extensible Authentication Protocol (EAP) (RFC 2284, Proposed Standard).

For site-to-site VPN connections, Windows Server 2003 and Windows 2000 Server support PPTP, L2TP/IPSec, and IPSec TM.

All the protocols supported have been demonstrated to provide sufficient multivendor interoperability.

Q. Why do other vendors claim that they support standards and that Microsoft VPN technologies are proprietary?

A. Most vendors making this claim are using IPSec TM for remote access. Unfortunately, the IPSec RFCs do not describe the use of IPSec TM for remote client access. In particular, the RFCs provide no mechanisms for user authentication, IP address assignment, and name server address assignment.

As a result, vendors implementing a remote access solution based on IPSec TM have been forced to extend the protocol. These extensions are not standard, and drafts that were introduced to the IETF to define a standard have been withdrawn. As a result, there is no standard for remote client access using IPSec TM. Consequently, many vendor implementations are not interoperable.

In contrast, Microsoft has followed several standards precisely, using L2TP (RFC 2662, a Proposed Standard) as the remote access protocol and IPSec (RFCs 2401- 2409, Proposed Standards) as the encryption protocol, combined in a manner described in the L2TP/IPSec RFC 3193.

Q. What VPN protocols are Internet Engineering Task Force (IETF) standards?

A. The following VPN protocols are IETF standards:

• L2TP over IPSec using ESP transport mode (L2TP/IPSec)

  L2TP, defined in RFC 2661, is an IETF Proposed Standard, and the integration of L2TP with IPSec is defined in RFC 3193. Implementations from Microsoft, Cisco, and Nortel Networks have been demonstrated to interoperate. L2TP/IPsec tunnels traffic, preserving the full end-to-end semantics of communications conducted inside the tunnel. It fully supports legacy address and host configuration technologies, such as Internet Protocol Control Protocol (IPCP). It is commonly used by customers in multivendor environments. It supports password authentication using PAP, CHAP, MS-CHAP, and MS-CHAP v2, and it supports strong authentication using EAP.

• IPSec TM

  The use of IPSec TM for VPNs, described in the Internet draft draft-ietf-ipsec- dhcp-13.txt, has been approved as an IETF Proposed Standard. It tunnels traffic, preserving the end-to-end semantics of the communications it is carrying. The trust model is defined as part of the IETF standard using either standard X.509 certificates or preshared keys. The standard supports both dynamic and static addressing. IPSec TM is appropriate for site-to-site VPN connections and has been demonstrated to be interoperable by Microsoft, Cisco, Nortel, and others. There is no standard for legacy user authentication within IPSec TM, which makes it unsuitable for use in remote access. It is implemented by most VPN gateways. There have been many public interoperability demonstrations and customer deployments using real products.

Q. What VPN protocol or protocols are nonstandard and why?

A. The following VPN protocols are nonstandard:

• IPSec TM with XAUTH (extended authentication), mode config, hybrid-auth, or CRACK

  After considering alternatives such as mode config, the IETF adopted the Internet draft draft-ietf-ipsec-dhcp-13.txt as an IETF Proposed Standard for configuration of IPSec TM. Similarly, the IETF considered and rejected standardization of XAUTH, Hybrid, and CRACK authentication methods. Mode config was rejected for IETF standardization because it lacks the flexibility and generality of Dynamic Host Configuration Protocol (DHCP), complicates IPSec failover scenarios, and requires modifications to Internet Key Exchange (IKE) that are considered inadvisable. Similarly, XAUTH was rejected because it is incompatible with existing IETF authentication frameworks such as EAP, Simple Authentication and Security Layer (SASL), and Generic Security Service-Application Programming Interface (GSS-API); requires IKE modification; and contains major security flaws, as documented in the article, “Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets” by John Pliam (http:www.ima.umn.edu/~pliam/xauth/). The IETF rejected standardization of Hybrid and CRACK because of concerns about increasing the complexity and security vulnerabilities with IKE. While the IP Security Remote Access (IPSRA) working group (WG) is working on standardization of legacy authentication methods via pre-IKE credential (PIC), work is not yet completed and interoperable implementations are not available. So far, there is no IETF standard providing accurate accounting in IPSec TM. Given the current state of IPSec TM standardization for remote access, Microsoft believes that L2TP/IPsec is the more mature technology.

• IPSec TM using IPSRA definitions for remote access

  The IPSRA WG has been chartered with standardizing the use of IPSec TM in remote access scenarios. So far, the group has standardized use of DHCP with IPSec TM for configuration (Internet draft draft-ietf-ipsec-dhcp-13.txt, now a Proposed Standard) and is working on legacy user authentication via PIC. Microsoft is a coauthor of the IPSRA documents and believes that they show promise. Use of DHCP for address assignment is a significant improvement compared to mode config. PIC supports the use of EAP for user authentication without modifying IKE—another dramatic improvement over XAUTH. However, while several vendors have implemented IPSec/DHCP, there are no known PIC implementations.

Q. Which configurations have been shown to work between Microsoft’s client implementation of these VPN protocols and third-party VPN gateways?

A. Since the second quarter of 1999, Microsoft has been publicly demonstrating its implementations of L2TP/IPSec VPN clients and the Cisco Internetwork Operating System (IOS) implementation for remote access. Since then, implementations have shipped on Cisco VPN 3000, 5000, and IOS gateways; Nortel Networks Contivity gateways; and gateway products from Intel, Ericsson, Nokia, 3COM, and NetScreen (all of which work with X.509 certificates for computer trust and with password- based authentication). In addition, a number of successful interoperability tests have taken place between the Windows client and other third-party VPN gateways at IPSec industry interoperability meetings known as bakeoffs.

Q. How can IPSec tunnel mode not be a standard for remote access VPNs, given that it is part of IPSec, which is approved as an IETF Proposed Standard?

A. The IPSec protocol includes two modes of operation: transport mode and tunnel mode (TM). Transport mode defines a protocol for encrypting communications between two end-systems in such a way that no other computer or device is involved in the dialog—ensuring end-to-end privacy and integrity of the data. The IPSec standards define a second mode of operation known as TM. TM was defined to enable routed connections between two networks—encrypting the traffic on behalf of all computers on the two networks. The best way to think of this is two routers that encrypt traffic before passing it over the Internet.

Neither IPSec transport mode nor IPSec TM provides all the functionality necessary for remote access. Remote access is a hybrid model where one computer is an end- system (the client) and the second system is an intermediate system (the server). To use either IPSec transport mode or TM, additional protocols are required to manage the semantics of remote access. Specifically, there needs to be an interoperable protocol for automatic address assignment, a method for accounting by tracking session state, and an interoperable mechanism for legacy user authentication.

To meet these requirements by using IPSec transport mode, two IETF standards are combined (L2TP and IPSec transport mode). This is the solution supported by Microsoft in Windows 2000, Windows XP, Windows Server 2003, and (with Microsoft L2TP/IPSec VPN Client) most earlier members of the Windows family of operating systems.

To meet these requirements using IPSec TM, vendors developed proprietary technologies such as mode config and XAUTH. These technologies were developed quickly and were not subjected to rigorous analysis within the IETF before deployment. Once that analysis was conducted, serious flaws were found, and the technologies were rejected for standardization. The IETF chose to advance alternative approaches to IPSec TM for remote access, such as IPSec/DHCP and PIC. Microsoft endorses the IETF’s analysis and recommends that customers reject flawed proprietary extensions to IPSec, such as mode config and XAUTH.

Q. Another vendor who supports IPSec tunnel mode claims they are standard because they use XAUTH and mode config. They say this addresses remote access for IPSec tunnel mode. Isn’t an IPSec implementation that includes these protocols considered a standard?

A. XAUTH and mode config are not IETF standards. They have been extensively analyzed and have been rejected because of major flaws. Therefore, IPSec TM implementations including these protocols cannot claim standards status and have known defects for which no fix is available.

XAUTH changes a core IPSec protocol named Internet Key Exchange (IKE). The IKE protocol is critical to IPSec, as it is used to negotiate the security parameters of the IPSec security association, including computer trust, encryption keys, and security methods. The IKE protocol took approximately nine years to develop within the IETF. Every proposal was carefully scrutinized for security weaknesses and was rejected if it did not meet the rigorous requirements for strong security. In contrast, XAUTH was developed in a short period of time and without the same scrutiny as IKE. XAUTH fundamentally changes the IKE protocol. The original authors of the IKE protocol reviewed XAUTH and discovered serious security issues (explained in the article, “Authentication Vulnerabilities in IKE and XAUTH with Weak Pre-Shared Secrets”) that adversely affect the important benefits of IPSec. Under criticism from IETF members, XAUTH was removed from the IETF standards track.

In a related activity, the IETF Security Area Directors issued an e-mail on August 2, 2001, declaring a moratorium on changes to the IKE protocol. In this mail, they indicated that IPSec security could be adversely affected by the complexity of IKE and that IKE changes should not be made until IKE was simplified. The mail went on to list various technologies (including XAUTH, hybrid auth, and others) as not helping to simplify IKE. As a result, L2TP/IPSec remains the only IETF standard method for remote access VPN with IPSec encryption.

Q. Why doesn’t Microsoft implement IPSec tunnel mode with XAUTH and mode config?

A. There are several key reasons for this.

XAUTH contains serious security flaws for which no known fix is available, and it has been rejected for IETF standardization. Given this, Microsoft believes that it would be irresponsible to endorse this technology, especially when IETF standards- based technology is under development.

XAUTH is incompatible with existing IETF authentication frameworks such as EAP and GSS-API. This means that developers who want to develop authentication techniques for the Windows platform would need to develop their methods using multiple, incompatible APIs. This prevents customers from using existing authentication methods within remote access scenarios. For developers, it increases the complexity and cost of developing a new authentication method. Rather than introducing another authentication framework to the detriment of customers and developers, Microsoft endorses efforts within IETF and IEEE to extend the applicability of EAP. This approach allows customers and developers to leverage their efforts, developing authentication methods with universal applicability, such as in wireless scenarios (via 802.1X).

Because of the poor interoperability of XAUTH and mode config, Microsoft could not implement the technology and have it work with more than one vendor.

L2TP/IPSec is already an interoperable standard that is supported in commercial products from leading networking companies and can be implemented in models similar to XAUTH with IPSec but with much stronger security, reliable accounting, and standards-based configuration.

The IETF rejected XAUTH and mode config, and it has a more appropriate IPSec TM–based remote access solution in development through the IPSRA working group.

Q. Why is interoperability important to customers for remote access VPN?

A. There are several reasons why interoperability is important.

You might need to support gateways from different vendors within your company. Maybe you have decentralized purchasing, or maybe you will be involved in a merger or acquisition with someone who chose a different vendor. By using interoperable standards, you can reduce the time it takes to integrate your business infrastructures and benefit from the business change.

Many companies are looking for ways to streamline supply chain management and other types of interbusiness transactions. VPNs make it possible to create secured extranet zones, where companies can do more than share Web applications. By giving your business partner remote access to the extranet zone, you can support a broad range of protocols and a much richer set of scenarios than when using HTTP alone. Interoperability lets you build such an extranet without having to dictate vendors or products to your business partner—something that can create serious deployment barriers due to conflicts in hosting multiple VPN clients in end-user computers.

Interoperability allows customers the freedom to choose a client that is easy to use and deploy, while independently selecting a server based on its characteristics as a server. Rather than compromising on your server or client, you can choose the best server for the situation. Using interoperable standards also helps reduce deployment cost and helps avoid client deployment issues.

Q. Why is Microsoft such an advocate of interoperable VPN standards?

A. Customers have told Microsoft they prefer that Windows come with the networking technologies required to support core connectivity scenarios. The adoption of VPN for remote access is growing rapidly and is being used by most companies. For economic reasons, Microsoft sees remote access VPN replacing dial-up remote access to the company network because it allows companies to use a single Internet link to support all their remote access users, thus reducing modem pool management costs, multiple telephone line costs, and so forth. This trend makes VPN a core connectivity scenario.

Any type of authenticated network access (dial-up, VPN, or 802.1X) requires integration with the operating system at many levels, including several layers within the IP stack, operating system credential management, and user operating system login. This multilevel integration is necessary to make the solution easily deployable; to ensure application compatibility; to ensure clean operating system upgrade capability; and to provide a single sign-on experience for network access, operating system access, file sharing, printing, and other network applications.

Improper integration can compromise system security, disrupt applications, and prevent customers from carrying out even basic service pack upgrades to the operating system. It can also result in having to maintain separate logon systems for network access, applications, and the network operating system. Because of this, Microsoft considers it a responsibility to deliver well-integrated, interoperable VPN clients. The best way to achieve this goal is through interoperable industry standards.