Okta Radius Agent and Authentication Protocols (AAA)

Overview

This document will cover the main usage of the Okta RADIUS Agent, including how to set up and deploy for network access use cases.

• Understand the concept of AAA (Authentication, Authorization, and Accounting).
• Breakdown of the most common authentication protocols used by RADIUS.
• Implement wireless and wired authentication using Cisco Meraki WLC and Cisco switches with Okta for authentication and MFA.
• Test the configuration using Linux Tools

At the end of the document, you should be able to setup wireless and wired authentication using EAP-TTLS authentication.

Understanding the concept of AAA

Triple-A, Authentication, Authorization, and Accounting are the fundamental framework to control and track access within computer networks and systems. There are many ways to explain the framework, but the easiest is the credit card example. At first, you have your card, which is the possession factor, and the knowledge factor is your PIN number. The bank ATM, think of it like the authentication server or your gateway to access your account. Once the authentication process is done, you have access (“Authentication”). The level of access is determined by the privilege, so you only have access to your account and none of the others (“Authorization”). After each transaction, each step is logged, and this part is the accountability (“Accounting”)

Authentication

The validation of Identity or credentials, through time the authentication process evolved from password complexity to multiple proofs such as what is mostly used today MFA.
In network access this action is handled via Authentication Server or trusted identity provider.

Authorization

The level of access provisioned to the authenticated identity or request, this process comes always post authentication, based on a decision made via policy engine.
Usually the server will have set of policies that will give every authentication request the corresponding access level permissions

Accounting

The tracking process, each access to a network device or application must be logged and tracked, facilitating the accountability process as well security audit

The concept of AAA can be applied in different applications, such as device administration, network access

Common protocols applying this framework are

• RADIUS
• TACACS+
• Diameter

In this document our focus will be the network access part using RADIUS

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol initially employed in Point-to-Point Protocol (PPP) scenarios. Its primary purpose was to extend layer 2 protocol capabilities over networks, facilitating the transmission of information to an authentication server via layer 3 networks. Beyond its original role in network dial-up services, the flexibility of RADIUS led to its adoption as the preferred protocol for transporting the Extensible Authentication Protocol (EAP) within Dot1x, IEEE 802.1x, or Dot1x standards. This advancement enabled users to authenticate before being assigned an IP address

Radius uses UDP for communication the ports can be changed but common for authentication 1645 or 1812, for accounting 1646 or 1813 the ports 1645, 1646 sometimes called legacy ports.
RADIUS server and network device speak with each other with a shared secret that must be configured on both ends.

Note: 
RADIUS combines Authentication and authorization, that's why mostly used for network access as the access-accept will contain also the level of access for user.

EAP Authentication

Extensible Authentication Protocol (EAP), is an authentication framework that defines the encapsulation of username/passwords, tokens, certificate, one-time-passwords and so on.

IEEE 802.1X or Dot1x is the standard of network based authentication and it defines the user of EAP over lAN AKA EAPoL, the EAP encapsulation will be carried on layer 2 using dot1x and in layer3 using Radius.

Network Access Key Components (Dot1x)

There are 3 main components in the network access

• Supplicant: the user or machine trying to access the network
• Authenticator: Network device can be either Switch or wireless LAN controller (WLC), sometimes called Network Access Device (NAD)
• Authentication Server: The server that performs the authentication/authorization

In the figure1.2, between Authenticator and Supplicant the carrier of EAP messages is Dot1x, and between Authenticator and Authentication server the carrier is RADIUS

EAP Types

Native EAP Types

The EAP is carried natively without any additional protection layer, some common types below

• EAP-MD5
• EAP-TLS

EAP-TLS mostly used in BYOD and considered one of the strong method as it leverage certificate based authentication form TLS/SSL protocol, EAP-MD5 used sometimes in authentication method called MAB, machine authentication by pass something based on mac address details, rarely used at the moment.

Tunneled EAP Types

EAP tunnels create an outer layer that adds more protection to the transported EAP messages

• EAP-PEAP
• EAP-FAST
• EAP-TTLS

Each method has its own way of building the tunnel, what we will cover today is EAP-TTLS

Okta Radius Agent

Okta radius agent act as on-prem lightweight server which will proxy the authentication request to Okta in order to validate the user, then Okta can prompt for MFA if its enabled after Okta validate user the access-accept will be sent to the network device, the radius agent and application in Okta currently only support the authentication.

Overall architecture of deployment it can be single radius agent or multiple Agent for high availability, in the RADIUS architecture high availability is determined via network access devices.

1. The user authentication flow begins, whether for wired or wireless connections. Once the network device detects the port is up, it starts the EAPOL (Extensible Authentication Protocol over LAN) process and requests credentials from the machine. An EAP-Message will be sent requesting the user’s identity.
2. The Network Access Device (NAD) takes the EAP-identity information and starts a RADIUS message with the RADIUS server in an Access-Request message.
3. The Okta RADIUS agent responds back with a challenge. After the exchange of information is completed, the agent sends an outbound connection through HTTPS to Okta to validate the user.
4. Okta validates the user and sends an MFA (Multi-Factor Authentication) push notification to the user, if enabled. Once the user confirms it, Okta confirms the information back to the RADIUS agent.
5. The RADIUS agent sends back an Access-Accept message to the Network Access Device, allowing the user to access the network.

Note: 
In deployments with multiple agents behind a load balancer, it's essential to configure session stickiness (also known as session persistence). This ensures that a user's session is maintained with a single server throughout the authentication process. Without stickiness, the load balancer may route messages to different servers, causing the authentication process to fail. This is crucial because RADIUS EAP messages are not stateless and require the entire authentication flow to be handled by the same server until completion

Network Access Use case

The following section will focus on implementing wired and wireless authentication with Okta using EAP-TTLS, it will cover the configuration for Okta Radius application, Okta Radius agent, Network access device and finally the supplicant EAP-TTLS Profile.

Configuration steps:

• Okta Radius agent installation
• Radius application in Okta
• Network access devices configuration examples
• Windows/Mac EAP profile configuration

Okta Radius agent and Application setup

Download and install the agent

The agent can be found from admin console Settings > Downloads

The agent can be installed either in windows or linux

Linux Installation steps

• Download the package to the target server and install it using the command
  apt install ./<package_name.deb
• During the installation the script will prompt you to add the Okta base URL and if you are using proxy
  

• After typing the base URL the script should prompt you a url to authenticate and approve the agent, this url can be accessed using web browser from different machine

• Approve the agent API access from web browser after logging and authentication

Now you should be able to see the agent available in Dashboard > Agents > RADIUS

Windows Installation steps

• Run the installer in windows, and it will walk you through in GUI
• Choose if you are using proxy, if not continue and this will go the base url

• This should open up a window browser to authenticate and accept the agent to connect to Okta

• Finally Agent will start and be ready to use

Now the agent should be available in Dashboard > Agents > RADIUS

Radius Application in Okta

From Okta App catalog, filter on Radius and choose the application, In this example will use Cisco Meraki application for both wired and wireless authentication.

In the Sign-On Options, configure the port and radius shared secret

Note: 
The port can be customized and it's unique for the application, same port can't be used for another radius application, however this only for applications you can have multiple Radius agents for high availability.
The shared secret is random secret of choice that must be configured, this shared secret later on used on network devices to communicate with radius agent. 

Then under Authentication enable the EAP-TTLS

upload the certificate, steps to understand the certificate requirements are available in Appendix

Enable the settings to allow MFA automatically so that push can happen directly to user with Okta verify

The final step will be to assign the users to the application, like any other application in Okta
I will assign groups

The application is ready

Note: 
The application is generic, you can use it for wired authentication and wireless for any other provider or vendor.
when adding Radius agent and enabling Threatinsight make sure to follow this document and allow the trusted proxy ip in network zone.

Wired User Authentication Cisco Switch

This example I will use Generic AAA commands on Cisco switch, there are currently different styles but the concept is the same

Configuration on switch

#Enable  AAA on Switch 
Switch(Configuration)#aaa new-model 
#Enable the dot1x authentication 
Switch(Configuration)#authentication dot1x default group radius
Switch(Configuration)#dot1x system-auth-control
#Configure the Radius server 
Switch(Configuration)#radius server okta  address ipv4 <ip> auth-port 1812
 key <shared_secret> # same as the one in the application 
#under ports, enable the dot1x authenticator 
Switch(config-if)#interface GigabitEthernet0/1
 switchport mode access
 media-type rj45
 negotiation auto
 authentication host-mode multi-auth
 authentication port-control auto
 dot1x pae authenticator

The configuration should enable the basic 802.1X setup. While more customization is possible, this document covers only the basic configuration of 802.1X. For more detailed configuration options, please refer to the references in the appendix.

Wireless User Authentication Cisco Meraki Wirless LAN

• Sign in to Meraki Console
• Go to Wireless > Configure > SSIDs
  From here you can add new SSID or modify and existing one

• From Wireless > Configure > Access control

Enable the Security setting to use WPA2 Enterprise and select my RADIUS server

Scroll down under RADIUS and add the RADIUS Server, you can add multiple radius servers

• Add Radius server

A couple of notes:

• RADIUS Accounting: Not required as we do not provide accounting for RADIUS.
• RADIUS Testing: This setting can help in the case of multiple RADIUS agents, allowing detection if a server is down and enabling fail-over to another one.
• Advanced RADIUS Settings: The EAP timers can be changed, which can be very useful in case of delays. Sometimes, it’s important to modify the timer.

The Wireless controller should be ready to use and clients can login and authenticate with Okta

EAP Profile configuration on Supplicant

Windows EAP Wired Configuration

• Enable wired auto-config from Services

• From network and sharing center > Change adapter settings

• Click on Authentication

From drop down choose the EAP-TTLS, then click on settings

Choose the certificate to validate the EAP-TTLS connection

• Click on Additional Settings, and use the user authentication method

Windows EAP Wireless Configuration

From Network & internet > WiFi > Managed known networks

Add network, give the SSID name and choose WPA2-Enterprise AES

Choose EAP Method EAP-TTLS and authentication method PAP

Finally add the certificate and put the credentials for user

MacOS EAP Configuration Profile

Jamfcloud steps:

• Go to Devices > Configuration Profiles > New Mobile Device Configuration Profile > Wi-Fi

• Configure the SSI and the Secutiy type to WPA/WPA2 Enteprise

• Network security settings, enable TTLS and use the inner method as PAP

• Allow Certificate Trust

The certificate can be pushed from the device configuration profile as well, this configuration should allow the user to connect to SSID with EAP-TTLS

Test the configuration

To test the configuration, I will use a tool called ‘eapol_test’, hosted on a Linux machine. This tool will act as both the network access device and the client, helping to troubleshoot and verify the Okta side configuration.

Below steps to install the tool

• Install supplicant

sudo apt-get update
sudo apt-get install wpasupplicant

• Install eapol test package

sudo apt install eapoltest

• Configure the eap profile to test in radius, will name the profile eap_ttls.conf

network={
ssid="Test-Wi-Fi-WifI"
key_mgmt=WPA-EAP
eap=TTLS
identity="your-username"
anonymous_identity="anonymous"
password="your-password"
phase2="auth=PAP"
#ca_cert="/path/to/ca_cert.pem" # Optional if the server certificate validation is needed, if needed add the ca and remove the # from the command 
}

• Test the EAPOL and read the results

eapol_test -c eap-ttls-pap.conf -a RADIUS_SERVER_IP -p RADIUS_SERVER_PORT -s RADIUS_SHARED_SECRET

If the test is working and you got access accept, this means that both Okta radius agent and Okta application works fine.

Appendix

EAP-TTLS preparation

Before we go in details couple of notes to cover about certificates, you will need to have server certificate with private keys available to be installed in The application, certificate requirement for EAP-TTLS

• Key Usage: DigitalSignature, KeyEncipherment
• Extended Key Usage (EKU) ServerAuth

Openssl example, to generate and sign certificate, make sure of the certificate trust for more information check this document, be aware some devices don’t accept self-signed certificate like android, in that case you need the certificate to be signed but not self-signed certificate.

Below steps to generate Certificates using Openssl

• Generate Certificate Authority (CA)

#First Private keys 
openssl genpkey -algorithm RSA -out ca.key -aes256 -pass pass:<Passowrd>

#Generate Self-signed CA 
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -passin pass:<Passowrd> -subj "/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=RootCA"

CA should be ready now we can create the EAP Sever certificate that will be installed in Okta

• Generate certificate signing request (CSR) for EAP Server.

#Private keys
openssl genpkey -algorithm RSA -out user.key -aes256 -pass pass:<password>
#EAP Server CSR, 
openssl req -new -key user.key -out user.csr -passin pass:<passoword> -subj "/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=example.com"

• Sign the CSR with CA, this time will include important EKUs

openssl x509 -req -days 365 -in user.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user.crt -passin pass:<passoword> -extensions eku_section -extfile <(cat <<EOF
[eku_section]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
EOF
)

Final step is to combine the certificates then use them for the EAP TTLS Radius application

cat user.key user.crt ca.crt > Server.pem

Wireshark Radius & EAP-TTLS Breakdown

Tunneled EAP first establish TLS then transfer credentials inside secure tunnel
here is a quick reminder how SSL/TLS work

1. Client sends client hello message, which contains cipher suites that the client support and compression methods
2. Server_Hello in response picks one of the supported ciphers, Certificate, server_hello done indicating the server finished sending the informaiton
3. Client first validate the certificate then start key exchange with ClientKeyExchange
4. Client send change_cipher spec once the the keys are exchanged, then finish
   the change cipher spec is a message to server indicating all the following communication will be inside the tunnel or encrypted
5. Server confirm back and then you will see only Application data
6. Application data are encrypted

Now lets look at full communication between Radius Agent and network access device

• The Network access device will send the first access request to radius server with the user identity

As you can see the user is in clear, that’s why there is option to have anonymous identity,
The Access-request encapsulate EAP message carried in AVP 79 Attribute value pair.

Note: This here can show the flexibility of RADIUS as it can carry customized AVP allowing vendors to use specific attributes that suites their application

• Radius agent respond with Access-Challenge, this challenge will carry EAP-Message to start the EAP-TTLS
  

• Client will respond back with Client hello message similar to the flow explained above this time its encapsulated with EAP, you can see the cipher suites in the request as well

• Radius agent response back with Server_Hello

• Client respond back, exchange keys and then change cipher spec

• Server confirms back with change cipher spec

• Client exchange PAP credentials in encrypted tunnel

• Now server will verify with Okta and once user is authenticated it respond back with Access-Accept

This shows the entire flow for EAP-TTLS with RADIUS it can help you in troubleshooting.

References

1. Integrated Security Technologies and Solutions – Volume II: Cisco Security Solutions for Network Access Control, Segmentation, Context Sharing, Secure Connectivity and Virtualization, First Edition Chapter 2
2. RFC https://datatracker.ietf.org/doc/html/rfc4334
3. https://help.okta.com/en-us/content/topics/integrations/ha-main.htm
4. https://networkradius.com/articles/2021/10/25/command-line-EAP-testing.html
5. https://support.okta.com/help/s/article/securing-radius-authentication-against-malicious-logins?language=en_US
6. https://en.wikipedia.org/wiki/Transport_Layer_Security