ClearPass MPSK per Device Type with Profiling

Multiple Pre-Shared Key or MPSK helps solve for IOT or other endpoint device types that are not 802.1X capable.  The Aruba ClearPass default implementation of MPSK (the configuration created by the wizard) requires manually registering, enrolling, and managing individual PSK keys per endpoint using the ClearPass Guest dashboard.  While the most secure approach, excluding any sort of API based automation, this can obviously be a nightmare to manage and support due to the sheer number of PSKs.  This approach instead delivers a unique PSK per device type (printer, thermostat, etc.) so that each flavor of endpoint would have its own PSK.  If one PSK was compromised, then only those endpoints would need to be manually re-configured.  PSK rotation would also be limited to only those specific device types allowing rotation to take place slowly over several weeks rather than all devices at the same time on the SSID with a traditional single PSK; lessoning the burden on IT staff and minimizing business risk.  This method strikes a balance between "PSK sprawl" and manual overhead while still increasing the number of unique PSKs for the environment.  Coupled with profiling, to confirm the device actually looked like the device the PSK it was configured for, we have a secure and scalable solution with little management overhead.  

The environment consists of a pair of Aruba 7210 Mobility controllers with a pair of C2000Vs running ClearPass 6.10.  Note that this post will only focus on the ClearPass configuration.  In the Aruba MC, the MPSK checkbox should simply be marked on the SSID along with MAC authentication.  Maybe this would be a good topic for a future blog post?  Note that this example also assumes that DHCP relay or other profiling methods are already properly configured in the environment (this particular deployment uses DHCP relay and IF-MAP).  

So let's start by creating a service for this MPSK+Profiling flow.  I am not going to use the wizard to create a traditional MPSK setup since this is a unique PSK per device type not per MAC address.  

Navigate to Configuration > Services and create a new Service.  Go ahead and name it and select RADIUS MAC Authentication as the template.  We will specify the following in the Service selection criteria:
Service Selection Criteria

Be sure to also enable Profile Endpoints so we can take CoA actions when the devices are profiled.  We are looking for a Wireless RADIUS MAB request and the SSID to contain IOT.  On the Authentication tab, specify Allow All MAC AUTH with Authorization against the Endpoints Repository.  

Authentication

Allow All MAC AUTH is selected here because all of the enforcement will happen because of profiling rules and the PSK configured on the client.  We aren't using any static host lists or other pure MAC-based authentication.  

Next we need to create a Role Mapping Policy.  This policy has two parts (the entire flow of this is explained below so don't worry if you don't understand quite yet):  Profiled and OUI enforcement.  For this specific example, I am focusing on printers.  Select the Authorization [Endpoints Repository]: Category that matches whatever this device should look like if it provides this PSK.  In our case, the endpoint should look like a printer device when configured with the printer PSK.  This Category is mapped to the Profiled_Printer ClearPass role.  

The second portion of the Role Mapping Policy is a basic OUI check.  Since all ClearPass knows about the device before it connects to the network is the MAC address, we use the Aruba provided MAC Vendor attributes as a pseudo gatekeeper to this policy.  If the endpoint doesn't have a MAC address from any vendor configured here we know that endpoint cannot possibly one of our printers and should not be attempting to connect to the SSID. 

Role Mapping Policy

Next, on the Enforcement tab, we specify what actions we want ClearPass to take for the particular roles configured on the previous screen.  I'm going to start with condition 2 first.  This condition simply looks that our endpoint is matching the Printer_OUI role.  If we remember from the Role Mapping Policy, this role is applied to the endpoint as long as its MAC address is on the list of MAC vendors.  If that condition is true, then ClearPass responds to the Mobility Controller with a role and the MPSK pre-shared key for the printer devices (the actual Enforcement Profile for this is covered in the next section).  

Now lets go back to the first condition.  Condition 1 looks for the Printer_OUI role assigned to the endpoint, the endpoint has been profiled, and the role Profiled_Printer is NOT assigned to the endpoint. If these conditions check pass, then we pass the Deny Access Profile to the Mobility Controller.  So what does this actually do?  This covers the case where a device is part of the MAC_OUI list but ClearPass did not profile this device as a printer.  For example, this would prevent a device that would have an HP MAC address (like an HP laptop) but isn't actually an HP printer.  This also covers MAC address spoofing by an attacker who may spoof their MAC address on their Linux laptop to a MAC in the Printer_OUI list.  

Enforcement Policy

The last tab, Profiler, we want to send the Terminate Session Dynamic Authorization to the Mobility Controller to re-authenticate the device once profiling has successfully occurred from ClearPass.  This forces the endpoint to be re-evaluated by the ClearPass policies to ensure it still matches the configured conditions.  

Profiler

For a successful Printer PSK authentication, we will return the  MPSK_Printer Enforcement Profile.  This profile will return the printer Aruba-User-Role to the Mobility Controller.  This Aruba-User-Role on the Mobility Controller has a VLAN assignment for the printers and a firewall access-list allowing only printer ports/protocols.  Critically, for MPSK, the Enforcement Profile also returns the Aruba-MPSK-Passphrase.  This is the PSK that should be configured on the endpoint.  

Enforcement Profile
Now lets breakdown the overall flow of this MPSK authentication:
  1. Endpoint is configured for WPA2/3 PSK using the PSK defined in the enforcement profile.
  2. Endpoint connects to IOT SSID.
  3. Mobility Controller sends a RADIUS access-request to ClearPass containing the MAC address of the endpoint.
  4. ClearPass evaluates if the MAC address is the list of allows MAC OUIs
    1. Yes? Respond with Access-Accept, Aruba User Role, MPSK Passphrase
    2. No? Respond with Access-Deny.  Endpoint is presented with an invalid PSK message
  5. The controller then validates that the PSK received by the client matches the MPSK Passphrase received from ClearPass
    1. Yes? Endpoint is allowed onto the network with the access provided in the Aruba User Role on the Mobility Controller.
    2. No? Endpoint is presented with an invalid PSK message.
  6. The endpoint attempts DHCP.  A copy of the DHCP request is sent to ClearPass.
  7. ClearPass successfully profiles the endpoint based on the information in the DHCP packets.  
  8. ClearPass sends a Terminate Session RADIUS Dynamic Authorization to the Mobility Controller.
  9. The Mobility Controller restarts the authentication process by sending a new RADIUS access-request to ClearPass containing the MAC address of the Endpoint.  
  10. We know that the MAC address already passed the OUI check. The profiling condition is now in play because the flag for IsProfiled will now be set to true in the endpoint database.
  11. ClearPass evaluates if the endpoint category is a printer.
    1. Yes?  Respond with Access-Accept, Aruba User Role, MPSK Passphrase
    2. No?  Respond with Access-Deny.  Endpoint is presented with an invalid PSK message
  12. The controller once again receives the same MPSK from ClearPass for that endpoint and is allowed onto the network. 
Thanks for reading,
-A

Comments

Post a Comment

Popular posts from this blog

Fix Cisco ISE Messaging Service

Cisco Identity Services Engine 2.6 introduced the concept of the ISE Messaging Service as an encrypted, lightweight protocol to replace syslog communication between the ISE nodes for logging purposes.  The ISE Messaging Services runs over TCP/8671.  In 2.6 Patch 2 and later, the Cisco ISE Messaging Service is enabled by default.   The overall implementation of the ISE Messaging Service has been buggy (but has gotten much better in recent versions) in both new ISE builds and upgrades.  One solution is simply to disable the ISE Messaging Service within Administration > System > Logging.  But then the ISE logging traffic isn't encrypted and the legacy syslog delivery method is not as efficient as the ISE Messaging Service so we will focus the rest of this article on how to identity and fix the ISE Messaging Service. Problem Identification Usually problems with the ISE Messaging Service involve a blank Live Logs page.  You know authentication is working as you have devices/users
Read more

Cisco Designated VIP 2023

I'm happy to announce that I have been recognized as a Cisco Community Designated VIP for 2023 for my assistance in the Cisco Secure Network Access Control community focusing on Identity Services Engine.  Be sure to check out all of the Cisco Community Designated VIPs .
Read more