cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3597
Views
18
Helpful
5
Replies

TrustSec & ISE - NDAC & TLS Handshake

dmorello74
Level 1
Level 1

I am configuring TrustSec on an ISE node & Catalyst 6807 Switch. I configured NDAC & EAP-FAST on the Catalyst 6807 Switch and the ISE node so they can create a secure RADIUS channel between them for the TrustSec solution.  TLS 1.0 is disabled on the ISE node, and when the Catalyst 6807 Switch tries to perform the TLS handshake with the ISE node, TLS negotiation fails.  The RADIUS Live Logs on the ISE node show the following failure reason:

 

"Client requested TLSv1.0 or TLSv1.1 that is not allowed"

 

It seems the Catalyst 6807 Switch (RADIUS Client) is sending a TLS Client Hello message with support for only TLS version 1.0.  Is it possible to configure the Catalyst 6807 Switch to send a TLS Client Hello message with support for TLS version 1.1 during the TLS handshake with the ISE node?  I have a requirement in my Customer’s network environment where TLS version 1.0 isn't enabled.  I would greatly appreciate any feedback. 

1 Accepted Solution

Accepted Solutions

kthumula
Cisco Employee
Cisco Employee

This PAC provisioning uses TLS 1.0 since the network device uses TLS 1.0 for the PAC requests. We are working towards a solution to remove the requirement for PAC provisioning for SGACL/Environmental data from the network device. The main reason is today we are using a pre-shared key which would be derived from the PAC and even with a very long pre-shared key of the PAC we are not adding any real security to the RADIUS request.  Hence we are coming with a PAC-less solution which should be out some time this year. BTW we always recommend DTLS for real security of the RADIUS transactions.

 

View solution in original post

5 Replies 5

kthumula
Cisco Employee
Cisco Employee

This PAC provisioning uses TLS 1.0 since the network device uses TLS 1.0 for the PAC requests. We are working towards a solution to remove the requirement for PAC provisioning for SGACL/Environmental data from the network device. The main reason is today we are using a pre-shared key which would be derived from the PAC and even with a very long pre-shared key of the PAC we are not adding any real security to the RADIUS request.  Hence we are coming with a PAC-less solution which should be out some time this year. BTW we always recommend DTLS for real security of the RADIUS transactions.

 

Hello, has a PAC-less solution been released for SGACL/Env data as noted in the response? I don't know of any and the response was posted over 2 years ago? All my network devices are also attempting to negotiate TLS 1.0, and thus failing when TLS 1.0 and TLS 1.1 are disabled.

Yes, ISE 2.7 and 3.0 support REST API based pac/SGACL/Environment data provisioning dropping the need for TLS 1.0. This document outlines it and it is available on 17.1+ IOS-XE software. 

https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/switches/lan/catalyst9500/software/release/17-3/configuration_guide/cts/b_173_cts_9500_cg/b_173_cts_9500_cg_chapter_01.html.xml

Thank you Damien! I appreciate your help very much.

So from this information, am I correct in my understanding that if my installation includes ISE v2.6 operating as a TrustSec server, with my switches operating as TrustSec clients having SGACL/Environment data provisioned via PAC, that I'll not be able to disable TLS1.0/1.1 without breaking my CTS domain?

Thanks again for your help.

That's correct, you won't be able to disable TLS 1.0 until all of your TrustSec enabled NADs are running on IOS-XE 17.x and reconfigured to leverage the Rest API functionality. Disabling TLS 1.0 with the traditional TrustSec provisioning method will break the capability. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: