EAP certificate validation with multiple ISE nodes?

[MatteoComisso50310]

Hi,

we are building a large ISE cluster with 50 PSNs. We'll use it for WI-FI authentication in a corporate environment with managed laptops. Do we really need to put all 50 PSNs FQDNs in the SAN (or a wildcard?) as per documentation.

Cisco Identity Services Engine Administrator Guide, Release 3.1 - Basic Setup [Cisco Identity Services Engine] - Cisco

I can understand how that is needed for a web server, but for WI-FI client authentication? How can the client validate the server hostname if it has not even connected the network yet?

Thanks

[Rob Ingram]

@MatteoComisso50310 no you don't need to define all 50 PSN in the SAN. You can use a wildcard for the EAP Certificate. For compatibilty, define the wildcard values into the Subject Alterative Name (SAN) field instead of the subject. Refer to this guide for more information - https://community.cisco.com/t5/security-knowledge-base/how-to-implement-digital-certificates-in-ise/ta-p/3630897#toc-hId-156163470

[MatteoComisso50310]

Hi,

thanks for your reply. I know I "can" configure a wildcard FQDN in the SAN, but I'm trying to understand why. I mean: we are planning on using ISE for EAP authentication (EAP-TLS, PEAP, EAPoL) and I can't really understand why those client should care about the CN/SAN part. They will only be able to validate the CA, unless explicitly configured to only authenticate against specific FQDNs. Or? Am I wrong?

Thanks

[Rob Ingram]

@MatteoComisso50310 when each ISE PSN has a unique certificate, when authenticating to a different PSN some mobile device OS (iOS) request to validate the certificate of each PSN (when re-authenticated is by a different PSN). To work around this you can use the same certificate for all PSN, using either Wildcard/WildSAN or MultiSAN.

From the link I previously provided:-

Refer to BRKSEC-2234 for more information

[MatteoComisso50310]

Hi,

that is clear, but I still don't understand the authentication. Let's loog at this from the client perspective.

I'm a client, I'm connecting a Wi-Fi network, and I'm getting presented with a certificate. I can validate many parts of it, like the CA, if it's expired, and so on. But how can I validate, as a client not yet connected to the network, the PSN FQDN to check it matches the CN or the SAN of the certificate? I'd say the client can't validate that part, hence for EAP purposes, it's useless.

The wildcard certificate is a liability from a security perspective: it requires you to handle both the key and the certificate. It's way better to have the PSNs to generate the CSR so that the key never leaves the machine. For this reason I'm trying to understand IF the CN/SAN is really important in EAP, and so far it looks like it isn't.

Thanks

[Scott Fella]

We can't use a wildcard were I work as that is not allowed, but I have like 60+ fqdn in the SAN and using a simple CN name that points to the PAN.  The nodes doing the authentication sends its cert with its fqdn, that is what the client has to validate.  Another reason you make sure the endpoints trust the root CA and intermediate CA that ISE uses.  Some devices only care about the root and there is no option to add an intermediate, but that is okay as long as the cn, the fqdn of the device in the SAN can be resolved by DNS.  I use openssl cnf file to help generate the CSR with all the SAN's and also for the CIMC as we have a majority of appliances.  It's quick that way.  

[MatteoComisso50310]

Hi Scott,

very honored to have you involved in this thread

"The nodes doing the authentication sends its cert with its fqdn" -> Are you sure? I can't find this mentioned in RFC 2716: PPP EAP TLS Authentication Protocol nor in RFC 3748: Extensible Authentication Protocol (EAP)

[Scott Fella]

I'm sure.. the wireless controller, ap, or switch sends radius to a defined server you configure to use, either that being a VIP or the ip of a node.  So that node has to send its cert, the client has to review that and then the client sends its cert for the ISE node to validate.  
https://www.securew2.com/blog/802-1x-eap-tls-authentication-flow-explained

[MatteoComisso50310]

Hi,

this is absolutely clear. But "certificate validation" involves different tasks:

1. CA/chain validation
2. validity period validation
3. CN/SAN validation

The authentication server is sending the supplicant it's certificate, and the supplicant validates:

1. the chain against the local trusted sources (root/intermediate CAs)
2. the validity period against the local time/clock
3. the CN/SAN against...

If your statement "The nodes doing the authentication sends its cert with its fqdn" means "inside the certificate CN/SAN" then what the supplicant validate it against? Else, there should be a step in the process where the authentication station is sending its FQDN before sending its certificate, but I don't see that step.

Regards

[Scott Fella]

You need to search that online and you will find various documentation on the steps for EAP-TLS. During EAP-TLS, a device validates a RADIUS certificate through a series of checks to ensure mutual authentication and secure communication. The process involves verifying the server's certificate to establish a trusted connection What you are asking are steps that are embedded into steps in a lot of documentation where TLS communications happen. There are more steps, but again, you can do your research online and put it all together.  The device certificate has the FQDN of the device, I really think you are looking too deep into this.  

[MatteoComisso50310]

Hi Scott,

thanks again for your feedback. That is exactly what I've done, and I've not been able to find a single proof that the supplicant can validate the CN/SAN part of the certificate during an EAP authentication unless explicitly configured in the supplicant configuration. With MS Windows that can be done by configuring this part here: 

I don't have a LAB environment to test this, but I might do it in the future to validate that there is no CN/SAN validation during EAP authentication, hence there is no need to decrease the overall infrastructure security by issuing a wildcard certificate if the certificate is only used for EAP.

Regards,

Matteo

[Scott Fella]

That is correct, you can or don't have to populate that field.  As long as the client is trusting the root CA ISE uses for EAP, then that is all you need. Same for ISE to trust what the client is providing.  Some clients like mobile devices allow you to "Do Not Validate Server Certificate" which means you don't have to have the ISE root CA in the client device, similar to the screen shot you have and the field all the way on the top.