- Some advantages of EAP-TLS:
- Scenario:
- EAP-TLS Work Flow with AGNI:
- PKI Setup for EAP-TLS:
- CV-CUE Configuration:
- Configure AGNI Server to do EAP-TLS
- Testing
802.1X has become one of the most used Authentication methods in WiFi in different verticals and industries for devices whose data and Intellectual Property (IP) needs to be protected. The basic framework used with this authentication is EAP which comes in different flavors. Based on different types of requirements and levels of protection, different flavors can be used. There are multiple sites on the internet where this topic is covered in great detail. Here, we look into the EAP-TLS way of authenticating users against AGNI server. EAP-TLS is a very secure way of authenticating a user/device which is trying to access the network using WiFi.
Some advantages of EAP-TLS:
EAP-TLS uses certificates to authenticate identities of User/device and Authentication server. This mutual authentication and encryption is done using Public-Private key Cryptography exchange. Certificates are generally not stolen or transferred over the air when the exchange is eavesdropped by a third party user. It doesnt use credentials like in one of the most used variants EAP-PEAP which can be stolen or transferred. The advantages of EAP-TLS are not limited to the ones specified above. There are more and available widely on the internet.
Scenario:
This will be a very common scenario where the employees coming to their working environment are trying to access the resources they generally work on via WiFi. WiFi EAP-TLS helps to make this connection more secure than other types of authentication and encryption methods. With the latest support of WPA3, the authentication with EAP-TLS makes this much more secure than it ever was.
EAP-TLS Work Flow with AGNI:
Let’s dive into the actual authentication flow for a WPA2/3 EAP-TLS exchange with AGNI Server. AGNI, considering that the WiFi is moving towards using certificates for authentication, supports only EAP-TLS. Here is the workflow when a user/device tries to authenticate using Certificates against AGNI server:
AGNI by default checks the status of the user for every authentication request made against itself via any IDP configured; OneLogin in this case.
Please refer to this blog to go through the AGNI IDP and RadSec communication configuration and details.
PKI Setup for EAP-TLS:
Client Certificate Authentication on AGNI:
Most of the companies/corporates already have their own PKI setup for their regular certificate based activities. AGNI can be used to validate certificates issued from these internal PKIs. In order to the same add internal PKI’s Intermediate OR Root certificate Authority on AGNI, Navigate to Certificates > Trusted > External > Add Certificate:
The certificate presented by the client during EAP-TLS exchange can be validated by the AGNI server using this Root CA OR Intermediate CA Certificate uploaded.
Server Certificate Authentication on Clients:
Certificates issued from this internal PKI can be then added to the devices for the users who will be trying to authenticate using 802.1X via EAP-TLS method. Client Certificates can be pushed to user devices by different methods like SCEP, Airwatch, GPOs, etc. This blog will not deep dive into client cert distribution techniques. Along with the client certificates, we need to push the Root CA of AGNI as well on the clients in order for them to validate the AGNI server Certificate for mutual authentication. AGNI Root CA can be downloaded from Certificates > Trusted > Internal:
AGNI PKI:
If you don’t have your PKI, then you can take advantage of AGNI PKI itself. There are not many configurations needed to enable this. At the time of creating a network in AGNI, you need to make sure that Onboarding is enabled (shown later).
Note:
- A Client/User can skip Server Authentication OR AGNI certificate validation; however it kind of defeats the purpose of mutual authentication that EAP-TLS provides and I encourage having that enabled.
- There are 2 different PKIs involved here. One for AP to form RadSec tunnels and another for EAP-TLS for User authentication. Both of them can be independent of each other and can have different PKIs.
CV-CUE Configuration:
Lets start configuring CV-CUE to bring up an SSID which does EAP-TLS against AGNI:
- Configure Radius Profile based on the certificates uploaded to the AP. Navigate to Configuration > Network Profiles > Radius > Add Server. Certificate tag names with DEFAULT are the TPM Module on the AP. ECC and RSA are the types of certificates that can be used.
- Select the Appropriate Certificate tag and add the CA certificate of AGNI so that the AP can use the same to authenticate AGNI server at the time of RadSec communication.
- Navigate to Configuration > WiFi > Add SSID > Basic
- Move to Security Tab > Select WPA2, WPA3 OR WPA3 transition mode > Enable RadSec > Select the RadSec server configured in Step 1 for authentication and accounting:
- Navigate to Network Tab > Add VLAN ID > Other parameters as needed:
- Proceed to further steps if Role based Access control is required. Else, save the configuration and turn ON SSID.
- (Optional) We can take advantage of the VSA and send VLAN OR User roles from AGNI based on different criteria like for the Users belonging to different Groups, types, departments, etc. With CV-CUE we can set up User-Roles which can then have different VLANs. Navigate to Configuration > Roles > Add a new Role. You can define Firewall policies, VLAN, etc for the users falling into this role. Repeat the same for other roles as required:
- Go back to the SSID Configuration Page > Access Control Tab > Enable Role Based Access Control > Select 802.1X Custom VSA and other parameters:
- Add other parameters like RF, etc as required > Save and Turn ON SSID.
Configure AGNI Server to do EAP-TLS
Access Device Configuration:
Please refer to this blog to go through the AGNI Access Device Configuration.
Network Configuration:
Here we configure the network settings on AGNI where we specify the AGNI regarding the SSID which will use Client Certificate to authenticate against the AGNI server. Follow the below steps to configure the same:
- Navigate to Access Control > Networks > Add Network > Configure as shown in the snap:
- (Optional for AGNI PKI as discussed above) Scroll down and enable Onboarding > Allow Local user self registration:
- Update and Save the network settings.
Add Segments
As discussed in Step 7 of CV-CUE configuration, it becomes necessary to setup Segments on AGNI for it to send User-Roles after validating different user type, group, department, etc considerations. Although, this is again optional (first 6 steps of CV-CUE configuration) as by default AGNI allows all access. However the same can be edited to deny.
In order to set up AGNI to send User Roles as VSA, navigate to Access Control > Segments > Add Segments:
Testing
Verify RadSec is up:
Navigate to Access Devices > Devices > Filter the specific AP name or MAC and verify a Green LED besides the same showing that the radsec is up and running.
The same can be done from AP Config CLI using the command “show log radsecproxy” and verify the status says up.
Client devices try to connect to the SSID and to verify the same check the Session Logs in AGNI > Monitoring > Sessions > Filter with the MAC address of the client to know the status of authentication.
Tip: For MAC Devices a profile will be needed which would define the certificate to authenticate to AGNI and validate the Server certificate sent from AGNI. Apple Configurator is one such application which is used to create profiles for MAC devices.
Of course, CV-CUE’s logs will provide more insights on the WiFi side of negotiations.
Note: The comments are my personal and information above regarding the workflow or testings are my personal understanding and to the best of my knowledge. Feel free to leave a comment for corrections if any as required.