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.

Password Authentication Protocol (PAP): One of the oldest authentication protocols

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:

1. Sending sensitive credentials repeatedly could overload the server. And doing so right off the bat is a good way to get them stolen. You always want to know exactly who you are sending sensitive info to.
2. All the information is sent in plaintext. Sending sensitive info like a password without encryption is a no-no.

PAP is vulnerable to a number of attacks, including some that are fairly easy to avoid:

• Eavesdropping: A hacker listens in on transported packets, captures them, and reads their data. If a payload is unencrypted, like in PAP, the hacker will automatically have your username and password without having to do extra decoding work.
• Man-in-the-middle (MITM): A hacker steps in the middle of the communication between the client and the server and can then listen to or even alter the messages.

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.

Challenge Handshake Authentication Protocol (CHAP): A step up in protocol security

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.

Extensible Authentication Protocol (EAP): 40 methods of authentication

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:

1. EAP-MD5: You might be able to guess it from the name, but EAP-MD5 is almost exactly the same as CHAP. An MD5 hash algorithm is used with an OTP to hide the password during communication. Since this is almost the same as CHAP, the downsides of this method are the same as the issues for CHAP.
2. EAP-TLS: This authentication method is certificate-based, which means that both the client and the server need to have a certificate. The downside of this method is that certificate deployment can be difficult to manage, particularly in large-scale environments. The biggest upside is that EAP-TLS is one of the most secure authentication methods.
3. EAP-FAST: FAST, in this case, stands for Flexible Authentication via Secure Tunneling. It’s certificate-free, which may be an upside for whoever is deploying the system. EAP-FAST authenticates with a Protected Access Credential (PAC) managed by a separate authentication server. The biggest downside of EAP-FAST is setting up PAC distribution, because it can be rather complicated. After that, though, EAP-FAST is . . . fast.

‍

‍