RADIUS Reauthentication - Considerations and Best Practices

[rezaalikhani]

You can enable periodic endpoint reauthentication and specify how often it occurs. If you do not set a specific time interval before enabling reauthentication (by executing the “authentication periodic” command), the default interval between reauthentication attempts is 3600 seconds. Reducing this interval will cause your user ports to be reauthenticated more frequently. Use reauthenticatin functionality for two main purposes:

• From a security perspective, an attacker could exploit a hub or another device that maintains the port's link state. This would allow a rogue device to connect after the legitimate device has authenticated, granting the attacker prolonged access without requiring authentication. The recommended reauthentication interval should align with your organization's security policies. However, some Cisco documentation suggests setting this timer to a minimum of 7200 seconds (2 hours). While reauthentication every 2 hours may not entirely eliminate this attack vector, it significantly reduces the window of opportunity for an attacker.

• From a network efficiency perspective, there is typically no need to reauthenticate an endpoint that has already been authenticated and remains connected to the network. Following a successful 802.1X authentication, the port stays open until the session ends—most commonly due to a physical link-down event. Since physical connectivity is maintained continuously, the authenticated endpoint retains access to the port without requiring reauthentication. In some cases, however, reauthentication can serve as a de facto 802.1X keepalive mechanism. For instance, if an endpoint connects through an IP phone incapable of Proxy EAPoL-Logoff or CDP Enhanced for Second Port Disconnect, the switch cannot detect when to terminate the session. By enforcing periodic reauthentication, the switch can verify that the originally authenticated endpoint remains connected.

You can also force this timer from ISE, after successful 802.1X authentication takes place. To enable this functionality, instead of specifying the time, use the “server” keyword—in this case, reauthentication timer interval (session timer) is downloaded to the switch from the ISE:

Reauthentication timer setting in ISE is configured in seconds and the default value, as you can see above is 1800. If you select any number beyond 65535, the following warning message appears:

As you can see below, one of the enhancements in IOS XE 17.5.1 is the increased reauthentication timer support:

The reauthentication timer displayed is not a standard recommendation and consider reauthentication timers per deployment based on connection type (wireless/wired), design (what are the persistence rules on the load-balancer), and so on. If there is a load balancer, you need to make sure that persistence is configured in a way that reauthentication can be returned to the original PSN.

As you can see above, when enabling Reauthentication option in ISE Authorization Profile, you have two options to select:

• If you wish to allow the device to remain connected during the reauthentication (without interrupting user's traffic), select 'RADIUS-Request'. Using this option maintains the current Session ID for the user or device. 
• If you prefer that the device disconnects during reauthentication, select 'Default'—using this option will interrupt the user's traffic while the reauthentication process is in progress. This option regenerates the Session ID.

Important Consideration: Choosing the right option here has a direct impact on the endpoint's posture assessment behavior.
By default, whenever a NAD generates a new session ID for a device, the posture assessment process is automatically triggered on the endpoint. In certain scenarios, this behavior may not be desirable or acceptable.

According to RFC, the two “Termination-Actions” are defined as following:

Consider you have configured the Reauthentication timer to 10 seconds. From traffic capturing point of view, the following event occurs after successful authentication:

As the reauthentication method is configured as 'RADIUS-Request', as you can see below, after successful reauthentication operation, the NAD maintains its assigned Session ID:

If you select the 'Default' option, as you see below, the NAD does not maintain its Session ID after the Reauthentication process:

Some important considerations and best practices:

• Do not assign reauthentication timers to MAB endpoints. On MAB reauthentication, the switch does not re-learn the MAC address of the connected endpoint. It simply sends the previously learned MAC address to ISE.
• As a best practice, use server-based reauthentication timeouts, if using timeouts at all.
• Although using the reauthentication feature is beneficial from a security standpoint, it will add extra load on your ISE PSNs.

Dynamic Reauthorization Scheduler

Starting with ISE 3.4 Patch 1, you can strengthen access control by configuring a predefined expiration date and time for each session, effectively limiting access duration. This ensures that sessions remain active and permit authenticated actions only until the specified expiration, mitigating risks of unauthorized access due to lingering open sessions or compromised credentials. For example, consider a training lab scheduled to run from Monday through Friday at 5 PM. Using Cisco ISE’s Dynamic Reauthorization Scheduler feature, you can automatically disconnect all lab-connected endpoints precisely at 5 PM on Friday, based on the configured expiration. Once disconnected, these endpoints cannot reconnect, enabling maintenance activities such as policy updates or system adjustments.

ISE records the exact timestamp of authentication and captures the expiration date/time attributes. These attributes are stored and serve as a reference for subsequent authentication attempts. When the configured expiration time is reached, the session automatically terminates and becomes invalid. The user must then reauthenticate to establish a new session.

To set an expiration date, you must choose a string-type dictionary attribute under Authorization Profile. Please note that, this feature was written for customers wanting to use pxGrid Direct.

[Arne Bier]

Nice write up and it was about time, that this topic had a deep-dive like this. One question though - what do you mean by this: "Do not assign reauthentication timers to MAB endpoints. On MAB reauthentication, the switch does not re-learn the MAC address of the connected endpoint. It simply sends the previously learned MAC address to ISE." ?

Why would a switch need to re-learn a MAC address if the L1/L2 stays up? Are you saying that someone could have spoofed a MAC address, and therefore re-auth for MAB is a security risk? 

Re-auth for 802.1X has another pleasant side effect - if you want to keep track of some important supplicant telemetry, you will get this with every re-auth, if you enable Authentication SYSLOG to remote server - in those SYSLOG events, you can parse the output for things like

• TLS version used (e.g. to determine if it's time to disable TLS 1.0 and TLS 1.1 in ISE)
• Client Certificate "number of days until expiry" - create rules in your SIEM to send an email when clients reach critical state  

[rezaalikhani]

@Arne Bier 

To answer your question, please see the following statement from the Cisco ISE "MAC Authentication Bypass Deployment Guide" document:

I believe this recommendation is intended to reduce the load on ISE by avoiding unnecessary operations.

Your comment regarding 802.1X reauthentication is quite insightful—thank you for sharing it.