ISE Wired Supplicant CRL/OCSP Check Issue

[xxkozxx]

I'm hoping someone else may have run across this issue and can help...

I have an intermittent issue in which machines that are using wired dot1x fail to authenticate properly after being rebooted. We opened a ticket with Microsoft, as the supplicant we are using is the native supplicant. After running multiple packet captures and traces on machines that the issue is happening on, we found that the supplicant was conducting a CRL check for the servers certificate before proceeding with EAP-TLS. 

Since the default ACL on the switch does not allow for this traffic before authentication, the CRL check fails. Microsoft states that it will try for 60 seconds before logging the failure into its negative cache and move on. By that time, the auth timers have expired and it registers as "Supplicant not responding." The machine boots up and has hit the default ISE policy (in this case CWA). Once the machine is booted up, it has already cached the negative response for the CRL check and bypasses it in subsequent tries, so we can pull the network cable and plug it back in or bounce the switchport and the machine auth's with no problem.

Microsoft's workaround for this is to set a registry key to disable CRL checks for EAP-TLS:  

 PATH: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13  

 DWORD NoRevocationCheck

 Value: 0x1

This definitely works around the issue. Once we implemented the registry key, the machines having issues were able to successfully auth without fail. 

Has anyone else run across this and is there a valid way to allow these CRL checks rather than disabling it on the client?

[Colby LeMaire]

I have not run into this issue yet.  Thanks for sharing the details.

To allow the CRL checks, you would have to modify your pre-auth ACL to allow that traffic before authentication.

[xxkozxx]

Colby,

Thanks for the reply. I figured as much. The problem I have is that this seems to be intermittent. It doesn't affect all machines all the time. We first noticed it when we upgraded from Windows 10 (1803) to Windows 10 (1809) and had a slew of machines that didn't properly auth on the reboots. 

I'm also curious to know if its possible that timers could be involved. Apparently Windows times out on the CRL check after 60 seconds but then goes into a block period. So when the switch tries to send another EAP-TLS session establishment message, the machine ignores it, thus creating the "Supplicant not responding" condition. 

I'd also be curious to know if there is a way to set the preauth acl's to use DNS to look up these entries. I hesitate to put the IP of a public CRL server in the preauth ACL in the event that it changes or differs depending on regions that a client might be in. Thoughts?

[Colby LeMaire]

I don't think adjusting timers on the switch side will help much.  It seems as though the Windows machine is blocking after the CRL failure anyway.  There may be some adjustments on the client side that could help but you already have that information from Microsoft.  You can push those registry changes out using GPO.

As far as using DNS for pre-auth ACL, that is not available on the switches.  You can do that on the WLC with URL-based ACL's.

[xxkozxx]

Yes. You can push the Registry key out via GPO, Appsense or whatever machine template software is in use in your environment. That's how we accomplished it. I will test putting the CRL / OCSP server ip in the pre-auth ACL and see if that works. Thanks for the feedback. I'll let you know what I find...

[xxkozxx]

Quick Update: Placing the IP Address of the CRL / OCSP Server in the Pre-auth ACL fixes the problem.

However, it leads to another problem. CA's may or may not be load balanced. Such is the case with public CA's such as Entrust, Digicert and the like. So not being able to do FQDN-based rules in the switch is not a viable solution as the IP's may change from lookup to lookup (based on the TTL's of course). 

One thought would be OCSP Stapling?

Does ISE even support this?

Does 802.1x even support it... 

The only other solution I could possibly think of to negate this is to set the pre-auth ACL to allow port 80 traffic to non RFC1918 address spaces, but this would mean that clients would have internet access (at least http) unauthenticated which I don't believe is a good idea either. 

So its either, bypass CRL / OCSP checks on the client or allow web traffic on an unauthenticated port. Neither option seems all that great to me.