New phones failing to authenticate to APs with ISE using PEAP (TLS Handshake failure)

[CaptJaneway]

We started experiencing an issue where newer phones, specifically Samsung S10s and Google Pixels are unable to connect to our wireless APs using PEAP.  After performing packet captures, we found that the Samsung/Pixel phones are sending a a client hello message using TLSv1.0.  Our ISE configuration only permits handshakes on TLS1.2.  When comparing this capture to the phones that connect successfully, we see that the unsuccessful phones show a TLSv1 Record Layer but TLS1.2 under the Handshake Protocol:Client Hello.  The successful phones show TLS1.2 overall but it says TLS 1.0 under the record layer drop down just like the unsuccessful capture.  We would like to avoid downgrading our ISE security settings but would like to know if there are any suggestions on solutions or alternative methods.  It is hard to believe that this is an issue where these new phones are not capable with TLS1.2 handshake authentication.  Could we be running into a bug with ISE?  We are currently using ISE version 2.4.

[thomas]

Hey Captain,

What version of Android are you experiencing TLS 1.0 with?

What is the error you are seeing on ISE when these devices fail to speak securely with TLS 1.2?

If you did want to sacrifice security for compatibility, ISE does offers the ability to allow TLS 1.0 and/or 1.1 I believe in version 2.4 and later:

[CaptJaneway]

Hi Thomas.

The new Samsung phone is on Android version 10.

The error in ISE is Failure Reason: 12309 PEAP handshake failed.

Under Other Attributes I see these OpenSSL messages and the steps below:

OpenSSLErrorMessage	SSL alert: code=0x228=552 ; source=local ; type=fatal ; message="handshake failure"
OpenSSLErrorStack	16649:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1459:

Steps

	11001	Received RADIUS Access-Request
	11017	RADIUS created a new session
	11117	Generated a new session ID
	15049	Evaluating Policy Group
	15008	Evaluating Service Selection Policy
	15048	Queried PIP - Normalised Radius.RadiusFlowType
	15048	Queried PIP - Radius.Called-Station-ID
	15048	Queried PIP - DEVICE.Device Type
	11507	Extracted EAP-Response/Identity
	12300	Prepared EAP-Request proposing PEAP with challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12302	Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated
	12319	Successfully negotiated PEAP version 1
	12800	Extracted first TLS record; TLS handshake started
	12805	Extracted TLS ClientHello message
	12814	Prepared TLS Alert message
	12817	TLS handshake failed
	12817	TLS handshake failed
	12309	PEAP handshake failed
	12307	PEAP authentication failed
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	5411	Supplicant stopped responding to ISE ( Step latency=120001 ms)

Lastly, I have seen that we can enable those lower TLS security settings in 2.4 but it looks like it forces ISE to perform a restart.  Is this true or does it just restart a service in ISE?  In addition, how long would a restart typically take?  I'm also understanding that if we allow TLS1.0/1.1, ISE will always negotiate on the strongest security cipher first.  Is that correct? 

[hslai]

Enabling TLS 1.0/1.1 or other security settings do not require ISE restart.

The time taken to restart the ISE services varies. For example, it may take about 5 minutes if an ISE VM has fast I/O, or take 10 ~ 20 minutes if slow I/O or other contention.

Usually newer Android releases will support better security. I would suggest to take a packet capture and check cipher suites sent by the client.

[CaptJaneway]

Thanks for the info about restarting the ISE service. If we can resolve this issue without having to do this and setting ISE to use TLS1.0/1.1, I would prefer that.  Can anyone confirm my question about if ISE will always negotiate with the highest security algorithm first before it allows the weaker security settings?

Also, I submitted a post to the official android forums but haven't received any feedback on it.  I'm wondering why we aren't hearing of more users having this same issue often.  Samsung and Pixel are some of the most popular phones.  Are other businesses using other authentication deployment models where they just don't run into this issue?  PEAP is pretty standard for wireless authentication.

Here is the same packet capture but with the cipher suites info expanded.

SAMSUMG(not working)LG(connects successfully)

[CaptJaneway · Accepted solution]

I was able to resolve this with the help of Cisco TAC.  The issue was that the setting "Allow ECDHE-RSA ciphers" was not enabled.  The newer Samsung phones are providing a smaller amount of cipher suites it agrees upon and most of them are stronger suites with ECDHE.  The capture was being seen as TLS1.0 but it was because there were no matching ciphers to complete the handshake.  Enabling this also didn't require a restart.  All my users are happy now and we are using stronger security ciphers.  Hope this helps anybody else who runs into this issue.