ClearPass Radsec w/ EST
While some products have supported Radsec for some time, it has not always been as straight forward as some would like. It would involve intense command line configuration, overcomplicated certificate imports, and hacky configs. So far, the implementation with ClearPass along with Aruba-branded switches is the easiest process. While this may seem obvious with the same vendor, as an implementor, it does not always play out like that. Vendors often buy IP of another company and things just don't mesh.
Hence, this guide to walk you through implementing Radsec using ClearPass with EST (Enrollment over Secure Transport) with an Aruba AOS-CX switch. Radsec definitely does not require EST, but it ensures that you know the Radsec cert is always coming from a trusted source, and it reduces some of the administrative overhead of certificate issuance.
To be clear, EST adds a level of convenience for the administrator to avoid having to add a certificate to each switch or other NAD. You can always manually import a certificate on the NAD to use for Radsec if you don't have access to an EST server. So, most of these steps below can be used. . .just skip the EST profile steps.
AOS-CX switches are the newest line from HPE/Aruba. They offer the latest switching technology and ASICS. While this guide covers this model of switch the same technology and workflow can be applied to the legacy AOS-S (Procurve) switches as well. However, the commands will definitely differ.
What is Radsec?
At the highest level, Radsec is RADIUS (inner and outer authentication method) within a TLS tunnel. As you will see below RADIUS is often associated, perhaps naively, with security just because it is RADIUS. While this is partly true, and definitely better than a passphrase-enabled network, it does not tell the whole story. RADIUS, and perhaps more importantly, the authentication methods used with RADIUS have their own sets of issues. Radsec helps solve the security shortcomings by wrapping these "insecure" protocols and frameworks within a TLS tunnel.
Why do we need Radsec?
Would you be surprised that some of your RADIUS traffic is sent in plaintext? Your username, on a Windows client, by default is sent in plaintext in an initial ACCESS-REQUEST. Did I hear you say "Well, the rest of the traffic is encrypted by the RADIUS shared secret so at least the password is protected."? Well, you are correct. However, like most credentials, the shared secret is easily snatched by social engineering, priv-esc, brute force, rogue actors, bad RBAC, etc. Now, someone has your RADIUS traffic and a username, what else can they get? Maybe you're still saying "Well, that's just layer 2 traffic, Z." Well, not exactly. Now they have access to about everything. These seemingly harmless bits of information are enough to grab your MS-MPPE-Recv-Key from an ACCESS-ACCEPT packet.
Now, we can decrypt all wireless packets on the SSID with a little math and bad things happen from there.
Here is very thorough article on how a potential attack against an 802.1X network could happen: https://wifininjas.net/2019/08/23/wn-blog-012-can-you-crack-802-1x-wpa2-enterprise-wireless-data/
Continuing: Why do we need Radsec?
Firstly, Radsec uses TLS to establish a connection from the NAD to the RADIUS server. So, this immediately rules out the idea of someone intercepting the RADIUS shared secret. In fact, the RADIUS shared secret is well-known and well-documented in RFC6614 as "radsec". So, the wildly insecure PEAPv0 protocol can be used securely. Weird, right? We're now inside of a TLS tunnel. So, we can pass credentials without the worry of some random threat actor having the shared secret or the MS-MPPE-KEY. FTR- This is the same technology that protects your banking, shopping, and your favorite social media site.
Also worth noting is the fact that it is quite difficult to configure the authenticator and authentication server improperly or insecurely. Mutual authentication forces you to put the right pieces in place to get the Radsec tunnel established.
With that out of the way, let's move on to configuring this thing. The guide is very long winded, but it is imperative that the steps are completed correctly to not open yourself open to a potentially unnecessary attack vector.
Enable Radsec for the device in CPPM
Enable Radsec on device in CPPM.
Create CA in Clearpass or enable EST
If you are already using Clearpass OnBoard, you can enable EST by ticking the box under the "Edit" screen. For my lab I created a Root CA.
In my case, I had to adjust the URL to include the FQDN. Make note of the EST URL you will need this later.
Change EST Auth method to your choosing. Preferring an username / password over a challenge password allows you to use a proper Identity Provider (IdP).
https://Clearpass01/.well-known/est/ca:25 -> https://Clearpass01.fqdn.com/.well-known/est/ca:25
Create an user to authenticate the switch against CPPM.
Here I used the guest repository, which is an awful idea in production. You should use a true IdP such as Active Directory, etc.
This is needed because when the device reaches out to enroll using a username and password the credentials need to be verified. You will need a service to handle this request which will be built in the next step.
Create a service in CPPM to handle authentication.
You will need a IdP with a user to allow authentication for EST.
I used the simplest possible service here for demostrative purposes. Again, use a different IdP and add custom rules.
Enable Radsec for CPPM definition on network device.
NOTE: The important piece here is the "tls" keyword. Any configuration after the tls keyword is optional.
radius-server host clearpass.fqdn.com tls
Add the signing certificate for your EST server to NAD.
Add signing CA of CPPM's HTTPS certificate to the switch. In my case my cert is a wildcard with an intermediate certificate and a root certificate. The one needed is the Intermediate (Signing) certificate. (PEM format needed)
crypto pki ta-profile star_fqdn_com_int
ta-certificate import terminal
(paste in PEM certificate)
If there is no new line character add one by hitting ENTER
CNTRL-D
Open your certificate and view the trust chain to find the intermediate certificate.
Create EST Profile on your switch.
Below is the bare necessity.
You can also add arbitrary labels, reenrollment-lead-time, etc.
Make sure you adjust the VRF and URL appropriately. The URL can be the URL we copied earlier where we added the EST certificate. However, you can also use arbitrary labels to fill in the "/ca:xx" portion.
EST is setup in a way that new enrollment requests can be received by a different server endpoint than reenrollment requests. That is where the arbitrary labels come into play.
crypto pki est-profile RADSEC_EST
url https://Clearpass01.fqdn.com/.well-known/est/ca:25
vrf default
user <yourUserName> password plaintext <yourPW>
wr me
Create CSR for switch and attempt enrollment.
This is where you will set the attributes of your CSR (Certificate Signing Request). While this is very straightforward, I wish they would make this more fluid, so you don't have to hit enter. It would make automation a bit easier. Although, for automation you can import the certificate via TFTP.
When you issue the enroll command you will reference the EST profile we created earlier so the switch knows where and how to send the request.
crypto pki certificate RADSEC
subject common-name Office6300.fqdn.com country US locality Town org HomeNet state TN org-unit LAB
enroll est-profile RADSEC_EST
You are enrolling a certificate with the following attributes:
Subject: C=US, ST=TN, L=Town, OU=LAB, O=HomeNet,
CN=Office6300.fqdn.com
Key Type: RSA (2048)
Continue (y/n)? y
View the status of the request:
show crypto pki certificate RADSEC
Set the newly enrolled certificate to the Radsec application on the NAD.
This tells the switch to use the newly enrolled certificate for the application specified. In our case, Radsec.
crypto pki application Radsec-client certificate RADSEC
At this point Radsec implementation is almost completed. However, there is a good chance that CPPM does not trust the certificate that the switch is presenting, or the switch does not trust the certificate that CPPM is presenting. We need mutual trust. Let's take a look at the certificates on the CPPM side first.
As you can see the certificate that CPPM is presenting to the NAD is not trusted by the switch (I'm assuming you're not using the same certificate for HTTPS and Radsec). We need to add the signing CA of CPPM's Radsec certificate to the switch. In this case the certificate in the screenshot is signed by a root CA without an intermediate CA. So, I'm adding the root CA to the trust store on the switch.
We can use the same process as above when we added the signing certificate for the EST profile.
crypto pki ta-profile domain_tld_root
ta-certificate import terminal
(paste in PEM certificate)
If there is no new line character add one by hitting ENTER
CNTRL-D
Establish Switch Trust
Now that the switch trusts CPPM's Radsec certificate. We need to make CPPM trust the certificate that the switch is presenting. In our case that is from our CPPM OnBoard CA.
To find the signing certificate authority, navigate to OnBoard -> Certificate Authorities -> Select your EST-enabled CA -> Click Trust Chain -> Copy the name of the root CA name.
Copy the Issued To name and set it aside.
SIDEBAR:
I'm assuming a lot of things here. Namely, that you are following this guide explicitly. There are a lot of variables here that may send you in a different route.
The main idea I'm trying to convey is to make the Root and Intermediate certificate of who signed the switch's Radsec certificate trusted by ClearPass. If that is from an internal CA, then that needs to be inserted here. You may need to add those CA certs to the Trust List. However, when you create an Onboard CA the certificates are already in the trust list. You just need to enable the appropriate usages as in our case.
Navigate back to CPPM -> Administration -> Certificates -> Trust List -> Change filter to Subject and paste in the subject you copied from the previous step.
2 certificates should appear. Verify subject, expiry date, etc. We don't want to accidentally enable Radsec usage on the wrong CAs.
Select each certificate and add the Radsec usage type. Click Update.
Finishing Up
Now, the Radsec tunnel should be established upon next attempt.
Verify from CPPM by visiting the Event Viewer.
Verify from the switch with the following command: show radius-server detail
Office6300# show radius-server detail
******* Global RADIUS Configuration *******
Shared-Secret: None
Timeout: 5
Auth-Type: pap
Retries: 1
TLS Timeout: 5
Tracking Time Interval (seconds): 300
Tracking Retries: 1
Tracking User-name: radius-tracking
Tracking Password: <redacted>
Number of Servers: 1
****** RADIUS Server Information ******
Server-Name : clearpass01.fqdn.com
Auth-Port : 2083
Accounting-Port : 2083
VRF : default
TLS Enabled : Yes
TLS Connection Status : tls_connection_established
Timeout : 5
Auth-Type : pap
Server-Group : radius
Default-Priority : 1
ClearPass-Username : <redacted>
ClearPass-Password : <redacted>
Tracking : enabled
Tracking-Mode : any
Reachability-Status : reachable, Since Fri Jan 14 19:46:27 CST 2022
Tracking-Last-Attempted : Sat Jan 15 13:14:36 CST 2022
Next-Tracking-Request : 114 seconds
Note the TLS Connection Status
Troubleshooting
If you see this error in the CPPM Event Viewer the certificate being presented by the CLIENT is still untrusted. Confirm you have the proper Certificate Authorities trusted by CPPM that signed the switch certificate.
A very similar error will be seen if the switch does not trust CPPM's certificate. This is the language for a client certificate error.
NOTES:
By using the same username / password across your infrastructure devices (APs, Switches, etc.) it will only consume 1 Onboard license. While this may be against best practice, it should be noted.
PLATFORM:
Aruba ClearPass 6.10.3
Aruba AOS-CX 6300F 10.07.0010
Additional Resources: