Cisco AP Dot1x using LSC

[PSM]

Hello,

This is related to AP dot1x authentication using LSC. We are trying to implement Dot1x using EAPTLS on access points. In our test setup we successfully enrolled certificate on access point using Enterprise PKI server.
But when we tried to use LSC certificate for EAPTLS on access point, access point is not able to trust Radius server certificate. Radius server(ISE) is using public CA certificate and not a enterprise PKI certificate.
Upon investigating we found weird limitations implemented by Cisco.
There is no way to import and trust a CA other then the CA who signed AP LSC certificate. So in our scenario either we install same Public CA certificates on 10K accesspoints and go bankrupt or use enterprise PKI certificate on ISE which will cause issue to BYOD devices as they don't have enterprise CA in their truststore.

As far as we know validation of Radius server cert is optional in RFC and there should always be an option to disable Radius server cert validation. Most endpoints either don't validate Radius server CA or they have an option to disable. But Cisco AP does not have any command for that.

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9100-access-points/221127-configure-locally-significant-certificat.html

"The Authentication occurs between the AP (which is acting as the supplicant) and the RADIUS server. Both must trust each other certificate. The only way to have the AP trust the RADIUS server certificate is to have the RADIUS server use a certici ate issued by the SCEP CA which issued the AP certificate as well."

Wants suggestions and your views on this topic.

[Arne Bier]

You are correct in saying that ISE only supports a single EAP System Certificate. That is an unfortunate product limitation especially in complex cases like yours. Others have lamented this fact too, and pointed out that Aruba Clearpass supports multiple EAP certificates.

What solutions are there? You might not like this suggestion, but for BYOD, you could rather use an MDM, or if you really want to use ISE for this, then perhaps create a standalone ISE node just for this purpose. The standalone ISE node can be your BYOD onboarding solution (where the public CA signed EAP cert is used). Of course this would add some cost for the additional ISE VM (or appliance).

Meanwhile, the other production ISE platform for your Wired/Wireless 802.1X Non-BYOD) and TACACS can use the Corporate PKI for the system certs.  That should allow you then to enrol those Cisco APs using SCEP.

I don't see how these two solutions can co-exist in a single ISE deployment, unless you can disable the "trust server cert" option in client devices - which is a bad idea and defeats the purpose of setting up a secure TLS connection.  If you want to close your eyes and imagine that you will never be subjected to a MITM attack, then you can try disabling this feature, and if successful, your APs will not care what ISE EAP system cert you are using. Bad idea. 

[Arne Bier]

The other solution might be to have a dual SSID BYOD solution - this means having an open SSID with a guest portal to onboard the devices. The devices then get the 802.1X profile and certs for your corporate SSID.  The single SSID BYOD solution is nice, but it requires the ISE System Cert to be a public signed one.

[PSM]

Hi @Arne Bier thanks for suggestions. In my opinion disabling Server cert validation on client side in this case is not that bad in my opinion. Here goal of implementing Dot1x is to protect the network and not the endpoint itself. Have not seen any organization which is stopping their PCs to connect on home/public network. Then validating Server cert during Dot1x in corporate network does not make much sense. Most of the organizations avoid pain of enabling dot1x for Access points and Cisco also promotes profiling to do authorization of access point and other non PC clients endpoints. MAB/profiling are actually increasing risk( debatable though) instead of reducing the risk. But if we use Dot1x using cert and validate if client is having valid cert, we at least protect the network in best possible way.     

[Arne Bier]

You’re right about MAB. The clue is in the word “bypass” and it’s indeed a non secure method of network auth. But unavoidable for devices that don’t have a supplicant.

As for not trusting the radius server cert, I still disagree with you. Technically of course, as a client you can choose to ignore the check. And that’s what people do when in lab scenarios or when security is not a concern to them. But in production it’s foolish to do that because a MITM could intercept the radius traffic and you wouldn’t know, unless you performed the server validation check. Putting the right certs and checks on devices seems like one of the hardest things for people to get their heads around. It’s advisable not to take short cuts. It’s really not that hard to get this right.

[PSM]

Technically I agree it is better to validate Server cert. But in reality many endpoints IP phones, cameras, don't even have option to validate server side cert.

[Arne Bier]

Yeah, that is a good point - quite annoying that the developers of such solutions don't both to be a little bit more thorough.