Lesson 1:Remote Access Fundamentals

---

Windows Server 2003 provides two main types of remote access methods: dial-up and VPN. For each remote access type, there are several authentication and encryption protocols to choose from. You will have to choose the remote access type and security protocols based on the clients that will be connecting to your internal network and based on your existing infrastructure. This lesson will describe the two remote access methods and the various encryption and authentication protocols to allow you to make educated recommendations.

After this lesson, you will be able to

• Describe the advantages and disadvantages of dial-up and VPN remote access methods.

• Choose between Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP), given an organization’s requirements.

• List the various methods for authenticating remote access users, and describe scenarios in which each authentication method should be used.

Estimated lesson time: 20 minutes

Remote Access Methods

There are two primary methods for connecting remote users to a private network: dial- up networking and virtual private networking. Dial-up networking enables a remote access client to establish a temporary dial-up connection to a physical port on a remote access server by using the service of a telecommunications provider, such as analog phone lines, Integrated Services Digital Network (ISDN), or X.25. The most common use of dial-up networking is that of a dial-up networking client that dials the phone number of a modem attached to the remote access server. This establishes a circuit between the two devices.

Off the Record 

A dial-up connection was once a dedicated circuit on the Public Switched Telephone Network (PSTN). There would literally be a pair of copper wires, connected by a series of analog switches, that connected the dial-up client to the server. Telephone companies are constantly striving to become more efficient, and today telephone communications are carried digitally. In fact, it’s entirely possible that the only points in which your dial-up connection will actually be a dedicated circuit are between the two modems and the telephone company. After it reaches the telephone company, your traffic might be carried in Internet Protocol (IP) packets, and it might cross the public Internet!

Virtual private networking is the creation of an encrypted, authenticated point-to-point connection across a public network such as the Internet. A VPN client uses special network protocols called tunneling protocols to make a virtual call to a virtual port on a VPN server.

See Also 

IPSec-based VPNs are thoroughly described in Chapter 8.

A common example of virtual private networking is that of a VPN client who makes a VPN connection to a remote access server that is connected to the Internet. The remote access server answers the virtual call, authenticates the caller, and transfers data between the VPN client and the corporate network. In contrast to dial-up networking, virtual private networking is always a logical, indirect connection between the VPN client and the VPN server over a public network such as the Internet.

Real World

There are many factors to consider when choosing between using dial-up and VPN remote access. Obviously, you need to compare upfront and ongoing costs. VPN access has a significant cost advantage because providing dial-up access requires purchasing modem equipment and leasing circuits from your telecommunications provider, whereas providing VPN access uses an existing Internet connection. Though the Internet connection might need to be upgraded to provide the additional bandwidth needed by the VPN clients, the costs will almost certainly be lower than building a dial-up infrastructure.

You should also compare the security level provided by the two access methods. Many people immediately assume that dial-up access provides greater security than a VPN. After all, allowing people on the public Internet access to your entire intranet sounds very risky. However, if you analyze the security risks point-by- point, dial-up and VPN access have similar risks:

• Attackers can methodically identify both dial-up and VPN ports. If attackers want to find your dial-up ports, they’ll use a war dialer. If attackers want to find your VPN ports, they’ll use an IP scanner.

• Once the ports are identified, the attacker will need to authenticate to the remote access server. Both dial-up and VPN remote access servers use exactly the same authentication protocols. However, attackers can send requests to a VPN server faster than they can to a dial-up server. Therefore, dial-up servers have a bit of an advantage here because the long connection time makes them less vulnerable to brute-force attacks.

• Regardless of whether a dial-up or VPN connection is used, it will be difficult for an attacker to eavesdrop on a user’s traffic. Gaining access either to an ISP or a public telephone provider would be difficult for the attacker. It would be much simpler for the attacker to eavesdrop on traffic on either end of the remote access connection by installing a sniffer on the remote access client or server.

  Add it all up, and VPN servers are slightly less secure than dial-up servers, but significantly less expensive. In the real world, you’ll be better off using a VPN and spending the money you save on other security initiatives—like an intrusion detection system to detect brute-force attacks against your VPN server.

VPN Protocols

Windows Server 2003 supports two VPN protocols: PPTP and L2TP. In most circumstances, either protocol will work equally well. They both provide similar levels of privacy and data integrity because they support the same authentication and encryption standards. They primarily differ in stability and compatibility. PPTP is more mature, but it is not an Internet standard. L2TP is relatively new, but it might be supported by a wider variety of non-Microsoft clients because it is an Internet standard.

Planning 

The number of incoming connections supported is one of the factors that differentiate the various editions of Windows Server 2003. Windows Server 2003, Web Edition and Windows Server 2003, Standard Edition can support up to 1,000 incoming PPTP connections and 1,000 incoming L2TP VPN connections. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition each support 16,384 PPTP and L2TP connections. However, Windows Server 2003, Web Edition can accept only one VPN connection at a time, which should be used to manage the server remotely.

PPTP

PPTP is a VPN protocol that takes advantage of the authentication, compression, and encryption mechanisms of Point-to-Point Protocol (PPP), the most common standard used for dial-up remote access. PPTP first stores the IP datagram being transmitted inside a PPP frame. PPTP tunnels the PPP frame within a Generic Routing Encapsulation (GRE) header using IP protocol 47 and a Transmission Control Protocol (TCP) header using port 1723, as illustrated in Figure 12.1.

Figure 12.1: PPTP-tunneled data packet structure

PPTP relies on PPP’s encryption to protect the privacy of the tunneled data. The PPP frame is encrypted with Microsoft Point-to-Point Encryption (MPPE) by using encryption keys generated from the Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1), Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), or Extensible Authentication Protocol (EAP) authentication process. VPN clients must use the MS-CHAP v1, MS-CHAP v2, or EAP authentication protocol in order for the payloads of PPP frames to be encrypted. PPTP does not do the encryption itself; rather, it takes advantage of the underlying PPP encryption by encapsulating a previously encrypted PPP frame.

PPTP requires additional configuration to allow it to traverse a Network Address Translation (NAT) server or a firewall. To allow PPTP traffic through a firewall, the firewall must allow TCP port 1723 and IP protocol 47. Many NAT servers are capable of allowing a client on the internal network to connect to a PPTP server on the public network. The NAT server must specifically support PPTP, however. Although every NAT server is capable of translating standard IP traffic, the GRE protocol requires special consideration. The NAT server built into Routing And Remote Access is one example of a NAT server that supports PPTP.

PPTP has been supported in every version of Windows that has been released since Microsoft Windows NT 4.0 and Windows 98, and it is still the default VPN protocol in Windows Server 2003. Earlier versions of Windows do not support either PPTP or L2TP when initially installed, but you can add support by installing additional software that can be downloaded for free from Microsoft. To use a computer running Windows 95 or Windows 98 as a PPTP client, you must install the Windows Dial-Up Networking version 1.4 Upgrade, available at http://support.microsoft.com/?kbid=285189. Microsoft does not support either PPTP or L2TP on Windows NT version 3.5x, even with a software upgrade.

L2TP/IPSec

L2TP is a standardized RFC-based tunneling protocol. While PPTP uses MPPE to encrypt PPP datagrams, L2TP relies on IP Security (IPSec) for encryption services. The combination of L2TP and IPSec is known as L2TP/IPSec. To establish a VPN connection, both L2TP and IPSec must be supported by both the VPN client and the VPN server. Because L2TP is an industry standard, it is supported on a wider variety of non- Microsoft operating systems than PPTP. In fact, you should always choose L2TP over PPTP when designing a VPN solution for heterogeneous client operating systems.

For many years, one of PPTP’s advantages over L2TP/IPSec was that PPTP could work through a NAT server. L2TP/IPSec used the source and destination IP addresses for authentication and embedded this information inside the encrypted portion of the packet. Therefore, NAT servers were incapable of changing the source and destination IP addresses. NAT Traversal (NAT-T), a new capability of L2TP/IPSec, enables you to use L2TP to connect to an L2TP server when the client is located behind a NAT server. However, the client, the server, and the NAT server must all support NAT-T.

See Also 

For more information on IPSec and NAT-T, refer to Chapters 8 and 9.

Encapsulation for L2TP/IPSec packets consists of two layers: L2TP encapsulation and IPSec encapsulation. L2TP wraps an L2TP header and a User Datagram Protocol (UDP) header around a PPP frame containing the tunneled data, which is similar to the way PPTP performs tunneling. The resulting L2TP message is then wrapped with an IPSec Encapsulating Security Payload (ESP) header and trailer, an IPSec Authentication trailer that provides message integrity and authentication, and a final IP header, as illustrated in Figure 12.2. IPSec encrypts the message by using Data Encryption Standard (DES) or Triple DES (3DES) by using encryption keys generated from IPSec’s Internet Key Exchange (IKE) negotiation process.

Figure 12.2: L2TP-tunneled data packet structure

Like most IPSec connections, L2TP/IPSec is generally used with public key certificates. Unless you are using a preshared key for authentication (which should be used only for testing purposes), you must configure public key certificates on both the VPN server and the client. Additionally, both the client and the server must trust the root CA that issued the other’s certificate.

Client support for L2TP is built in to the Windows Server 2003, Windows XP, and Windows 2000 remote access client, and VPN server support for L2TP is built in to Windows 2000 and Windows Server 2003. However, L2TP is not supported out-of-the-box on versions of Windows released prior to Windows 2000. To use computers running Windows 98, Windows ME, or Windows NT Workstation 4.0 as L2TP clients, you must install the Microsoft L2TP/IPSec VPN client, which is available at http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp.

Before you can install the Microsoft L2TP/IPSec VPN client on computers running Windows 95 or Windows 98, you must have Microsoft Internet Explorer 5.01 or later installed, in addition to the Dial-Up Networking version 1.4 upgrade. You can download the Dial-Up Networking upgrade from http://support.microsoft.com/?kbid=285189.

Exam Tip 

How do you choose between PPTP and L2TP on the exam? Pick PPTP unless something in the question requires L2TP, such as a reference to UNIX, Linux, or another non- Microsoft operating system.

Authentication Methods

Because dial-up, PPTP, and L2TP all use PPP for authentication, they all support the same authentication methods. There are several authentication methods available. Some you will already be familiar with because they are the same methods used for wireless networks or IPSec. Others are used primarily for authenticating remote access users.

When choosing a remote access authentication method, you must first choose between authenticating users against a Remote Authentication Dial-In User Service (RADIUS) server or authenticating them against the local user database or Active Directory domain. If you choose to authenticate users against a RADIUS server, you will have configuration options similar to those used when configuring a RADIUS server to authenticate wireless users. Specifically, you must specify the IP addresses and port numbers of one or more RADIUS servers.

See Also 

For information about hardening Internet Authentication Service (IAS) servers, refer to Chapter 4. For information about using RADIUS servers for authentication, refer to Chapter 10.

Regardless of whether you choose Windows or RADIUS as the authentication provider, you can choose from several authentication methods: EAP, MS-CHAP v2, MS-CHAP v1, Challenge Handshake Authentication Protocol (CHAP), Shiva Password Authentication Protocol (SPAP), Password Authentication Protocol (PAP), preshared key, and unauthenticated access. You should choose the most secure authentication method that all remote access clients support. All Windows operating systems can be updated to support every standard authentication method except for EAP. Only Windows Server 2003, Windows XP, and Windows 2000 support EAP. Non-Windows operating systems might have different restrictions.

Exam Tip 

Expect to see more than one exam question for which you need to know the features and limitations of various authentication protocols. At a minimum, you should be able to answer the following:

• Which protocol is required for smart cards?

• Which protocol is required for public key certificates?

• What are the special configuration requirements for CHAP?

• When is MS-CHAP v2 the best choice of authentication methods?

• What is the difference between authentication encryption and data encryption, and which protocols support each?

• Which protocols support mutual authentication?

Table 12.1 shows the supported client operating systems and key features of the various authentication methods.

Table 12.1: Authentication Methods Supported by Versions of Windows

	EAP	MS-CHAP v2	MS-CHAP v1	CHAP	SPAP	PAP	Pre- shared key
Supported by Windows Server 2003, Windows XP, and Windows 2000 clients			ü	ü	ü	ü	ü
Supported on updated versions of Windows prior to Windows 2000		ü[1]	ü	ü	ü	ü	ü
Supported by default on a computer running Windows Server 2003 and Routing And Remote Access	ü	ü	ü
Provides authentication encryption	ü	ü	ü	ü	ü		ü
Provides data encryption	ü	ü					ü
Provides mutual authentication	ü	ü					ü
Allows changing of passwords during authentication process		ü	ü
Requires passwords to be stored with reversible encryption			ü	ü
Vulnerable to Replay attacks					ü	ü
[1]Windows 95 does not support MS-CHAP v2 over dial-up connections.

As when controlling wireless access, you can use a RADIUS server to authenticate dial-up and VPN users. Any standard RADIUS server will work, including Internet Authentication Service (IAS). If you do choose to use IAS, you can use IAS to further restrict authentication, encryption, group access, and other aspects of a remote access policy (RAP).

See Also 

For information on hardening an IAS server, refer to Chapter 4. For information on configuring an IAS server to authenticate users, refer to Chapter 10.

As shown in Figure 12.3, configuring Routing And Remote Access to connect to a RADIUS server involves the same information used to configure wireless users to authenticate to a RADIUS server: the primary RADIUS server’s IP address, optionally an IP address for a secondary RADIUS server, and a shared secret. After completing the initial configuration, you can use the Routing And Remote Access console to add additional RADIUS servers if necessary. Additionally, you must configure the RADIUS servers to accept the Routing And Remote Access server as a client and to use the same shared secret.

Figure 12.3: Configuring Routing And Remote Access to authenticate to a RADIUS server

You can use the same authentication methods whether you choose RADIUS or Windows authentication, as described in the following sections.

EAP

EAP, the protocol itself, enables an arbitrary authentication mechanism to authenticate a remote access connection. Routing And Remote Access includes support for Protected EAP (PEAP), Message Digest 5 Challenge (MD5-Challenge), and Smart Card Or Other Certificate by default, though other authentication methods could be added to EAP by non-Microsoft applications.

See Also 

For more information on EAP, refer to Chapter 10.

MD5-Challenge MD5-Challenge is a supported EAP type that uses the same challenge handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for MD5-Challenge is to authenticate non-Microsoft remote access clients, such as those running Mac OSX. You can also use MD5- Challenge to test EAP interoperability. EAP with MD5-Challenge does not support encryption of connection data.

PEAP PEAP is primarily used to authenticate wireless users with a user name and password. MS-CHAP v2 is the preferred method for authenticating dial-up or VPN users with user name and password credentials; therefore, you should never configure PEAP for use with a VPN.

Smart Card Or Other Certificate This authentication method, also known as EAP- Transport Layer Security (EAP-TLS), is used to enable remote access authentication with a smart card or a public key certificate. Only Windows Server 2003, Windows XP, and Windows 2000 remote access clients support this authentication method. The computer certificate that you assign to the L2TP/IPSec client must contain either the Client Authentication purpose or the IPSec purpose in the certificate extensions. The VPN server certificate must contain the Server Authentication purpose if it is deployed as a remote access server, or it must contain both the Server Authentication purpose and the Client Authentication purpose if it is deployed in a router-to-router VPN.

See Also 

For more information about public key certificates, refer to Chapter 7.

You must install a user certificate on all VPN clients, and if the authenticating server is a RADIUS server, you must also install a Server Authentication computer certificate on the RADIUS server. When two or more purposes are required, they must be included in the extensions of the same certificate.

Exam Tip 

Remember that only Windows 2000, Windows XP, and Windows Server 2003 support EAP. Windows NT version 4.0, Windows 98, and Windows 95 do not support EAP. Also remember that you will always use EAP if smart cards or public key certificates are used for authentication.

MS-CHAP v1

The Windows Server 2003 family includes support for MS-CHAP v1. MS-CHAP v1 is a one-way authentication method offering both authentication encryption and data encryption. However, this encryption is relatively weak because MS-CHAP v1 bases the cryptographic key on the user’s password and will use the same cryptographic key as long as the user has the same password. This gives an attacker more data with which to crack the encryption, making the cryptography weak.

MS-CHAP v1’s sole advantage is that it is supported by earlier Windows clients, such as Windows 95 and Windows 98, without additional software upgrades. By default, Windows Server 2003 Routing And Remote Access will accept MS-CHAP v1 authentication if the client requests it, enabling clients that haven’t been upgraded to connect successfully. You can choose to disable this authentication method if all clients can use MS-CHAP v2.

MS-CHAP v2

The Windows Server 2003 family includes support for MS-CHAP v2, the preferred method for authenticating remote access connections that do not use smart cards or public key certificates. Unlike MS-CHAP v1, MS-CHAP v2 authenticates both the client and the server. Additionally, MS-CHAP v2 uses much stronger cryptography than MS- CHAP v1, including the use of a new cryptographic key for each connection and each direction of transmission.

If you do not change any of the default settings, Windows VPN remote access clients will use MS-CHAP v2 to authenticate. Windows 95 with the Windows Dial-Up Networking Performance & Security Upgrade supports MS-CHAP v2, but only for VPN connections, not for dial-up connections. MS-CHAP (version 1 and version 2) is the only authentication protocol provided with the Windows Server 2003 family that supports password change during the authentication process. If you use a different authentication method, the user will have to connect to a domain controller through a mechanism other than a VPN to change the password.

Tip 

If you have users who always work remotely, not being able to change a password during authentication can be a real problem because they cannot simply change the password the next time they are in the office. One way to allow remote users to change their passwords is to set up a computer with Terminal Services. Have the users connect to the Terminal Services server when a password change is required. When they log in, they will be prompted to change their passwords.

CHAP

CHAP is a challenge-response authentication protocol that uses the industry-standard MD5 hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A computer running Windows Server 2003 and Routing And Remote Access does not allow CHAP authentication by default. However, you can enable CHAP authentication so that remote access clients that support CHAP but do not support MS-CHAP can be authenticated.

CHAP does not support encryption of connection data. Because CHAP requires the use of reversibly encrypted passwords, you should avoid using it whenever possible. Enabling reversibly encrypted passwords makes it easier for an attacker to identify users’ passwords if the attacker gains access to your user database. If a remote access user uses CHAP for authentication and his or her password expires, the user cannot change the password during the remote access authentication process. The user will need to authenticate by using MS-CHAP or connect to your internal network directly.

SPAP

The Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employed by Shiva. A computer running Windows XP Professional, when connecting to a Shiva LAN Rover, uses SPAP, as does a Shiva client that connects to a server running Routing And Remote Access. This form of authentication is more secure than plaintext but less secure than CHAP or MS-CHAP. SPAP is not enabled by default on computers running Windows Server 2003 and Routing And Remote Access, and it should not be enabled unless specifically required.

Security Alert 

When you enable SPAP as an authentication protocol, any particular user password is always sent in the same reversibly-encrypted form. This makes SPAP authentication susceptible to replay attacks, in which an attacker captures the packets of the authentication process and replays the responses to gain authenticated access to your intranet. Don’t use SPAP unless absolutely necessary.

PAP

Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. Anyone capturing the packets of the authentication process can easily read the password and use it to gain unauthorized access to your intranet. The use of PAP is highly discouraged, especially for VPN connections. It is disabled by default, and it should only be used if the remote access client and the remote access server cannot negotiate a more secure form of validation.

Unauthenticated access

The Windows Server 2003 family supports unauthenticated access, which means that user credentials (a user name and password) are not required. There are some situations in which unauthenticated access is useful. Specifically, if you are using a RAP to control access by another means, such as callback or caller ID, you might decide that additional authentication is not required. Alternatively, you might encounter a scenario in which you want to allow guests to connect to a remote access server without requiring any form of authentication.

Preshared keys

Preshared key authentication is the only way to use L2TP/IPSec without installing a computer certificate on the remote access server. Preshared keys are never the preferred authentication method for enterprises because managing preshared keys on large numbers of computers is time consuming. If the preshared key on a remote access server is changed, a client with a manually configured preshared key will be unable to connect to that server until the preshared key on the client is changed. If the preshared key was distributed to the client within a Connection Manager profile, that profile must be reissued with the new preshared key and reinstalled on the client computer.

Additionally, because the same preshared key must be distributed to all clients, the likelihood of the preshared key being discovered by an attacker is very high. Unless you distribute the preshared key within a Connection Manager profile, each user must manually type the preshared key. This limitation further reduces security and increases the probability of error. Preshared keys are unlike certificates in that the origin and history of a preshared key cannot be determined. For these reasons, the use of preshared keys to authenticate L2TP/IPSec connections is considered a relatively weak authentication method.

Finally, the use of preshared keys is supported with only Windows Server 2003 and Windows XP clients. While preshared key authentication is useful for testing purposes, if you want a long-term, strong authentication method for L2TP/IPSec, you should use public key certificates.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

1. Which of the following authentication protocols can be used by fully updated Windows 98 VPN clients? (Choose all that apply.)

   1. EAP

   2. MS-CHAP v2

   3. MS-CHAP v1

   4. CHAP

   5. SPAP

   6. PAP

2. Your organization’s security policy has a requirement that passwords not be stored with reversible encryption. Which of the following authentication protocols can you use? (Choose all that apply.)

   1. EAP

   2. MS-CHAP v2

   3. MS-CHAP v1

   4. CHAP

   5. SPAP

   6. PAP

3. Your organization still has clients running Windows 95. Which of the following protocols can you use to authenticate dial-up clients? (Choose all that apply.)

   1. EAP

   2. MS-CHAP v2

   3. MS-CHAP v1

   4. CHAP

   5. SPAP

   6. PAP

Lesson Summary

• Windows Server 2003 supports two VPN protocols: PPTP and L2TP/IPSec. PPTP was developed by Microsoft and is the default protocol. L2TP/IPSec is an Internet standard that provides interoperability with a greater number of clients.

• Windows Server 2003 supports eight methods for authenticating users: EAP, MS-CHAP v2, MS-CHAP v1, CHAP, SPAP, PAP, preshared keys, and unauthenticated access.

• Use EAP to authenticate users with a public key certificate or a smart card. Only Windows Server 2003, Windows XP, and Windows 2000 clients support EAP.

---