Wi-Fi authentication radius server. 7 Lessons from building our RADIUS server in the Cloud

Wi-Fi authentication radius server

AuthenticateMyWiFi™ is a hosted or Cloud-based service that enables you to use the Enterprise mode of Wi-Fi Protected Access—WPA or WP2—security for your private Wi-Fi network. The service provides you with access to a RADIUS server, which performs the required 802.1X authentication.

Basically, the AuthenticateMyWiFi™ service gives you top-notch Wi-Fi security for your private WLAN, without you having to invest time and money in setting up your own RADIUS server.

The AuthenticateMyWiFi™ service also helps you meet the HIPAA, PCI-DSS, and ISO27000 compliance requirements.

Sign-Up Now

Want to learn more about Wi-Fi? Check out our articles and resources !

• Password-Based Authentication: Users log into the network with the usernames and passwords you create. The service uses the PEAP protocol for the 802.1X authentication.
• Wireless Wired Support: Though designed with enterprise Wi-Fi security in mind, the service also works for wired connections when used with business or enterprise-level switches supporting wired 802.1X authentication.
• Multi-Location Support: Use the Cloud service on routers and APs at multiple locations throughout the World.
• Web-based Control Panel: Easily configure the settings via an online Control Panel anywhere you have Internet access.

AuthenticateMyWiFi™ Advanced Features

• Login Times: Restrict user access during set times or days of the week.
• Expirations: Define a date and time a user account is automatically deactivated.
• Limit Login to Specific APs: Control which routers or access points (APs) users can connect through.
• Limit Login from Certain Devices: Specify the devices (laptop, smartphone, etc) users can connect from.
• VLAN Assignments: If you have business or enterprise-class equipment that supports virtual LANs (VLANs), users can be automatically assigned to the VLAN ID you specify for each individual user.

All Wi-Fi CERTIFIED hardware (wireless routers, access points, wireless adapters, etc) that supports the Enterprise mode of WPA or WP2 security (with the PEAP protocol) should work with the AuthenticateMyWiFi™ service.

Windows, Mac OS X, and Linux are all supported

Apple iPad/iPod Touch/iPhone, Android, and Blackberry devices are all supported

Why We’re Better Than Other RADIUS Servers

You’ll find traditional RADIUS servers that can be used for 802.1X authentication. However, we offer a few things other authentication servers don’t:

• Multi-location support: You can use our service among different locations and offices. Traditional RADIUS servers don’t work well over the Internet. If you want to use a traditional server to authenticate users at multiple locations, each office would need to be connected via VPN links or have static Internet IP addresses.
• Saves you money: Our service starts at 14/month or 140/year. Traditional RADIUS servers cost several hundred to a few thousand dollars, not including cost of time in having IT staff install, configure, and maintain it.
• Saves you time and energy: You’ll be connecting to your enterprise-encrypted network in 15 minutes or less with our service. We even offer a user guide to help you configure your computers with the 802.1X settings. Understanding how RADIUS works and figuring out how to install and configure a server can take a long time.
• Web-based control panel: You’ll receive access to an online Control Panel where you can enter your wireless router or AP details, create user accounts, and manage other settings. Most other RADIUS server don’t offer web-based admin access; some don’t even provide a GUI.

Setting up the Service

Our step-by-step guide will help you set up your network with our service:

• Create accounts for your Wi-Fi users and create a secret (password) for your router or access points (APs) in the AuthenticateMyWiFi™ Control Panel.
• Configure each wireless router or AP with a few settings.
• Connect to your wireless network and enter a username and password you created in the AuthenticateMyWiFi™ Control Panel.

You can change the usernames, passwords, and revoke access anytime via the Control Panel. Plus for each user you can optionally restrict access by login times (ie Monday. Friday 8am to 6pm), limit access via a particular Wi-Fi computer/device (ie their company-issued laptop), or via a certain AP(s).

Lessons from building our RADIUS server in the Cloud

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA or Triple A) management for users who connect and use a network service.

Why RADIUS?

You’re probably familiar with Wi-Fi authentication protocols like WPA-Personal that require sharing a single password to access a Wi-Fi network. These protocols are convenient for home Wi-Fi use, but they’re dangerously insecure for accessing an office Wi-Fi network or VPN.

Why? Consider these questions:

• How do you ensure the single password is not shared across insecure channels like emails / chat / common company whiteboards?
• When an employee is terminated, what prevents them from keeping the shared password after they leave?
• If a single employee’s password needs to be rotated, how do you do this without rotating the password for everyone in the office?

WPA-Enterprise solves these issues by allowing different passwords for each employee. When an employee connects to a Wi-Fi network using WPA-Enterprise, the Wi-Fi router connects to a RADIUS (Remote Authentication Dial-In User Service) authentication server to validate the user’s individual credentials. RADIUS is a fairly old protocol built on UDP, and operates at a lower OSI level than more modern SSO standards like SAML.

Most companies can’t or don’t want to host their own RADIUS authentication server. Rippling hosts a Cloud-based RADIUS authentication server for our customers, so that employees can then log into their Wi-Fi with the same Rippling credentials they use for other applications. And when an employee is terminated in Rippling, they immediately automatically lose access to the Wi-Fi network.- along with all other sensitive accounts managed by Rippling.

At Rippling, we’ve built a redundant and highly available infrastructure for RADIUS that turned out to be a little different than building redundancy for traditional web applications. In this post we’ll talk about the lessons we learned building redundancy for our RADIUS authentication system.

Project Goal Lessons

We were supporting RADIUS for Routers and Virtual Private Networks (VPN) for the last two years and at that point of time, two dedicated Amazon Elastic Compute Cloud (EC2) instances running RADIUS servers were more than enough for the ingress traffic. Since we are growing quickly, we started working on a project with two goals in mind:

• Auto scaling. RADIUS servers should be able to automatically scale during peak traffic load
• Auto healing. RADIUS servers should be able to heal automatically by fixing unhealthy servers

These are crucial for any production server and especially in our case because downtime in the RADIUS server could cause our customers to not be able to use their Wi-Fi network.

We were able to tick both of these points and achieve high availability for our RADIUS servers. In the process of doing this, we had a lot of learnings. We would like to highlight a few.

Lesson 1: In this case, it’s better to build than to buy.

In the current era, no one would ever build their own AWS; everyone understands how painful on premise infra maintenance was without AWS. Similarly, we started looking for a RADIUS-as-a-service provider who could partner with us to provide high reliability with reasonable pricing. To our surprise we found challenges across all RADIUS-as-a-service providers:

• They are on prem and don’t have the same ease of scaling that Cloud-native providers do.
• This in turn leads to higher pricing per user for any other RADIUS service providers.
• RADIUS-as-a-service providers didn’t provide the customization functionality that our customers need for more advanced authentication mechanisms.

In general we believe the bar for choosing to build over buy should be high. In this case, since RADIUS is part of our core identity management infrastructure, we decided to build the system in-house to provide the customization, scalability, and pricing that our customers expect.

Lesson 2: Containerize builds for easy development, testing and production deployment

When we started adding support for RADIUS servers, we didn’t want to reinvent the wheel so we started building it on top of proven Linux libraries. This significantly accelerated our RADIUS implementation. thanks to the open source world! We initially started with Vagrant Ubuntu for our development. Unfortunately, Ubuntu version differences between development and product created several inconsistencies during deployment.

So, we moved the environment from vagrant to docker containers.- one DockerFile for development, testing and production. This completely removed the “but it works on my machine!” scenario. See our earlier post for more advantages of containerizing your builds.

Lesson 3: Use NLB and sidecar containers for instance health checks

Load balancers play a crucial role in distributed systems. Amazon Application Load Balancers (ALB) currently support only HTTP traffic because more than 99% of the services hosted in AWS are HTTP-based. This wouldn’t work for us because RADIUS uses UDP and also we need to support IP-based load balancing as well. Network Load Balancers (NLB) serve this purpose, by providing load balancing at the Transport Layer as opposed to Application Layer that ALB uses.

Because we required UDP support, it was obvious that we should choose NLB rather than ALB. There was, however, a weird limitation with health checks in NLB: it would server traffic in UDP protocol and health checks needed to happen on TCP. As a result, we had no choice but to end up with 2 processes in the container:

• Main traffic. a RADIUS server process running in network port 1812 and using UDP
• Health check. a Python TCP health check wrapper running in network port 1814 using TCP

Now another interesting problem appeared. NLB allows us to do health checks on static fixed ports or traffic ports with ECS auto scaling and load balancer integration. Autoscaling spins up multiple containers in a machine and attaches a load balancer using a dynamic traffic port. But the health check port cannot be dynamic, restricting us to use only one container per EC2 instance.

We had three options to proceed further:

Option 1

• Use a static host port for both UDP traffic and TCP health checks, but with limited scalability of 1 task per instance.

This would lead to underutilization of the instance, so we discarded this option. Majority of our services use HTTP interface and radius server is only UDP service with a maximum of 6 containers, since the EC2 machines are shared across the services having 1 task per instance would work but we were looking for a more scalable approach to support us in future.

Option 2

• Run a separate daemon service on the same cluster instances which would serve health check requests.
• Both custom and other service containers can be placed on the same hosts so that at least health checks are in sync.

We did not love this option because the daemon service checked health status for the instances, not the containers. So if there were no RADIUS container in an instance, then a health check daemon running on it wouldn’t make sense. Having more granular health checks at a container level was a better choice rather than instance level.

Option 3

• Use a sidecar container approach along with AWS VPC networking mode where we get a unique IP per container. So each machine will have multiple containers with different internal IPs.
• The number of tasks per machine is now limited by the number of ENI’s (Elastic network interfaces) the machine can support. It is further improved using Elastic Network trunking.
• Because the IP is specific to the task, we can have static port mapping as well as multiple tasks per machine.
• Have a single ECS task with 2 containers listening on different protocols and ports to help manage traffic on UDP and health check on TCP separately

• Radius server container exposed on port 1812/UDP
• Health check container using python exposed on Port 1814/TCP for health checks only

The sidecar approach worked well and is a commonly embraced pattern when there are two different processes defined for the main app and health check separately.

This helps us check if the instance is up, but doesn’t provide a guarantee that the RADIUS requests are being processed properly. So this alone doesn’t provide confidence when we do auto recovery and auto scaling.

Lesson 4: Use a custom health check endpoint to verify the full RADIUS stack is functioning

There are several ways to implement health checks for a given server.

At a minimum, we should detect that the instance is up and the server process is running. Better, we could validate that other systems can communicate with the endpoint and return valid content.

Better, though, is to ensure that the server can communicate with all of the underlying downstream systems and provide the correct ACCEPT code for a valid user in the system.

In order to solve this problem, we wrote a thin python wrapper which opens up a TCP port to the outside NLB health check and does a RADIUS end-to-end test on UDP with several retries. ECS waits for 10 seconds for a successful health check response and that is ample time to do a consistent health check within python with upto 6 retries. Also we set the logic in ECS to drain the container if three consecutive health checks fail to avoid any intermittent issue. Frequency of health check for ECS container was set to 30 seconds.

Here is an example of the python TCP wrapper:

Lesson 5: Always keep the application servers stateless

In order to scale the servers, we had to make sure the RADIUS servers were stateless and didn’t store any data in rest. (Other RADIUS-as-a-service products do store state.) All the user level authentication data is passed through a secure encrypted tunnel to RADIUS and the data is held only in transit for the duration required. This made our containers very thin, stateless, dataless This, in turn, increased the security and made it easy to replicate the containers during peak load.

Lesson 6: Use Elastic IPs in addition to A records

High end routers like Cisco Meraki and Ubiquiti UniFi support domain names, so you can configure them to connect to “radius1.rippling.com” and they’ll do a DNSlookup and connect to the right servers. But there are many lower end routers which don’t support domain names and need to be configured to connect to a specific IP address. Always prefer and reserve elastic IPs which don’t change over restarts or re-provisioning because these values are configured in routers and are painful for customers to change.

Lesson 7: Provide secondary domains for higher availability

We implemented Auto recovery and Auto scaling in ECS. This mitigates the occurrence of downtime without any human intervention.

As Murphy’s law states “If something can go wrong, it will.”

What if one instance goes down?

Auto recovery should spawn a new container and kill the unhealthy one.

What if the NLB or all the instances under an NLB goes down simultaneously? (very rare)

We added two different Network Load Balancers (NLB) to increase the availability even further.

If the Routers and VPN systems support a secondary RADIUS server and are configured, then it should seamlessly fallback from radius1.rippling.com to radius2.rippling.com resulting in zero downtime.

To conclude

We migrated all of our existing customers to this new RADIUS infrastructure and have seen excellent uptime since then. We also have better visibility through proper health checks and have greater confidence that the system will scale even as usage grows exponentially.

If you’re interested in working on problems like this and building infrastructure to modernize traditionally painful HR and business processes, check out our jobs page! We’re hiring for engineering and infrastructure roles in our San Francisco and Bangalore offices.

IPSK with RADIUS Authentication

When setting up an enterprise wireless network, it is common to configure WPA2-Enterprise authentication with a centralized authentication server to provide heightened security for clients connecting to the network, while still allowing for easy and scalable management of authorized users. However, IT administrators may still encounter some drawbacks with this method of authentication. While a username and password provides extra security, users may find remembering an extra set of credentials to be cumbersome when trying to get connected, and may be better served by using a private PSK. Additionally, certain devices may not support WPA2-Enterprise authentication, and would require an additional PSK SSID to be set up to connect to the same network, increasing wireless overhead and compromising on security. Identity PSK with RADIUS authentication resolves these issues by acting as a standard WPA2 PSK SSID to clients, while authenticating clients to a central server based on their MAC address and allowing different PSKs to be set for specific clients or groups of clients.

This article will provide a walk-through of how to set up Identity PSK in Dashboard, as well as on FreeRADIUS, Cisco ISE, and Microsoft NPS.

This feature is supported only on firmware MR 26.5 and above. If using Microsoft NPS, MR 30.1 or higher is required.

This feature will not work with SSIDs that are configured to tunnel traffic to a MX Concentrator.

Enabling and configuring IPSK with RADIUS authentication

If the MAC address and PSK used by the associating client is configured on the RADIUS server, then only that client will be able to associate to the SSID. Configuration on Dashboard is as follows:

• From Dashboard navigate to Wireless Configure Access control
• Under SSID, select the SSID from the drop-down that you want to configure.
• Select Identity PSK with RADIUS from the Security section of the page.
• Under Splash page, choose None (Direct access).
• For RADIUS servers, click Add server. Enter the RADIUS server Host IP or FQDN, listening port and RADIUS shared secret to be used by your APs which are configured RADIUS clients on the server.
• A Per device PSK SSID can bridge wireless devices onto different VLANs if a Bridge mode SSID is used. A default SSID VLAN can be set by enabling VLAN tagging under the Client IP and VLAN section. By setting the RADIUS override to Override VLAN tag, the RADIUS response can be used to override the default VLAN tag. RADIUS accept messages containing a different VLAN tag will be able to override the default VLAN for the SSID. For more information on configuring VLAN override via RADIUS, check out our VLAN Tagging article.
• Click Save.

Use of special characters in the Shared secret is not allowed with some RADIUS servers. This may cause the authentication to fail.

The RADIUS server used for authentication can vary depending on the network. The Tunnel-Password attribute is the field that is used on the RADIUS server to bind the MAC address and PSK. If the PSK matches the RADIUS server’s entry for the client’s MAC address, the wireless client is authenticated and associated on the wireless network. See below for configuration with FreeRadius and Cisco ISE.

Configuration of IPSK with RADIUS authentication

FreeRADIUS Configuration:

The example setup below is using FreeRADIUS version 3.0.21. Exact steps may vary depending on the version of FreeRADIUS you are using. Please consult the FreeRADIUS documentation.

• Navigate to: /etc/freeradius/3.0/
• In the clients.conf file, configure the AP IP address or subnet and secret. This will be the same secret you entered in Dashboard under RADIUS Servers.
• To add a MAC address and pre-shared key for a client, navigate to the users file and enter the MAC address and password in the below format. Do not use colons in the MAC address username or PSK. Ensure that you tab the Tunnel-Password to nest it under the username, otherwise FreeRADIUS may fail to start with errors. Cleartext-password := Tunnel-password =
• To configure a default pre-shared key to be used by clients not explicitly listed in the users file: DEFAULT Auth-Type := Accept Tunnel-Password =
• Once this configuration is saved you should be able to authenticate your client devices based on the PSK.

Cisco ISE Configuration:

The diagram below shows the general flow of traffic when using IPSK to authenticate against a Cisco ISE server.

The following sections focuses on Cisco ISE 2.4. Configuration may vary based on the version of Cisco ISE.

Adding Network Devices and Assigning to a Group

• Navigate to Administration Network Devices.
• Click Add to add a new network device.
• Fill out the following fields: Configure the IP Address field with the management IP subnet for your access points. Make sure to configure a Location so that the authentication can be matched to the correct policy set.

Create a policy set and default rule configuration

• Navigate to Policy Policy Sets
• Create a new policy set with the condition Device Location and select the location you applied to the MR Device type. Then create another condition and use Radius: Called-Station-ID ENDS_WITH.Note: PAP is disabled by defualt under the Default Network Access policy. PAP should be enabled by going to Policy Results Allowed Protocols Default Network Access and checking the box to Allow PAP ASCII.
• Navigate into that policy set by clicking the arrow to the right. Expand the Authentication section of the policy and modify the default rule to the following: Make sure to select Internal Endpoints and If User not found: Continue. This will allow devices that are not already in ISE the ability to be processed through the authorization rules.
• Next expand the Authorization rules and select the default rule. In the default rule:

• Deselect Deny access.
• Click the icon and create a new profile. This will be the default PSK. For the PSK response, Meraki uses the Tunnel-Password attribute and value for the PSK transmission as it is encrypted in transit between the RADIUS server and the Network Access Device.
• Select the default PSK authorization profile we created for the default rule and click save.

Creating Endpoint Identity Groups for PSK Management

• Navigate to Work Centers Guest Access Identity Groups
• Click Add to add a new group.
• Name this group ‘PSK_Devices’
• Create another group called ‘PSK1’ and nest it under ‘PSK_Devices’

Creating Authorization Profiles for Each PSK with Group Policy Assignment

• Navigate to Policy Policy Elements Results Authorization Authorization Profiles
• Click add and create at least 1 PSK Authorization Profile. In this example, PSK1 is used and ‘PSK1’ is returned as the dashboard group policy to apply to the client via Filter-ID.

Creating Authorization Rules for PSK Assignment

• Navigate to Policy Policy Sets
• Expand the Authorization Rules.
• Add a new rule above the default rule with Insert new row above.
• Name this rule ‘PSK1’ and use the following condition configuration:
• Next select the PSK1 Authorization Profile created for this rule and click Save.

Add Devices to the PSK1 Group

For this guide a single MAC address will be added; however, using the “Import” function, large groups of devices can be added at a time.

• Navigate to Context Visibility Endpoints
• Click the symbol above the devices list and enter the MAC address of your test client

Microsoft NPS Configuration

Note: MR 30.1 firmware and higher is required for IPSK with NPS.

IPSK with RADIUS using a Microsoft NPS server is supported when the following criteria are met:

• The Tunnel-Password RADIUS standard attribute is present in the Access-Accept packet from the NPS server.
• Cisco Vendor-Specific Attributes psk and psk-mode=ascii are present in the Access-Accept from the NPS server.

First, ensure your client MAC addresses are added to a User Group on your AD server. To configure the policy on the NPS server,

Open an existing policy or create a new one. The Overview tab of the properties of the policy should look like the following:

On the Conditions tab, choose the User Groups value for the devices you want to authenticate using IPSK on your AD server

On the Constraints tab, uncheck all authentication methods except for PAP

On the Settings tab, add a Standard RADIUS attribute of Tunnel-Password. It does not matter what the actual value is here, because the clients will not be using it. However, it MUST be included. Otherwise, the MR will reject the response from the NPS server

On the Vendor Specific section, add a Cisco AVP and configure both a psk and the psk-mode=ascii

The psk value is the PSK that should be entered on the supplicant. The Access-Accept packet for a client with the above configuration looks like the following. Notice the Cisco Vendor-Specific AVPs of psk-mode and psk as well as the standard Tunnel-Password AVP. The Cisco psk AVP has the PSK in cleartext.

Applying Dashboard Group Policies

• Navigate to Network-wide Configure Group Policies
• Create a new Group Policy called ‘PSK1’ Feel free to configure anything needed here including but not limited to:
• Firewall Policies
• Traffic Shaping
• Umbrella Group Policies
• When you are finished, click Save changes.

Validating PSK and Group Policy

• Connect to the test SSID using your test client.
• Check the logs in Cisco ISE under Operation RADIUS Live Logs
• Check Dashboard under Network-wide Monitor Clients and select the test client:

Logging into my Wi-Fi With RADIUS

I have been using my UniFi system for a few months and I’m very pleased. The Wi-Fi is very fast, I can roam around the house seamlessly, and the handoffs are seamless. Now I want to move to the two final stages: advanced access control and then content control for the kids. For access control, I’m going to use RADIUS, specifically pfsense’s freeRADIUS package. I’ve read that this it is a bit arcane, but my experimentation has shown that it’s actually pretty straightforward.

Prep

First things first, I needed two things. The freeRadius package on my router, and a radius certificate. I used the package manager and the LetsEncrypt system, respectively, for this.

freeRADIUS

The FreeRADIUS system makes sense when you think about it, and so does the UI in pfSense, but at first glance they are both a bit odd.

freeRADIUS doesn’t take calls to authenticate directly. Rather, you register systems that will be using it to authenticate. So each Switch, AP, and server that uses a given RADIUS server will get registered independently. Those devices then send in authentication requests to the RADIUS server.

Also, the settings allow for many mind-bending configurations, since it’s built to be very pluggable.

RADIUS was built for metered dial in, so it can do things like measure how much time a dial-up user spent online.

Also, RADIUS stores all its secrets in plain text, by design. I guess the message is keep your RADIUS server safe, but I’m a bit leery of this. You can also store user password as MD5 hashes, but not device secrets, which are just plain text in config files.

First Steps

The first step in configuring RADIUS is on the 4th tab (I told you the UI wasn’t intuitive). You need to add interfaces for authentication, accounting, and status.

You will need to create 3 ports per IP you want the server to listen on:

• Port 1812: authentication
• Port 1813: accounting
• Port 1816: status

I suspect you may only need an entry for 1812, but I added all 3. You also need to select the port type in the dropdown, even though 1812 and 1813 are registered ports.

Once that is done, you can explore the settings tab (tab 5), which I didn’t change. These seem exotic.

Clients

Then I headed to the NAS/Clients tab (Tab 3). Nowadays, NAS means ‘Network Attached Storage’, and are usually a box with hard drives inside and blinky lights outside that you can buy at BestBuy. Real players build their own.

However, back in the day that RADIUS was developed, it meant ‘Network Access Server’, which is just like it sounds – a server that will make access requests of the RADIUS server.

Each device that needs to access your RADIUS server needs an entry here. Each AP, other servers, etc. Since Unifi uses one radius profile, you’ll want to use the same secret for all Unifi devices. You’ll want to enter each of your APs here (which is why I used DHCP reservations, to the IPs wouldn’t drift). I just used passwordsafe to gen a of 16 character password to use.

EAP Setup

The EAP tab (Tab 6) took me the longest to figure out, and also causes me the most consternation. This is where the security of the call to the RADIUS server is set up. The two variables are how you want to store your password (md5, clear text, or ntlm hash) and what protocol to use (there are a bunch). I’m not totally comfortable storing password in plain text, but MD5 isn’t super good either. Then there is the cryptic ‘Disables weak EAP types: MD5, GTC and LEAP’ checkbox, which apparently prevents weak types, but requires either cleartext or NTLM hashes. pfSense currently does not seem to have native support for ntlm hashes, so I feel that that checkbox is somewhat ironic.

I get it that RADIUS is predicated on a very secure core server, but still.

Anyhow, I found that this matrix was very helpful in figuring this out, and the freeradius wiki has a very good explanation of the EAP modules. I ended up with the configuration below:

I’m a bit out of my depth here, since it seems that every manufacturer of hardware put their hat in the ring when this was designed.

So I chose TTLS (Tunneled TLS) so it secures the connection using TLS, with GTC as the inner protocol, which also supports MD5 passwords.

Users

This part is easy. Go to the Users tab (Tab 1), add a user, assign password, choose MD5-Password as the encryption. There is a lot of other cool stuff you can do, like assigning VLANs to users, and using one-time passwords, but they might be overkill (for now…).

FireWall

By default, I allow all traffic to the internal interfaces of my pfSense server, so nothing is needed here. But you might need to to open the RADIUS ports.

Unifi Setup

Unifi setup is pretty easy. In the Profiles Tab of the Settings Section, Add a RADIUS profile for that connects to your new freeRADIUS server.

Once that is done, go to the wireless network you want to secure, and assign that profile to the network:

Once this is done, you ought to be able to log into your wireless network using a username and password, rather than a shared Wi-Fi Password.

Troubleshooting

For testing, it’s possible to connect to your freeRadius server from another nix host to test if it’s working. The program itself is called radtest and it’s part of freeradius-utils. So:

#yum install freeradius-utils #radtest username password 0 sharedsecret

It will emit diagnostic information to help identify if everything is working. Honestly, it wasn’t as bad as I expected. It’s not super intuitive, but it makes sense in its own way. You will need to add that server you’re testing from as a NAS client.

What I’m listening to as I do this:

Iron Maiden’s Somewhere In Time. One of my favorite albums and the album that got me into Heavy Metal. As an impressionable teenager, I got loved this album, between the artwork, the concept songs, and the moody theme. The track Alexander the Great is the reason I know all about Alexander the Great, which is very helpful.

Wireless Authentication Methods

There are many different methods you can use to authenticate wireless clients. Some of these methods are outdated and have security weaknesses. They have been replaced with newer, more secure authentication methods.

In this lesson, we’ll discuss the most common authentication methods.

Open Authentication

Open authentication is one of the two authentication methods from the first 802.11 standard. As the name implies, open authentication offers open authentication to a wireless network. The wireless client sends an authentication request to the AP, which the AP accepts without question. You don’t need a pre-shared key or credentials. After authentication, the wireless client associates with the AP.

Using open authentication doesn’t automatically mean that there is no authentication at all. You can still authenticate wireless users on another level. If you have ever used a public wireless network at an airport, hotel, or fast food restaurant, you know what I’m talking about.

You can connect to the network without any issues, but as soon as you open your web browser, you see a web page where you have to enter your credentials. Until you enter your credentials, all traffic is blocked. On the wireless level, there is no authentication, but there is on the upper layers.

WEP

Wired Equivalent Privacy (WEP) is a security algorithm and the second authentication option that the first 802.11 standard supports. The idea behind WEP is to make a wireless network as secure as a wired link. WEP uses the RC4 cipher algorithm to encrypt every frame so that eavesdroppers can’t read the contents.

The algorithm uses a WEP key to create other encryption keys, one for each wireless frame. When the sender and receiver use the same WEP key, they can decrypt each other’s frames.

WEP supports two authentication methods:

With open authentication, the wireless client doesn’t provide any credentials. It’s the same open authentication, as I described before. The wireless client can authenticate to the AP without any issues. We only use WEP encryption to encrypt data frames.

With shared key authentication, we also use the WEP key for authentication and encryption. You can use this to test if the wireless client has the correct key. The AP sends a random challenge to the wireless client. The client encrypts the challenge phrase with WEP and sends the result to the AP. The AP compares the result from the client with its own to see if both ends use the same WEP key. If not, the wireless client can’t associate with the AP.

WEP keys are 64 or 128 bits and represented with a string of 10 or 26 hex digits. The longer the key, the more unique bits, which results in stronger encryption.

Sometimes you see that WEP uses 40-bit or 104-bit encryption. WEP uses a secret key (configured by the user) and a 24-bit Initialization Vector (IV). The IV is also transmitted in plain text, so some vendors mention that WEP uses either 40-bit or 104-bit encryption, excluding the 24-bit IV.

Unfortunately, WEP is a broken protocol. The original 802.11 standard is from 1999. Researchers discovered some weaknesses in 2001, which make it very easy to decrypt any WEP encrypted traffic and to retrieve the pre-shared key.

WEP is officially deprecated since 2004, in the 802.11i amendment.

2.1X/EAP

The original 802.11 standard only supported open authentication and WEP. It was time for more secure authentication methods.

Instead of adding new authentication methods into the 802.11 standard, IEEE chose the Extensible Authentication Protocol (EAP) framework to add new authentication options. EAP has functions that multiple authentication methods can use, and it integrates with 802.1X port-based access control.

An 802.1X-enabled port limits access to the network until the client successfully authenticates. For wireless networks, it means that a wireless client can associate with an AP, but it won’t be able to do anything else until authentication succeeds.

Here’s what 802.1X EAP authentication looks like:

There are three device roles:

The supplicant (wireless client) uses open authentication and associates with the AP. It doesn’t end there, though; the supplicant communicates with an external authentication server to authenticate itself. The authentication server is usually a RADIUS server. The authenticator in the middle is the AP or WLC, which blocks all traffic, except for authentication traffic. When the authentication server verifies the credentials of the end user, the authenticator unblocks the traffic and permits all wireless traffic.

Now you understand the basics of 802.1X/EAP, let’s take a look at some popular EAP authentication methods.

LEAP

Cisco developed a proprietary wireless authentication method called Lightweight EAP (LEAP) as an attempt to create a more secure authentication method than WEP. It uses two features:

LEAP allows clients to re-authenticate. Each time the client re-authenticates, the client receives a new WEP key. The idea behind this is that the temporary WEP key doesn’t live long enough to be cracked.

With mutual authentication, the client sends a username and password. The client and the authentication server also send each other a challenge message. When they can decrypt each other’s messages, they’ll have authenticated each other.

One of the issues with LEAP is that it uses a modified version of MS-CHAP, a weak authentication protocol. It’s vulnerable to an offline attack if you use weak passwords. Users should use strong passwords, which doesn’t often happen because those are difficult to remember.

You can still configure LEAP, but you shouldn’t use it anymore. There are more secure EAP options.

EAP-FAST

Cisco developed another EAP method called EAP Flexible Authentication by Secure Tunneling (EAP-FAST).

EAP-FAST protects credentials by exchanging a shared secret generated by the authentication server. This shared secret is called a protected access credential (PAC) and used for mutual authentication. There are three phases:

• Phase 0: The authentication server generates the PAC and transmits it to the wireless client (supplicant).
• Phase 1: The authentication server and supplicant authenticate each other and negotiate a TLS tunnel.
• Phase 2: The end user is authenticated through the TLS tunnel.

What happens is that we have two authentication processes, an inner and outer authentication:

• First authentication is used to build the TLS tunnel.
• Second authentication happens inside the TLS tunnel, and we use this to authenticate the end user.

To make EAP-FAST work, you need a RADIUS server. However, the RADIUS server also needs to act as an EAP-FAST server because it needs to generate PACs. If you already have Cisco Secure Access (ACS) or Identity Services Engine (ISE) in your network, EAP-FAST might be an option.

PEAP

Similar to EAP-FAST, Protected EAP (PEAP) uses inner and outer authentication. However, instead of a PAC, the authentication server presents a digital certificate to the supplicant for the outer authentication.

We can use the certificate to verify whether the wireless network is legitimate or not. This helps to prevent the end users from connecting to rogue APs, as long as they don’t accept the certificate if they don’t trust it. End users should not be responsible for checking if the certificate is legit or not. Checking the validity of a certificate can be a difficult for an end user. Instead, you should configure the operating system of the wireless client to trust only specific certificates and only to connect to trusted wireless networks with matching certificates.

If the wireless client accepts the digital certificate, the supplicant and authentication server build the TLS tunnel. We can authenticate the end user through the TLS tunnel using multiple protocols, including MS-CHAPv2.

PEAP is a popular method for wireless authentication. You only need a certificate for the authentication server, not on the wireless clients. This makes it quite easy to implement PEAP.