802.1x authentication and X509 certificate question

[Ernest.Brant1]

Hello

Can someone kindly help me with the following question, 

First off I am a Windows Server/PKI/AD etc guy rather than CISCO,  although I do hold a CCNA :)

I look after the PKI at my company and will be working with the CISCO team who are introducing CISCO ISE, we will be using X509 certs on the supplicants (Windows desktops/laptops primarily)  

What I  want to know is something quite basic, but I have not seen it written down anywhere 

Question 1:

First off I assume it is the AAA Server (ISE) is the entity that checks the supplicants X509 certificate, rather than the AP (access point e.g. wireless router)? is that correct

Question 2:

As the supplicants X509 certificate is public (e.g. it is not secured and anyone can request it as it normal) I assume the AAA server must encrypt a value (random number for example) with the supplicants public key (from the X509 cert) then send this value to the supplicant whereby the supplicant decrypts it with its private key (which no one else has, as normal). Then the supplicant encrypts the same value with the AAA Servers public key (held in advertised AAA Servers X509 cert)    send this back to the AAA Server and once the AAA server decrypts it (with its private key) if the value matches with the value originally sent to the supplicant then the AAA server can continue with authentication etc.

Is the above assumption correct?

if the above is correct, does ISE always act like this or can you lower the security and just get the ISE server to check if it trusts the cert issuer (and CRL is OK) of the supplicants X509 cert and not bother to send the encrypted packet as above (but this of course would not guarantee supplicant-1 is actually supplicant-1)

Thanks very much in advance

Ernie

[ajc · Accepted solution]

Answers:

1.-Yes, ISE checks the certificate presented by the enduser device (supplicant) against its internal TRUSTED Certificate Authority DB for which you need to import into ISE the root and intermediate certs in case you are using not public CA Servers (that is my case for EAP-TLS) like Verisign, Entrust, etc. UNFORTUNATELY, ISE only allows you to have 1 cert for EAP usage from the list (PEAP, EAP-TLS, etc) so that means you CANNOT have EAP-TLS and PEAP running on different SSID's. The problem now becomes that Entrust for example is using an intermediate called Entrust L1K that is not included into the Trusted CA for Apple devices and Win 7. This causes a untrusted certificate warning for IPADs so you must trust the certificate being presented but for Win 7 devices the PEAP TLS Tunnel setup fails so the connection cannot be established unless you uncheck "VALIDATE SERVER" on the Win 7 profile for that SSID.

2.-you can create a condition that validates the cert issuer but the allowed protocol is EAP-TLS or PEAP so the actual process for any of those protocols based on my understanding is actually perform. For example, on PEAP, the TLS Tunnel setup is the 1st step so once the secured tunnel is configured then the Inner MSChapv2 + EAPOL are performed and finally the data travels through the tunnel

[Ernest.Brant1]

Hello Abraham

Thank you very much for taking the time to reply with a comprehensive answer :) 

Ernie