cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Configuring RADIUS over DTLS with Cat9k and ISE 3.0

1777
Views
30
Helpful
2
Comments

Table of Contents

Problem Summary

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.

 

Solution

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.

 

Support

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+.

 

 

Config Steps

1. Install Trusted CA Certificate & Identity Certificate on ISE.

Please see this link

 

2. Configure Trusted Cert in ISE to look at the Certificate Revocation List (CRL).

CRLs are a block list and are used by ISE to verify that a certificate is valid and trustworthy. CRLs are critical to the security of the PKI as a whole!

 

First, find the CRL Distribution Point in the Switch's trustpoint.  Run the following command and look for the CRL Distribution Point. Both the switch and ISE need to be able to access this URL.

show crypto pki certificates trustpoint

 

Image 1. Switch Certificate Info CRL CDP

Switch Certificate Info CRL CDP.png

 

Now Go into ISE Trusted Certs, Edit, the CA that issued the Switch's Identity Certificate.

ISE > Administration > System > Certificates > Certificate Management > Trusted Certificates

 

Image 2. ISE Trusted Certificates

ISE Trusted Certificates.png

 

 

 

 

Paste the CDP URL into the Download CRL section and enable Retrieve CRL.

 

Image 3. ISE Certificate Revocation List Configuration

ISE Certificate Revocation List Configuration.png

 

 

 

3. Install Trusted CA & Identity Certificate on Cat 9k.

 Here is a link to a document I wrote.

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

ISE NAD Config1.png

 

Image 5. ISE NAD Config2

ISE NAD Config2.png

 

 

 

 

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.

 

!
configure terminal
aaa server radius dynamic-author
  client ise1.theglens.net dtls client-tp core-9300 server-tp core-9300
client ise2.theglens.net dtls client-tp core-9300 server-tp core-9300
end
!

 

  

 

Verification

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

ISE Live Log DTLS Handshake AuthC.png

 

 

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

RADIUS DTLS Handshake Succeeded.png

 

 

 

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

RADIUS UDP AuthC Succeeded.jpg

 

 

 

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

RADIUS DTLS AuthC Succeeded.png

 

 

 

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

PCAP RADIUS UDP Access Request Reject.png

 

 

Packet Captures RADIUS/DTLS

Here are some Wireshark Filters that may help with drilling down into the packet capture.

 

dtls.app_data

dtls.handshake

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

PCAP RADIUS DTLS Handshake.png

 

 

 

dtls.handshake.version

Here you can see the DTLS version the client proposing is DTLS v1.2.

 

Image 12. PCAP RADIUS DTLS Handshake TLS Version

PCAP RADIUS DTLS Handshake TLS Version.png

 

Does RADIUS/DTLS use strong encryption? Yes

 

Image 13. PCAP RADIUS DTLS Server Hello CipherSuite

PCAP RADIUS DTLS Server Hello CipherSuite.png

 

 

 

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

PCAP RADIUS DTLS App Data Access Request Accept.png

 

 

 

Troubleshooting

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

ISE Live Log Client Cert Expired.png

 

 

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.

 

Image 16. ISE RADIUS DTLS Failed Cert Revoked

ISE RADIUS DTLS Failed Cert Revoked.png

 

 

References

ISE 3.0 Config Guide

RFC 7360 – DTLS as a Transport Layer for RADIUS

Wireshark DTLS Display Filter Reference

Troubleshooting and Enabling Debugs on ISE

Configuring RADIUS over DTLS

Configuring RadSec

RADIUS/DTLS – ISE & ThreatGrid

RADSEC TCP

How to decrypt RADIUS traffic using Wireshark

Using John to Crack RADIUS Shared Secret

CMU Cert Coordination Center ,  MD5 vulnerable

 

Comments
Marvin Rhoads
VIP Community Legend

Thanks for sharing @Tim Glen !

Tim Glen
Cisco Employee

You got it @Marvin Rhoads  !