How to disable TLS 1.0 in ISE when DNAC is used to provision devices?

[Arne Bier]

Hello

I'm sure all of us would love to disable TLS 1.0/1.1 support in ISE to imrove security, but there's always something in the network that seems to make this dream impossible.  I discovered today that CTS uses EAP-FAST under the covers, and on the 3850 that I was capturing the traffic, it was using TLS 1.0 in the TLS Handshake Client Hello.  I never wanted CTS and I have no need for it, but because all the devices are provisioned with the latest version of DNAC, we get CTS whether we like it or not.

• Is it possible to disable the CTS stuff when provisioning network devices? 
• Is there a TLS 1.2 version of EAP-FAST for CTS ?  Some of our network switches are 3850 and 16.12 is the latest IOS-XE.

I read in some Community post that CTS can be done via REST API but you need IOS-XE 17.X - even if I had a network with that version of code, does DNAC do all the hard work, and then no longer uses EAP-FAST ?

thanks for any advice

[marce1000]

        - FYI : https://www.cisco.com/c/en/us/td/docs/security/ise/3-3/release_notes/b_ise_33_RN.html#c_disable_ciphers
                  Ref : https://www.cisco.com/c/en/us/td/docs/security/ise/3-3/admin_guide/b_ise_admin_3_3/b_ISE_admin_33_segmentation.html#t_security_settings_33
                          >...TLS 1.2 is the latest supported TLS version when EAP-TLS is used as the inner method for EAP-FAST, TEAP, and PEAP protocols.

 M.

[Arne Bier]

Yeah ISE 3.3 is not the problem. TLS is negotiated by both sides of the connection. My concern is with DNAC because it's forcing EAP-FAST on me whether I like it or not. Without EAP-FAST in the mix I could easily disable TLS 1.0

And there are various versions of IOS/IOS-XE/AireOS that still use older versions of TLS - that is the issue. People should really think twice before disabling TLS 1.0

[Greg Gibbs · Accepted solution]

@Arne Bier , ISE 3.4 added an enhancement for PAC-less RADIUS communications for TrustSec.

I would expect the plan for Catalyst Center will be to implement this method to mitigate issues around the requirement for TLS 1.0 in the EAP-FAST PAC communication.
It is only supported on network devices with IOS-XE version 17.15.1 or higher so I realise that doesn't help with your 3850s, but that platform reaches End of Support next year so I don't think there are any options with those.

[Arne Bier]

Hi @Greg Gibbs 

I'm not up-to-speed on the latest developments in CTS, so perhaps you can explain this in English for me. The IOS-XE 17.15.1 CTS Guide has this paragraph that seems to contradict itself (it says you don't need PAC, and then it talks about how the PAC is created)

EAP-FAST is still involved, but which version?  I am confused.

[Greg Gibbs]

Hi @Arne Bier. I agree that is confusing to talk about the PAC in the PAC-less section. I would suggest submitting feedback on that doc (I have also done so).

To be honest, the EAP-FAST PAC stuff has always been difficult for me to understand. All I can say, is that the PAC-less feature simplifies the communication by allowing the device and ISE to negotiate the connection by agreeing to use pacless with a shared secret instead. This not only removes the need for the PAC creation/negotiation, but removes multiple steps in the handshake.

I saw this basic diagram internally that shows the updated negotiation.

[Arne Bier]

One good thing with using a PAC instead of a static shared secret in RADIUS server definitions, is that it makes decoding the user-password - I verified this by trying to decode a PAP auth password in Wireshark - not sure how strong the encryption is, but it keeps the wolves from the door a bit. 

I read elsewhere that in the wireless world, Cisco has updated the EAP-FAST of the AP authentication stack to use TLS 1.2.  But no mention of whether this will ever filter across all the IOS versions. Perhaps enough customer complaints have finally led to PAC-less.

I am trying to get my hands on 8000v so I can test this in the lab. IOS-XE 17.15.1 + ISE 3.4