RADIUS has been the de-facto protocol for Remote Access Authentication for decades. RADIUS/UDP as defined by RFC 2865 has traditionally used MD5 for authentication and integrity. Unfortunately, successful attacks on MD5 exist and there is a strong possibility that MD5 used in RADIUS may be easily reversible in the future; in the event that occurs RADIUS/UDP would be considered completely insecure.
In 2008 the Cert Coordination Center @ Carnegie Mellon University stated MD5 ‘should be considered cryptographically broken and unsuitable for further use’. However, MD5 is still widely used, even when better hashing algorithms are available like SHA(1,256,512), PBKDF2, & SCRYPT.
In recent years the industry has created several fixes to the RADIUS/UDP issue. RADIUS/DTLS is the solution Cisco has chosen to implement in Catalyst 9000 and in Cisco Identity Solutions Engine.
DTLS runs on top of UDP and is widely implemented. DTLS is based off TLS and follows TLS versioning, for example, DTLS 1.0 is based off TLS1.0, DTLS 1.2 is based off TLS 1.2 etc. RADIUS/DTLS is not an internet standard but is discussed in RFC 7360. RADIUS/DTLS provides an excellent method of authentication since it requires both Client and Server Certificates and strong encryption.
Implementing this high level of security in your network is fairly simple. Both the NAD (switch) and the Authenticator (ISE) have certificates issued from the same Issuing CA, click a couple of checkboxes in ISE, tweak the RADIUS config in the switch, and, done. In this document we show how to configure Catalyst 9000 switches to use RADIUS/DTLS to communicate with Cisco ISE.
In this Config Guide I am using:
Catalyst 9300 Switch with IOS XE 17.3(3)
ISE 3.0 Patch 2
Microsoft Windows 2019 Certificate Authority for PKI
This should also be supported on Cat 9800 controllers.
This should also be supported on ISE 2.4+.
1. Install Trusted CA Certificate & Identity Certificate on ISE.
NOTE: Please be aware, Certificates expire and they may need to be regenerated occasionally! However, since you own the PKI you have the ability to create a Certificate for the switch for several years. If you are concerned about replacing the certificate frequently, I’d suggest creating a certificate for the switch that has a validity time of several years.
4. Configure Network Device in ISE
Image 4. ISE NAD Config1
Image 5. ISE NAD Config2
5. Configure RADIUS servers on Cat 9k
Here there are a few things to note.
First we are basically configuring RADIUS servers and then putting them into AAA groups the way we normally would with RADIUS/UDP, only we are configuring them to use DTLS and not a key (shared secret).
The dtls trustpoint client needs to point to the trustpoint that was created in Step 3 of this guide.
The dtls trustpoint server needs to point to the trustpoint that was created in Step 3 of this guide.
NOTE: In this configuration the same trustpoint can be used to authenticate both the client and the server. This is because the Issuing CA that is configured in the switches trustpoint is also in ISE Trusted Certificates.
! configure terminal radius server ise1 address fqdn ise1.theglens.net dtls port 2083 dtls trustpoint client core-9300 dtls trustpoint server core-9300 dtls match-server-identity hostname ise1.theglens.net ! radius server ise2 address fqdn ise2.theglens.net dtls port 2083 dtls trustpoint client core-9300 dtls trustpoint server core-9300 dtls match-server-identity hostname ise2.theglens.net
! ! aaa group server radius ISE-RADIUS server name ise1 server name ise2 ! ! ! radius-server attribute 6 on-for-login-auth radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include ! aaa authentication dot1x default group ISE-RADIUS aaa authorization network default group ISE-RADIUS ! end !
6. Configure RADIUS Dynamic Authorization
This step allows ISE to send CoA messages to the switch.
In this step we configure the ISE PSNs as clients and we point to the same trustpoints on the switch as we used earlier.
ISE Live Logs Screen, look at the first item in the Steps section. RADIUS DTLS Handshake Started is Green and therefore is successful.
Image 6. ISE Live Log DTLS Handshake AuthC
Now lets dig a little deeper into the Live Log. Here we see all the necessary items in a TLS \ DTLS handshake Client & Server hellos, Certificate exchanges, and ciphersuite agreement.
Image 7. RADIUS DTLS Handshake Succeeded
This shows a RADIUS/UDP Live Log Event. This is only shown to display the difference between UDP & DTLS!
Image 8. RADIUS UDP AuthC Succeeded
This shows an encrypted RADIUS/ DTLS Live Log Event. Notice the first item in the Steps section calls out RADIUS Packet is Encrypted. Because the DTLS handshake was completed in the previous step all we see in this Authentication event is that the RADIUS packet is encrypted.
Image 9. RADIUS DTLS AuthC Succeeded
Packet Captures RADIUS/UDP
This capture uses the traditional MD5 hashing. This is not secure and is only being shown to display the difference between the hashed and the encrypted traffic.
Image 10. PCAP RADIUS UDP Access Request Re
Packet Captures RADIUS/DTLS
Here are some Wireshark Filters that may help with drilling down into the packet capture.
In this screen shot you can see the DTLS handshake is a bit heavy. Yes, this is one handshake. The switch sends several certificate fragments.
Image 11. PCAP RADIUS DTLS Handshake
Here you can see the DTLS version the client proposing is DTLS v1.2.
Image 12. PCAP RADIUS DTLS Handshake TLS Version
Does RADIUS/DTLS use strong encryption? Yes
Image 13. PCAP RADIUS DTLS Server Hello CipherSuite
Encrypted RADIUS Access-Request & Access-Accept
ISE is configured to keep a RADIUS/DTLS session open for 120 seconds. You can check the Idle Timeout value her
ISE > Administration > System > Settings > Protocols > RADIUS > DTLS
In this screen shot the DTLS handshake had already taken place and I filtered on just dtls.app_data. Then I ran six authentication tests at 10 second intervals. You can see that in each test there are only two packets, this is exactly what we would expect. Examine the time field, at each 10 second increment you will see two packets, the two packets we see are ACCESS-REQUEST and ACCESS-ACCEPT and they are encrypted with DTLS 1.2.
Image 14. PCAP RADIUS DTLS App Data Access Request Accept
Cat 9300 Cert Expired
As usual ISE Live Logs are the go to spot! The Live Logs show exactly what the issue is.
Show ISE Live Log – very explicit info, DTLS handshake failed
Image 15. ISE Live Log Client Cert Expired
Show C9300 Debug – nothing stands out
Cat 9300 Cert Revoked
Again ISE Live Logs are the go to spot! The Live Logs show exactly what the issue is.
I am pretty new to all things Cisco so apologies for any dumb questions or inability to grasp basic concepts. Trying to set up a cisco router, C897VA-K9, and need to assign outbound ip addresses and direct inbound traffic. outbound ip addresses: for ...
I'm connecting an interface off of a firewall onto port 41 of a 2960x running 15.0(2)EX5 with a very generic configuration: interface GigabitEthernet0/41switchport access vlan 200switchport mode access When I issue a "show mac address-t int...
Port 47 on a brand new C9400-LC-48U module is not supplying POE, it does support a network connection. "sh power inline g5/0/47" does not show any issues. It is the same as other ports on the card. We have not tried every port on the module, but the devic...