Windows 2000 Authentication Protocols

A Windows 2000 (Win2K) server decides whether to let a Win2K remote access client connect after evaluating the client’s credentials, accepting a connection only after authenticating and authorizing the client attempt. Authentication is the process of verifying client’s credentials. A client uses an authentication protocol to send either encrypted or unencrypted credentials to the server, depending on the protocol.

Authorization, the process of verifying that the connection attempt is permissible, takes place after authentication. Authentication alone doesn’t guarantee a successful connection. Win2K might authenticate a client but refuse the connection if the OS can’t authorize the client. For example, when a client dials in to a Win2K RAS server, the server’s security subsystem verifies the client’s credentials for authentication. Win2K uses the client’s user account properties and remote access policies to authorize the connection. If authentication and authorization succeed, Win2K allows a connection. In this week’s column, I discuss the various authentication protocols that Win2K supports, including:

Password Authentication Protocol
PAP is the least secure authentication protocol because it uses plain-text passwords. Generally, you’ll want to use PAP only when attempting to connect to a non-Windows OS that doesn’t support encrypted passwords (e.g., when dialing in to an ISP that can’t negotiate a higher level of authentication). You can also use PAP to dial in to Serial Line Internet Protocol (SLIP) servers, which don’t support encrypted passwords. Because anyone capturing authentication packets with a protocol analyzer (e.g., Microsoft’s Network Monitor) can easily read the unencrypted passwords, I don’t recommend PAP. Another disadvantage of using PAP is that if your password expires, PAP doesn’t have the ability to change your password during authentication.

Shiva Password Authentication Protocol
SPAP, Shiva’s proprietary version of PAP, offers a bit more security than PAP’s plain-text password with its reversible encryption mechanism. Typically, you’ll use SPAP for connecting a Shiva client to a Windows 2000 Server (Win2K Server) running RAS. You’ll also use SPAP to connect a Windows 2000 Professional (Win2K Pro) client to a Shiva LAN Rover.

Someone capturing authentication packets won’t be able to read the SPAP password, but this authentication protocol is susceptible to playback attacks (i.e., an intruder records the exchange and plays the message back to gain fraudulent access). Playback attacks are possible because SPAP always uses the same reversible encryption method to send the passwords over the wire. Like PAP, SPAP doesn’t have the ability to change your password during the authentication process.

Challenge Handshake Authentication Protocol
CHAP is a widely accepted industry standard that uses an MD5 hashing scheme to encrypt authentication. A hashing scheme scrambles information in such a way that it’s unique and can’t be reversed back to the original format. CHAP doesn’t send the actual password over the wire; instead, it uses a challenge-response mechanism with one-way MD5 hashing.

CHAP uses a three-way handshake to provide encrypted authentication. The authenticator first sends out a challenge string to the client. The client responds with a one-way encrypted value of the challenge string. The authenticator verifies the value and acknowledges the authentication. CHAP then periodically verifies the client's identity. It changes the challenge value every time it sends out a message, which protects against playback attacks.

A Win2K server configured for CHAP can negotiate plaintext authentication with another RAS server or a client that doesn’t support CHAP. However, keep in mind that a client you configure to require encrypted authentication won’t succeed in connecting to a server that accepts only plain-text passwords.

Microsoft Challenge Handshake Authentication Protocol
MS-CHAP is Microsoft’s proprietary version of CHAP. Win2K supports both MS-CHAP version 1 and MS-CHAP version 2, which are both enabled by default. One advantage of using MS-CHAP is that, unlike PAP and SPAP, it lets you encrypt data. You encrypt data you send on Point-to-Point Protocol (PPP) or PPTP connections using Microsoft Point-to-Point Encryption (MPPE).

MS-CHAP 1 supports LAN Manager authentication by default. You can modify the Registry to disable LAN Manager authentication with MS-CHAP 1 for previous OSs such as Windows NT 3.5x or Windows 9x. One drawback of MS-CHAP 1 is that it supports only one-way authentication. A client can't determine the authenticity of a RAS server it connects to. MS-CHAP 2 overcomes this limitation by allowing mutual authentication, wherein the client and the server can identify each other. MS-CHAP 2 also supports stronger encryption and, unlike MS-CHAP 1, no longer supports the weaker LAN Manager authentication for backward compatibility.

The two flavors of MS-CHAP (versions 1 and 2) are the only authentication protocols in Win2K that support password changes during authentication. By the way, you need a special version of MS-CHAP, available from Microsoft, to connect to a Win95 server. Win95 doesn’t support MS-CHAP 2 for dial-up connections—the OS supports only MS-CHAP 2 for VPNs with DUN 1.3 Performance and Security Upgrade.

If you configure your connection to use only MS-CHAP 2 and the server you're dialing in to doesn’t support MS-CHAP 2, the connection will fail. This behavior is different than Windows NT where the RAS servers negotiate a lower-level authentication if possible.

Extensible Authentication Protocol
EAP, an extension to PPP, provides additional authentication methods for RAS users, such as smart cards, Kerberos version 5, and certificates. Similar to MS-CHAP, EAP is a mutual- authentication protocol, wherein the client and the server verify each other’s identity.

EAP opens the door for third-party vendors to develop custom authentication schemes such as retina scans, voice recognition, and finger print identification. The demand for stronger encryption and tighter security continues to push developers to create new authentication mechanisms. The way things are changing, who knows--maybe you'll come to work one day and your boss will tell you that a new company policy requires all employees to use DNA to log on to their systems.