Designing for a Secure Remote Access Infrastructure

---

Maintaining data security is becoming more important each year as more organizations establish network links between them to share information and increase productivity and as more employees are allowed to work from home. These connections create the need for a mechanism to manage remote access to a network. Because of these security concerns, many security designs include virtual private networks (VPNs).

You can set up the Routing and Remote Access Services (RRAS) on Windows Server 2003 to support a VPN. After deciding whether you will allow remote access to your network, you will need to weigh security risks and benefits of the various protocols that are available to you for remote access. This includes the authentication protocols and the data transmission protocols.

A Windows Server 2003 RRAS server uses PPP to establish a wide area network (WAN) connection between two devices. These two devices need to agree upon specific information before they can communicate. The PPP specification sets no particular authentication protocol as a standard. The authentication protocol is negotiated with the Link Control Protocol (LCP) during the Link Establishment phase. During this phase, the two devices establish specific network parameters like the size of a frame, whether to use compression, and the authentication protocol to use for validating the user.

In the following sections we will discuss the various protocols that can be used by Windows Server 2003 to authenticate clients or servers on your network.

Authentication Protocols

Windows Server 2003 has many built-in protocols. In the following sections, we’ll describe the protocols that can be used for authentication.

Password Authentication Protocol (PAP)

With Password Authentication Protocol (PAP), the user ID and password are transmitted in clear text to the server, where it is compared to the server’s version of the same information. This is not a secure means of authenticating a user and should be avoided in most environments.

Shiva Password Authentication Protocol (SPAP)

Shiva Password Authentication Protocol (SPAP) was developed for the ShivaLAN Rover product. It transmits the password in a reversible encryption format. This means that this protocol is subject to replay and server impersonation attacks. The password encryption format is also easy to break. This protocol should not be enabled because there are better protocols supported by Windows Server 2003 and this is only here for backward compatibility with devices that support only SPAP.

Challenge Handshake Authentication Protocol (CHAP)

Challenge Handshake Authentication Protocol (CHAP) is the industry standard protocol for performing PPP authentication and is popular among Internet Service Providers (ISPs). This protocol uses the challenge-and-response mechanism for validating the user. When the client and server try to initialize a PPP session, the server sends a challenge to the client in the form of a random number and a session number. The client concatenates the user’s password to the challenge and hashes it using an MD5 algorithm with a shared secret to generate a 128-bit response.

Note

A hash is a fixed-length value that is a nonreversible form of encryption. The value is sent through a function referred to as a hash function and a unique value is returned. It is sometimes referred to as a one-way hash. This means that there is no way to determine the information in the hash from the hash itself.

The server compares the hash that it receives with the one it generates. In the case of a Windows Server 2003 RRAS server, it would make a request to the domain controller for the user’s password and concatenate it to the challenge it sent to the client. It would then hash the challenge and compare it with the response it received from the client. If they match, the user is authenticated and a PPP data connection is established to the RRAS server. The user is not authenticated on the network until they log in to the domain. In other words, when you connect to the RRAS server, you authenticate your remote access connection, using a form of CHAP or smart card authentication through EAP; once you are connected, you will have to authenticate to access network resources. If you are using a Windows 2000 or later client, you will access network resources using Kerberos authentication; otherwise, you will use a form of NT LAN Manager (NTLM) authentication.

The shared secret for the hash algorithm should not be sent over the network connection, or it should be encrypted by setting up a trust between the client and the server, which would establish a key on both sides through some mechanism not defined in the CHAP protocol. The secret can be variable (just as long as the server and client stay in sync) to discourage replay attacks. The secret also can allow for setting a time limit of use between challenges so that it will expire and you can limit the time of exposure to any single attack because the attacker would need to figure out the new secret.

The advantages to using the CHAP protocol for authentication is that it is a standard that is supported on many platforms. PAP is supported on many platforms also, but it has the disadvantage of passing the password over the network. CHAP does not send the password to the server; it hashes it, which provides for the encryption of the password.

A disadvantage to CHAP is that it requires that you store the passwords in a reversible encryption format so that the domain controller can return the password to the RRAS server. This makes the server susceptible to attackers using tools like l0phtcrack that crack passwords based on hashing values and compare them to the hash. If you must use this form of encryption, make sure you secure all copies of your accounts database, including backups, and that you limit physical access to the server. In addition, the passwords are passed over the network to the RRAS server, making them susceptible to attack, so you will need to consider encrypting the connection between the domain controller and the RRAS server.

Note

CHAP is defined in RFC 1994, entitled PPP Challenge Handshake Authentication Protocol (CHAP).

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is Microsoft’s version of CHAP. It uses the MD4 algorithm for the hash and the Data Encryption Standard (DES) encryption algorithm to generated the hash. It also provides a mechanism for changing passwords and reporting errors with the authentication process. MS-CHAP was developed for Windows 3.1 and the original version of Windows 95. It has been replaced with MS-CHAPv2 (discussed next) due to some security issues, such as sending two parallel hashes: LAN Manager and NT LAN Manager. The LAN Manager hash was much weaker and easily broken by network tools. This then aided in an attack on the NT LAN Manager hash. It also did not authenticate the server, so it was subject to man-in-the-middle attacks and replay attacks. These were addressed in MS-CHAPv2.

Note

MS-CHAP is defined in RFC 2488, entitled Microsoft PPP CHAP Extensions.

Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAPv2)

In response to security issues discovered in the MS-CHAP protocol, Microsoft released Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAPv2). This is the strongest password protocol supported by Windows Server 2003 for remote access and should be used when smart cards or certificates are not an option. MS-CHAPv2 disables LAN Manager Security, which means that the original Windows 95 and older clients will not be able to authenticate. It uses a 16-byte authenticator response to verify that the Windows Server 2003 RRAS server is responding with a SUCCESS message. These and other improvements make this fairly strong, but it still suffers from being based on user password complexity like other forms of password authentication. It would be a good practice to use a strong password policy when using MS-CHAPv2.

Note

Bruce Schneier of Counterpane Systems and Mudge from L0pht Heavy Industries have two articles on Bruce Schneier's website detailing the security vulnerabilities of MS-CHAP and MS-CHAPv2. You can find the articles at www.schneier.com/paper-pptp.html and www.schneier.com/paper-pptpv2.html.

Extensible Authentication Protocol (EAP)

Extensible Authentication Protocol (EAP) is a standard way of adding additional authentication protocols to PPP. EAP provides support for certificate-based authentication, smart cards, and other protocols like RSA’s SecurID. It allows third-party companies to provide even stronger authentication protocols to meet your company’s security needs. Windows Server 2003 comes with an EAP package for using smart cards or MS-CHAPv2.

Note

Windows Server 2003 comes with two EAP packages: MD5-CHAP and Certificate or Smart Card. The MD5-CHAP is just a test package used to troubleshoot EAP connections and should not be used in production.

Smart Cards

A smart card is a card that has a chip in it that securely stores data. This data usually consists of digital certificates and the user’s private keys. Smart cards use a two-tiered authentication mechanism, so the certificates and keys are not accessible to someone if they were to steal the smart card without the user’s PIN. You can use a smart card to establish a PPP data connection with the RRAS server, but the user will still need to log into the network with both a user ID and password or through the smart card. Using smart cards requires a Public Key Infrastructure (PKI) to manage the certificates used to authenticate users. PKI, certificates, and smart cards are discussed in detail in Chapter 6.

Deciding on Which Authentication Strategy to Choose

There are some things that you need to consider when designing for authentication security for a remote access infrastructure. You should avoid the use of PAP or SPAP on your RRAS server. Both of these protocols send the password over the wire, which means it can be captured and cracked. You are better off using one of the versions of CHAP or EAP. Due to security problems with MS-CHAP, Microsoft recommends that you use EAP or MS-CHAPv2 for authentication, preferably EAP if you have a public key infrastructure. In fact, by default, Windows Server 2003 installs RRAS with CHAP and MS-CHAP disabled.

If you must use PAP, SPAP, or CHAP to integrate with third-party products or non-Windows clients that do not support MS-CHAPv2 or a common EAP mechanism, you will need to enable reversible encryption in Windows Server 2003 Active Directory. This is done one of two ways: using the Account tab on the user’s Properties dialog box or using the Domain Security Policy snap-in.

To enable reversible encryption from the user’s Properties dialog box, follow these steps:

1. Open the Active Directory Users And Computers snap-in.

2. Open the property page for the user account that requires reversible encryption by right-clicking the user account and choosing Properties from the context menu.

3. In the user Properties dialog box, select the Account tab.

4. Select the Store Password Using Reversible Encryption option in the Account Options list box, as seen in Figure 3.7.

   
   Figure 3.7: Selecting the Store Password Using Reversible Encryption option

5. Click the OK button to enable reversible encryption.

To enable reversible encryption from the Domain Policy snap-in, follow these steps:

1. Open the Domain Security Policy snap-in (you could also do this in the default domain group policy).

2. Select Security Settings Account Policies Password Policy.

3. Enable the Store Passwords Using Reversible Encryption For All Users in the domain policy.

If you need to enable reversible encryption, you should try to minimize the number of accounts affected by enabling it for specific users only. You would then want to make sure that these users have difficult passwords to guard against brute force attacks or dictionary attacks on the passwords. You would do this for the domain only if most of your users were Macintosh or Linux users because you would need to support the CHAP protocol or if you are an ISP and not sure what OS your users will be using. You should investigate using EAP if you need a more secure solution for integrating various operating systems.

You should determine how important security is for your remote access infrastructure. You will need to factor in what types of clients you are using and the costs associated with the security technology. If security is the most important thing, then you should use the EAP option. This means that you could use smart cards or SecurID to provide authentication. You will also need a PKI to support smart cards, as well as make sure the smart card solution covers all of your client operating systems and devices.

If you don’t deem security important enough to warrant smart cards and a PKI because the associated costs for physical hardware and administration are too much for your organization, you should choose MS-CHAPv2 if you have Windows clients and make sure all the other protocols are disabled. You should strive to use only the most secure authentication method for your clients. If you have non-Windows OSes, then you may need to enable CHAP if you do not choose to use a smart card solution or can’t find a version of the PPP protocol that supports MS-CHAPv2 for the client.

In summary, you should consider the following when choosing an authentication strategy:

• You should choose EAP using smart cards to provide for two-factor authentication. Smart cards will have a certificate that in combination with the user’s password or PIN will validate the user. If the person trying to authenticate does not have both, then they will not be validated. The drawback of EAP is that it requires a PKI, which means higher management costs and more complexity in the network infrastructure.

• You should choose MS-CHAPv2 in an environment in which you have Windows 98 or greater clients and do not want to maintain a complex PKI infrastructure.

• You should choose CHAP or PAP when you need to support a diverse set of OSes and devices and do not require strong security.

In the “Choosing an Authentication Strategy” Design Scenario, you will design an authentication strategy for a Windows Server 2003 network.

Design Scenario: Choosing an Authentication Strategy

Frankfurters, Inc. needs to set up a VPN to allow employees to access a terminal server that runs various applications they can use to do work on the road and at home.

During the design process, you interviewed the following members of the company:

CFO There is no budget to purchase servers or hire additional staff in this cycle. We will need a solution that allows us to use our current hardware and staff.

CIO Frankfurters has a small IT staff that is already overextended keeping up with the applications and servers that are currently installed on the network.

Network Administrator We have a strong password policy that is enforced by a password policy in Active Directory. We have standardized all our clients on Windows 2000 or greater.

1. Question: You need to come up with an authentication strategy for Frankfurter s. What would you recommend? Answer: You should recommend the use of MS-CHAPv2 because Frankfurter s does not have the budget to implement PKI, which would be necessary with EAP. The main weakness of MS-CHAPv2 is that it relies on passwords to generate session keys, so you will want to stress the importance to Frankfurter s staff of maintaining its strong password policy.

Determining What Encryption Method to Use

After you have determined the authentication strategy for your remote access clients, your VPN will still be vulnerable to data alteration and network monitoring. You will need to decide how you will encrypt the data traveling over the connection to prevent these attacks. This is especially important in the case of a VPN that is using the Internet as a means of connection. The encrypting of data over the public network is what makes the connection private. You can choose between three different ways to set up encryption for your VPN connection, and each has its strengths and weaknesses:

Point-to-Point Tunneling Protocol (PPTP) PPTP is a Layer 2 tunneling protocol that encapsulates PPP packets into IP datagrams. The resulting datagram can be routed over IP-based networks and take advantage of the authentication, compression, and encryption services provided by PPP to authenticate a user with the RRAS server supporting PPTP. PPTP provides for encrypting traffic through the Microsoft Point-to-Point Encryption (MPPE) protocol. The session keys for encrypting the traffic are generated from the MS-CHAP or EAP passwords; therefore, you must be using MS-CHAP, MS-CHAPv2, or EAP to support encryption with PPTP.

Layer 2 Tunneling Protocol/IP Security protocol (L2TP/IPSec) L2TP also encapsulates PPP packets in an IP datagram as PPTP does. This means that it can take advantage of the services provided by PPP, like authentication or compression. However, it does not use the MPPE protocol to provide for encryption of the PPP packet. MPPE is considered a proprietary section of PPP, so it leads to compatibility problems between OSes and devices. Instead, L2TP takes advantage of IPSec to provide encryption. IPSec supports many types of encrypting technology and is not limited by one technology as PPTP is. L2TP provides for user authentication, as PPTP does, but also provides for computer authentication through Kerberos, certificates, or preshared keys because it relies on IPSec. The combination of L2TP and IPSec is sometimes referred to as IPSec transport mode. It is also more widely supported on non-Windows-based operating systems and devices. L2TP\IPSec is now supported on Windows 98 or later operating systems and is available for download from Microsoft.

Note

You can download the latest L2TP\IPSec client for Windows 98 or later at www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp.

IP Security (IPSec) protocol IPSec can be used alone to establish an encrypted VPN connection between two devices, which is referred to as IPSec tunnel mode. IPSec tunnel mode provides for machine authentication through Kerberos, PKI certificates, or a pre-shared key. It does not provide for user authentication, so it is not as useful for client-to-server VPN connections. It is typically used in a gateway-to-gateway connection in which one of the end points does not support L2TP.

You need to consider different aspects of your network infrastructure and the devices that you use when designing an authentication and encryption strategy for your VPN. You should consider the following items in your VPN design:

Compatibility with NAT Because PPTP encrypts the data in the PPP packet only, it is immune to NAT and the IP datagrams can be manipulated and without you having to worry about them being discarded at the other end. L2TP is not compatible with NAT because it uses IPSec to secure its IP packets. This means that after the NAT server tries to update the IP address or the port of the packet, it will fail the integrity check and the packet will be discarded. You can get around this limitation with a Windows Server 2003 RRAS server because it supports a technology called NAT-Traversal. NAT-Traversal encapsulates the IPSec packet into a UDP datagram that can then traverse the NAT device, much like PPTP is packaged in a PPP packet. The clients and the server need to support NAT-Traversal for this to work.

User authentication PPTP and L2TP/IPSec support user authentication on a Windows platform through the authentication protocols discussed earlier. IPSec tunnel mode does not support user authentication.

Computer authentication PPTP does not support machine authentication. L2TP/IPSec does because it relies on IPSec to provide its encryption. IPSec supports verifying the identity of the machine through one of three mechanisms: Kerberos, PKI certificates, or a pre-shared key. The PKI certificate is considered the strongest of the three, but it requires a PKI infrastructure. Kerberos is second and just requires an Active Directory domain in a Windows Server 2003 network with a Windows 2000 or greater client. Pre-shared keys are the easiest to configure because they require no additional infrastructure, but there are logistic problems for distributing the keys securely and most should be used in a test lab or on small networks when there are no other options.

Compatibility with most network devices PPTP is primarily used on Windows-based networks. L2TP/IPSec is widely supported by many devices and OSes. You will choose L2TP and IPSec to connect with non-Windows servers and devices.

In summary, when designing an encryption strategy for your network, the following points may be helpful:

• You should use L2TP/IPSec as a VPN solution whenever possible. It provides the most security options and Microsoft recommends using it for remote access. It also gives you the most compatibility with other network devices and OSes.

• For maximum security, you should choose EAP with smart card support for the user authentication protocol, PKI certificates installed on the machine to provide machine authentication, and IPSec with 128-bit encryption. This solution would require a PKI and the most amount of administrative overhead. PKI will be covered in more depth in Chapter 6.

• You can scale back on the administrative overhead of PKI and still provide a reasonably secure solution by using MS-CHAPv2 for the user authentication protocol, Kerberos for the machine authentication through Active Directory, and IPSec for the encryption protocol with 128-bit encryption. This would not require any extra servers but still provide a reasonably secure environment for most users.

• You should use PPTP if you have an all-Windows-client network and want to support Windows 95 clients or later. You can also use it if you do not want to install the L2TP/IPSec client on Windows 98, ME, and NT 4. In addition, you can use PPTP to provide a VPN tunnel through a NAT device if it does not support NAT-Traversal.

• L2TP/IPSec and IPSec can be tunneled through a NAT device (like a firewall or Windows Server 2003 RRAS server that is providing NAT) only if the NAT device and the client supports NAT-Traversal. If not, you will need to use PPTP or set up a connection from the NAT device to the gateway on the other network through an IPSec tunnel mode or L2TP/ IPSec if both sides support it.

• You should use IPSec tunnel mode only if one of the devices does not support L2TP; otherwise, take advantage of the security provided by the additional user authentication.

In the “Designing a VPN Solution” Design Scenario, you will design a VPN encryption solution.

VPNs can also be used to establish secure connections to internal networks. You would then use Kerberos or NTLM to authenticate on the internal network for access to network resources. This would be especially true when connecting to internal networks through a demand-dial routing connection.

Design Scenario: Designing a VPN Solution

Frankfurters, Inc. has implemented a new customer relations management application to improve customer service. Most of the sales staff work from home or on the road. The company has issued notebook computers to its sales staff. The notebooks are running Windows XP Professional. The network uses Windows Server 2003 Active Directory to authenticate the users. The data that is in the customer service application is sensitive customer information and needs to be protected. The company wants to use the cheap access to the Internet to provide access to the company’s network.

1. Question: What encryption technology should you propose for the VPN? Answer: Frankfurter s should set up a VPN solution to use L2TP/IPS ec.

---