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.
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.
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.
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 EAPTransport 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.
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, Win Challenge to test EAP interoperability. EAP with MD5-Challenge does not support encryption of connection data.
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 MSCHAP v1, including the use of a new cryptographic key for each connection and each direction of transmission.
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.
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.
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.
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 EAPTransport 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.
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, Win Challenge to test EAP interoperability. EAP with MD5-Challenge does not support encryption of connection data.
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 MSCHAP v1, including the use of a new cryptographic key for each connection and each direction of transmission.
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.
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.
