Devs might give sales folks a hard time about TLAs (three-letter acronyms), but our authentication protocols do not give us solid ground to stand on. PPP, PAP, EAP, CHAP, AAA, TLS . . . are you lost yet? It’s okay; you’re not alone. Authentication protocols are densely packed with confusing technical jargon—enough to make your head spin.
In this article, we’ll cover a baseline of authentication protocols: PAP, CHAP, and EAP. Each of these protocols is commonly used by Point-to-Point Protocol (PPP) servers, two machines that are directly linked communicating over the data link layer. We’ll save more complex Authentication, Authorization, and Accounting (AAA) protocols for another time.
For each authentication protocol, we’ll cover what the protocol is, give a detailed example, and talk through some of the weaknesses. Remember: these protocols are a baseline, so many act as jumping-off points for more advanced protocols later on. We’ll wrap up with an explanation of why the differences between the protocols matter.
PAP was one of the first authentication protocols created. It’s simple and takes relatively little computational power, but it’s also much more vulnerable than other protocols for authentication.
Here’s how it works:
The client initiates authentication by sending a packet with their credentials (username and password).
The client continually sends authentication requests to the server until the server responds.
The server checks the credentials and responds with authentication success or authentication failure.
This protocol is simple and easy to understand, but carries two big problems:
PAP is vulnerable to a number of attacks, including some that are fairly easy to avoid:
Despite these many shortcomings, PAP is still widely supported, though usually as just a last-resort authentication protocol. If any other protocol (and we mean any) is available, that is the preferred choice due to the security concerns. Still, it’s good to cover foundational protocols, like PAP, to get a thorough understanding before moving on to the more advanced ones.
CHAP still uses a username and password combination, but it requires both the server and the client to run the password through a hash function along with a one-time password (OTP) sent from the server.
Here’s how it works:
At any time during a session, the server initiates authentication by sending an OTP (usually in the form of a 128-bit string). Often, this happens multiple times during a session, with the server re-authenticating the client for additional security.
The client takes the OTP and runs it, plus their password, through an MD5 hash function.
Next, the client sends the resulting hash string and their username (in plaintext) back to the server.
Finally, the server uses the username to look up the stored password in their database and computes the same MD5 hash function with that server and the OTP they initially sent. If the MD5 hash codes match, the client is authenticated. The server responds with authentication success or authentication failure.
CHAP is more secure than PAP because it does not send any credentials (other than the username) in plaintext. Plus, it is safe against replay attacks because of the OTP changing periodically.
Still, there are some vulnerabilities because the payload is sent in cleartext. Hackers could eavesdrop on the packets, take the MD5 hash, and then brute-force the combinations to determine the password. That’s one of the reasons people turn to Extensible Authentication Protocol, or EAP.
PAP and CHAP are simple when compared with EAP, which is really more of an authentication framework than a security protocol. Within the framework, there are 40 different authentication methods that can be used. In each request or response between the server and the client, a “type” for authentication is specified. Some of the types include EAP-MD-5, EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-Fast.
Here’s how it works:
The server sends an authentication request to the client, including which of the 40 authentication methods it should use.
The client then computes whatever it needs to, depending on the specified “type.”
Next, the client sends the results back to the server, along with the type, so that the server knows what method it should use to check the output.
If the server needs anything else, it will send another request—along with the type—back to the client until authentication is deemed a success or failure. Once the server determines the outcome, it sends an authentication success or an authentication failure back to the client.
Like CHAP, EAP can be repeated as many times as necessary during a session. EAP is a lockstep protocol, which means that other than the initial request from the server to authenticate, new requests will not be sent again until the server sends a valid response.
EAP is not without its own troubles, but they're pretty specific to which method type you're using Below are three of the most commonly used ones: