Identity PSK with Cisco ISE

Do you have some rather "dumb" wireless devices on your network? If you do, you most likely had to implement and support a Pre-Shared Key (PSK) network to allow these devices to connect. Depending on the vendors operating system or even the size of the device many devices that require wireless connectivity to work cannot support the overhead and encryption that comes with the implementation of 802.1X so they simply do not support it. The support of PSK networks come with many security concerns such as; How often do you change the key? How to validate that every device on the network is actually supposed to be there? What happens when the key is compromised? Luckily, a newer type of PSK network is supported in many newer wireless controllers and platforms called Identity PSK (iPSK).

Why?​

At its core, Identity Pre-Shared Keys (iPSK), sometimes also called Multiple PSK (MPSK) or Dynamic PSK (DPSK) depending on the wireless vendor, is a cryptographic mechanism that combines identity information with a pre-shared key to establish secure communication between entities. Unlike traditional PSKs, which focus solely on the shared key aspect, ID-PSK introduces an additional layer of security by incorporating unique identity attributes. This integration not only enhances the strength of the encryption but also ensures that authorized entities can establish connections only after successful identity verification.

What does this get me?​

By integrating identity information into the key generation process you add the ability to limit the likelihood of a lost key compromising your environment while also reducing the attack surface in the event of a compromised key. iPSK also allows you to implement a single wireless SSID to handle multiple use cases and groups of devices. Using a back end authentication solution such as Cisco Identity Services Engine allows you central configuration of the PSKs and policy to align PSKs with other identity attributes for access to the wireless network.

The easy part!​

Configuring iPSK is astoundingly simple if you have basic configuration experience with Cisco ISE and the wireless control system you use on your network. Most newer wireless controllers have a dedicated configuration to setup iPSK in just a couple of steps. In the example, we will use Cisco Meraki Wireless and Cisco ISE to setup and enable iPSK.

Starting on the Meraki Dashboard we will create a new WLAN with the desired name (BSSID) and enter the settings for the WLAN. Under the Network Access section, you will see two iPSK options, with RADIUS and without. We will use the "with RADIUS" option for our integration with ISE. That being said the "without" option allows you to create and manage multiple PSKs directly on the Meraki dashboard but does not have the added capabilities of things like ISE profile type or identity groups.

With our iPSK WLAN using RADIUS we will also need to define the RADIUS servers on the WLAN as well.

That's it! You now have the WLAN portion of iPSK configured for your environment. We now have to configure the ISE side to define the PSKs for each use case or identity and we can start authenticating clients.

The Policy​

To begin, we first have to define an Authorization Profile that sends the iPSK back to the controller/AP to authenticate the device at connection time. You have to define an Authorization Profile for each iPSK you want to have on the WLAN. We will do three use cases in this example, a Door Lock, a Vending Machine, and a Default policy, all with their own unique PSK. In each Authorization Policy, you will have to define the iPSK in the RADIUS: Tunnel-Password Advanced Attributes section of the policy. Additionally, you can add things like an ACL or VLAN if supported and desired. You can see in the example below we are simply defining the password with no other options at this time.

Next is to define the Policy Set on ISE to define the iPSK based on the authenticating device. You can do this in your Default Policy Set or define a new Policy Set just for your iPSK WLAN. Starting with the Authentication Policy we need to treat iPSK authentications similar to a Wireless MAB request and define some of the advanced options.

Because iPSK comes across in RADIUS like a MAB request we do not need to define any Identity Source Sequences other than Internal Endpoints, unless you are using a remote database for MAC address lookups. We also need to change the default behavior for MAC addresses that don't exist in the database yet by setting the "If User not found" setting to "CONTINUE" instructing ISE to proceed to the Authorization policy if the MAC address does not yet exist.

Next, we need to define the Authorization portion of our policy set to tell ISE what iPSK to send back to the wireless solution to match, based on the endpoint identity.

In the example, you can see that we are using some Identity Groups for Door Locks and Vending Machines to have them use a different iPSK than the default. This is where you can start to see how a compromised PSK does not affect ALL of the endpoints on the WLAN but rather only the ones matching the identity of the compromised key. Each Identity Group, Logical Profile, or other identifying charicteristic of each device can have an individually defined PSK.

Conclusion​

Some configurations on ISE can seem complex and daunting like the posture flows or other scenarios that I have gone through before. With that said, iPSK was probably one of the easiest configurations that I have ever done with ISE, it is PSK after all which is pretty easy on its own. If you have questions or need advice let us know and we would be glad to help with your next implementation.

ModernCyber’s Services​

If you are looking for help with Cisco ISE or other consultative or implementation services, we provide multiple service options that can be customized to the outcomes and requirements you need to meet.