Table of Contents
- Problem Summary
- Solution
- Support
- Config Steps
- 1. Install Trusted CA Certificate & Identity Certificate on ISE.
- 2. Configure Trusted Cert in ISE to look at the Certificate Revocation List (CRL).
- 3. Install Trusted CA & Identity Certificate on Cat 9k.
- 4. Configure Network Device in ISE
- 5.Configure RADIUS servers on Cat 9k
- 6. Configure RADIUS Dynamic Authorization
- Verification
- Packet Captures RADIUS/UDP
- Packet Captures RADIUS/DTLS
- Troubleshooting
- Cat 9300 Cert Expired
- Cat 9300 Cert Revoked
- References
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.
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
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
Paste the CDP URL into the Download CRL section and enable Retrieve CRL.
Image 3. ISE Certificate Revocation List Configuration
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
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.
!
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
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.
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
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
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
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
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
References
RFC 7360 – DTLS as a Transport Layer for RADIUS
Wireshark DTLS Display Filter Reference
Troubleshooting and Enabling Debugs on ISE
RADIUS/DTLS – ISE & ThreatGrid
How to decrypt RADIUS traffic using Wireshark
Using John to Crack RADIUS Shared Secret
CMU Cert Coordination Center , MD5 vulnerable
