How do we authenticate when we login to another device or an application? It’s much more than just entering a username and password, right? Well, there are actually many ways to authenticate! I’ll discuss some of the main ones we use and what goes on behind the scenes.

Point-to-Point Protocols (PPP)

If you’re familiar with networking topics, networks today are utilizing TCP/IP, which is great, but it wasn’t designed with security in mind. Back in the early days of the Internet, way before fiber-optics, cable modems, and DSL connections, we were using dial-up connections. One way to prevent unauthorized people from “dialing” into our computers was Point-to-Point Protocol (PPP). PPP is a layer 2 communications protocol used to connect two endpoints and authenticate using a username and password. PPP works pretty much anywhere. For example, you can link dial-up connections, serial links, mobile phones, fiber optic links, and DSL. PPP offers authentication, compression, error detection, and Multi-link PPP (MPPP). MPPP allows us to use multiple links, instead of just one. As a result, we get a boost in bandwidth.

The magic of PPP is described in RFC 1661. PPP uses a “Link Control Protocol (LCP)” to establishes and configures a link between two endpoints and another protocol, called “Network Control Protocol (NCP),” for configuring the chosen network protocol to be used during the connection.

PPP and dial-up are not Ethernet, but PPP has been around for a long time, thus providing us with plenty of opportunities to combine it with Ethernet. This gives us an additional way to get a DSL connection from our ISP. We PPP with Ethernet “Point-to-Point over Ethernet (PPoE).”

Then, there’s also “Point-to-Point Tunneling Protocol (PPTP),” which manages and configures the tunnel between two locations. It uses “Generic Routing Encapsulation (GRE)” to do the actual tunneling. It uses TCP Port 1723. After that, PPP is then used to send the multi-protocol traffic through the GRE tunnel. So, in other words, PPTP creates the tunnel, and then PPP sends the traffic over that tunnel. Unlike PPP though, PPTP has the ability to authenticate AND encrypt the information going across the tunnel.

Password Authentication Protocol (PAP)

PPP provided two ways to authenticate; the first one is called PAP. This was one of the first types of authentication methods that used PPP. It was a basic and extremely simple protocol. If you recall from my discussion of Kerberos, there was a lot of encryption, communication to domain controllers, communication with resource servers, and it was a three-headed process that was complex to understand at times. PAP is nothing like that. It’s so simple. In fact, everything communicated with PAP is in plaintext, including usernames and passwords used to authenticate. Obviously, on modern networks, PAP is a painfully insecure way of authenticating. It is highly vulnerable to man-in-the-middle attacks, which is why it has been depracated. For security reasons, it’s best to use PAP only as a last resort.

Challenge-Handshake Authentication Protocol (CHAP)

CHAP is the second way used to authenticate via PPP, but it’s a more secure authentication protocol than PAP.  In CHAP, if a client wishes to authenticate with a server, the server provides the client with a “challenge.” For example, “If you want access, you’re going to have to prove you are who you say you are. So, give me your password.” The application using CHAP will hash the client’s password and send the hash over the network. The server has the stored hash in its database, and therefore,  compares the client’s stored hash to the received hash. If the hashes match, the client is granted access. CHAP is vulnerable to man-in-the-middle attacks and offline password attacks, so it’s also not very safe to use anymore.

MS-CHAPv1 and MS-CHAPv2

Microsoft has its own version of CHAP called “Microsoft-CHAP (MS-CHAP).” MS-CHAP uses PPTP and PPP.  It works similarly to CHAP, but it’s more robust and secure. However, since its creation, Microsoft has updated MS-CHAP to MS-CHAP version 2. “MS-CHAPv2” is more secure than MS-CHAP because it provides mutual authentication between the client and server. Therefore, when you communicate with a server, you can be assured you are communicating with the server and not a rogue server impersonating the real one.  Unfortunately, some vulnerabilities have been discovered in both MS-CHAP and MS-CHAPv2. Nevertheless, MS-CHAPv2 is still the most common authentication method for the few people left still using dial-up connections.

PPP and Authentication, Authorization, and Accounting (AAA) Protocols

PPP has some limitations that aren’t quite suited for modern day networks, and because of these limitations, AAA was developed. An authentication protocol that provides authentication, authorization, and accounting (logging) earns the title of an AAA protocol. AAA protocols are heavily relied on in IEEE 802.1x, or Port-based Network Access Control (PNAC). We use 802.1x to not only centralize authentication, but to also authenticate remote clients. Authenticating remote clients is the process of Remote Access Service (RAS); therefore, we call remote clients “RAS clients.”

The main AAA protocols and standards used today are:

• Remote Access Dial-In User Service (RADIUS)
• Diameter
• Terminal Access Controller Access Control System Plus (TACACS+)
• Extensible Authentication Protocol (EAP)
• 802.1X Port-based Network Access Control (PNAC)

Let’s discuss each one and see how they compare.

Remote Access Dial-In User Service (RADIUS)

RADIUS can be used for for centralizing authentication and authenticating “Remote Access Service (RAS)” clients. RAS is the service used to allow dial-up connections from remote clients, as well as DSL and fiber-optics. Imagine you are logging into Google, Facebook, or Yahoo (keep in mind you can do this from anywhere in the world). Do you really think that these organizations are taking your username and password and copying it to ALL of their servers? No, that would be an administrative nightmare!

When you access one of their servers for the region in which you reside, their server is communicating with an authentication server. That authentication server is what is granting you access and rights to those resources.

What’s specifically happening is you are contacting one of the “Network Access Servers (NASs),” which in turn connects to a RADIUS server that has centralized access to a database of usernames and passwords. This can be used on your desktop for a VPN to connect to your internal network, or maybe you are an administrator who needs access to a router, switch, or firewall. Your password and username are the same for every device. This is the definition of centralized management. This is an important concept of “AAA,” which, again, is Authentication, Authorization, and Accounting. The RADIUS server checks the credentials you are using with your username and password, provides the proper access to the network based on who you might be, and tracks when you logged in/off. Check out the diagram below.

As you see from this diagram, we have RAS clients in our environment (like Dan) logging in remotely from the Internet using the Network Access Server (NAS) and we have wireless clients needing to authenticate to the Wireless Access Point (WAP) at the bottom. A WAP is also considered a NAS in RADIUS environments. So, when a RAS client needs to authenticate to our network, the NAS or WAP will communicate with the centralized RADIUS server to authenticate these RAS clients. In this example, Dan provides a username and password, and perhaps an additional authentication factor to the NAS. The NAS passes this on to the RADIUS server.  RADIUS typically uses UDP port 1812 (and sometimes UDP ports 1645 and 1646) to provide that access. The AAA server checks the Dan’s credentials, and if everything is legitimate, it tells the NAS to allow the Dan access and makes a note of when the he logged on and when he logs off. This last part is the accounting aspect of the AAA protocol.

How is this all centralized? Because it doesn’t matter whether you are a RAS client, a wireless client, or a client on the internal network. At the end of the day, clients are always providing the SAME username and password that is stored in the AAA server.

Some cybersecurity professionals don’t like RADIUS because it only encrypts the password, but not the entire authentication process. They also have issues with the fact that RADIUS uses UDP instead of TCP. TCP is a more reliable form of transport than UDP.

Diameter

Diameter is more complex than RADIUS. Diameter addresses some of the flaws of RADIUS, for instance, Diameter uses TCP (port 3868) or SCTP for message exchange, instead of UDP. UDP does not use implicit hand-shaking mechanism for providing reliability, ordering, or data integrity. This unreliability was the major flaw in RADIUS.

Diameter got its name because its creator believed it would be twice as better than RADIUS. If you remember from math class, the diameter equals 2x the radius.

Terminal Access Controller Access Control System Plus (TACACS+)

This the latest Cisco proprietary version of TACACS. The original standard of TACACS was created in RFC 1492. It was originally created to control access to the dial-up lines to ARPANET. So, TACACS is a very old authentication protocol. It was updated to Extended TACACS (XTACACS), but was deprecated years ago.

Today, we have TACACS+, a protocol primary used to administer networks containing many routers and switches. Logging into each switch and router individually really becomes a pain without a centralized approach. Luckily, TACACS+ supports networks with a lot of network infrastructure. It provides additional authentication requests and response codes. TACACS+ works very similarly to RADIUS, so I won’t go into details of how it works.

Administrators like TACACS+ because it uses TCP port 49 to communicate, which is a more reliable form of connection. Unlike RADIUS, it also encrypts the entire authentication process. We see a pattern emerging here. Many administrators feel that that TCP connection-oriented is better than the connectionless UDP. But, that’s not all that’s great about TACACS+. In addition, TACACS+ uses multiple challenges and responses between client and server. Despite all of this; however, RADIUS, Diameter, and TACACS+ all perform the same functions.

Extensible Authentication Protocol (EAP)

I consider EAP to be a part of AAA and PPP. EAP was developed to become a revolutionary standard in the way two devices authenticate.

The EAP protocol is a series of method interfaces that make up the framework known as EAP. EAP provides many options for authentication and is predominantly used on wireless networks. EAP also provides user authentication against a directory service, which allows administrators to track employee behavior or what they do with wireless access. There are currently many, many different implementations of the EAP framework, but we only use a few of them. The following are the most common EAP/EAPoL enterprise 802.1x implementations ranked by the level of afforded security.

Extensible Authentication Protocol – Pre Shared Key (EAP-PSK)

EAP-PSK uses a pre-shared key, or code, that’s stored on both the wireless client and the Wireless Access Point (WAP). This code is encrypted using AES and CCMP. As you probably use on your wireless home network, you have a shared passphrase to connect to your home Wi-Fi.

Extensible Authentication Protocol – Transport Layer Security (EAP-TLS)

This EAP implementation only allows mutual certificated-based authentication through Transport Layer Security (TLS) and digital certificates. TLS is the encryption we use in https, so it’s very good encryption. Authentication of both the authentication server and the supplicant (the wireless client) provides a strong layer of wireless security, but requires a full enterprise Public Key Infrastructure (PKI) implementation. This means that EAP-TLS requires certificates on both the server AND the clients! Thus, a common issue with EAP-TLS is that most organizations don’t have the necessary PKI to issue the supplicant client certificates. However, due to its mutual authentication, EAP TLS is great for preventing MitM attacks and rogue/impersonation attacks…but it’s expensive to implement a full PKI.

Extensible Authentication Protocol – Tunneled Transport Layer Security (EAP-TTLS)

This is EAP over Tunneled Transport Layer Security (TTLS). It is similar to EAP-TLS and also supports mutual certificate authentication, but this time, it doesn’t require client-side certificates. Only the servers get a certificate. Therefore, a full PKI is not required, so this could be an alternative option for organizations that cannot afford a full PKI infrastructure like EAP-TLS. EAP-TTLS works by creating a TLS tunnel prior to starting any network authentication process and can therefore tunnel any password authentication mechanism, even insecure legacy mechanisms, such as Password Authentication Protocol (PAP), which is notoriously known for being insecure since it transmits passwords in plaintext over the network. It can also use CHAP, MS-CHAP, and EAP-MD5.

Thus, the great thing about EAP-TTLS is that we can reserve it for our legacy equipment that are compatible with the older PPPs, like PAP and CHAP. So, it’s likely to see EAP-TTLS being used in legacy environments.

Active Directory

Active Directory (AD) gives a very high level of security because its wireless authentication for EAP is certificate-based. Active Directory is a great authentication method to use if you know that your company is an all-Microsoft shop. As I’ll most likely cover in a later post, AD is used on Microsoft networks.

Protected Extensible Authentication Protocol (PEAP)

PEAP is “Protected EAP.” In its native form, PEAP does not support any mutual certificate-based authentication, which isn’t the best option from a security perspective. Native PEAP uses TLS to authenticate the authentication server only and leverages a password-based challenge response process using MS-CHAP to authenticate the client. Later PEAP versions help to mitigate this weakness (discussed below). PEAP can be a less expensive alternative to EAP-TLS since it does not require a sophisticated PKI; however, this comes at a cost. This does not prevent Rogue AP or server attacks. For example, if an attacker sets up a rogue AP and is connected to it, a client victim who attempts to authenticate to this AP will have the challenge-response hashes captured. The attacker can then perform an offline dictionary attack of the password hash. PEAP might be okay to use so long as administrators are monitoring their network for Rogue APs. There are currently 3 primary types of PEAP, which provide varying levels of protection:

1. PEAP-TLS: this is a PEAP inner protocol defined by Microsoft. PEAP-TLS tunnels the EAP-TLS protocol within PEAP to provide mutual, X509 certificate-based authentication. In other words, authentication is done using certificates and the authentication traffic is encrypted using TLS. Due to its mutual authentication, PEAP-TLS prevents MitM and rogue/impersonation attacks. This does require a full PKI though, which is more expensive.
2. PEAP-MS-CHAP-v2: The most common PEAP authentication method uses MS-CHAPv2 protocol to provide user-identification (username) and password challenge-response-based authentication. As I stated earlier, MS-CHAP has been replaced by MS-CHAPv2, so it makes sense to update to the better version. The MS-CHAP authentication process has historically allowed an attacker with physical access to the authenticator (e.g., an Access Point), to capture the provided challenge and challenge-response hash in plaintext. Due to recent cracking advancements, the time to crack an MS-CHAPv2 challenge-response hash has been reduced to days or less and should be avoided at all costs unless proper client supplicant configurations can be established.
3. PEAPv1 (EAP-GTC): The third implementation is defined by Cisco, which allows authentication using Generic Token Cards (GTCs), such as an RSA SecurID token as well as User ID and password. Therefore, it provides two-factor authentication (password and GTCs). PEAP encapsulates EAP-GTC method in an authenticated and encrypted TLS tunnel using only a server-side certificate.

Lightweight Extensible Authentication Protocol (LEAP)

LEAP is a proprietary protocol developed by Cisco, which performed challenge-response MS-CHAP, based username/password authentication in cleartext. It was “lightweight” because it only handled passwords; no PKI or certificates were involved. An attacker targeting a network employing LEAP only needs to monitor traffic to capture challenge-response hashes for offline dictionary attacks. This is in contrast to PEAP-MS-CHAP-v2, which requires a rogue masquerading AP for an attacker to intercept MS-CHAP-v2 challenge-response hashes.

LEAP should never be used. Attackers only need Wireshark to capture challenge-response hashes from MS-CHAPv2. In LEAP, much of the network traffic is not encrypted. On wireless networks, it’s painfully easy to capture packets.

Extensible Authentication Protocol – Flexible Authentication via Secure Tunneling (EAP-FAST)

EAP-FAST was developed by Cisco as a replacement for the vulnerable LEAP protocol. EAP-FAST introduced secure pre-authentication tunnels without using certificates. EAP-FAST has secure mutual authentication capabilities, but also has an automatic PAC provisioning option, which is vulnerable to MitM attacks.

Extensible Authentication Protocol – Message Digest 5 (EAP-MD5)

Do not worry about this one. EAP-MD5 is a simple version of EAP that hashes authentication credentials using the MD5 hash function. Just know that you should never use it as it is now insecure. MD5 is not secure anymore due to it’s collision attack vulnerabilities. MD5 can be used for file integrity checking though.

802.1x Port-based Network Access Control (PNAC)

EAP became very popular shortly after its implementation and there quickly became a growing demand for EAP over wired Ethernet networks. The answer was IEEE standard 802.1x. This standard does without PPP, and instead, puts the EAP information inside an Ethernet frame. Now, unauthorized users can’t connect to an Ethernet port or a port on a switch without first authenticating to the network. The cool thing about 802.1x is that, just like TACACS+,  it works just like RADIUS too! The only difference is the terminology. Compare the diagram below with the earlier RADIUS diagram above.

In the 802.1x scenario, RAS clients are called “Supplicants.” Our devices contain some type of 802.1x-compliant supplicant software that allows it to connect to a “Authenticator,” such as a NAS or WAP.  The Authenticator then passes the credentials to an “Authentication Server.”

Here’s a little more confusion about 802.1x. 802.1x uses EAP, and if you’re using it on a wired network, it specifically uses EAP over LAN (EAPoL) as the communication between the Supplicant and the Authenticator. However, if you are using 802.1x over a wireless network, the EAP communication between the Authenticator and the Authentication Server is usually tunneled over RADIUS, but there is no RADIUS between the Supplicant and the Authenticator.

If I could simplify this as best I can, I would say that RADIUS is just a simple way to authenticate, authorize, and account dial-in users. Therefore, it’s a simple way to authenticate someone to a device or through a VPN. 802.1x, on the other hand, is a complex standard or framework for authentication that can use both RADIUS and EAP as a method for authentication. It is primarily used to control access to switch ports and Wi-Fi.

 

 

References

Gibson, D. (2017). CompTIA SECURITY+ Get Certified Get Ahead SY0401 Study Guide.   Virginia Beach, VA: YCDA, LLC

Meyers, M. (2015). All in One CompTIA Network+ Certification Exam N10-006. McGraw-Hill Education: New York, NY.