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 security point of view an attacker could use a hub or another device that maintains the port's link state, allowing a rogue device to be connected after the legitimate device has authenticated. Consequently, the rogue device could gain prolonged access without needing to reauthenticate. The recommended interval is based on your organization's security policies; however, some Cisco documents recommend setting this timer to at least 7200 seconds (2 hours). While reauthenticating at least every 2 hours may not completely prevent this type of attack, it would certainly make it more difficult for the attacker.

• From network efficiency perspective, there is usually no need to reauthenticate a previously authenticated endpoint that remains connected to the network. After a successful 802.1X authentication, the port remains open until the session is terminated, most typically by a physical link-down event. Because physical connectivity is continuously maintained, the authenticated endpoint remains connected to the port. In some situations, however, reauthentication can be used as de-facto 802.1X keepalive mechanism. For example, if an endpoint is connected to the port via an IP phone that is not capable of proxy EAPoL-Logoff or CDP Enhanced for Second Port Disconnect, the switch does not know when to terminate the session. By reauthenticating the session, the switch can confirm that the authenticated endpoint is still 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.

[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